本文作者以亲身经历为例，回顾了自己在B端SaaS化过程中遇到的问题以及经验，与大家分享。
一、抽象化处理需求是悖论
这是书籍和经验造就的坑坑。
在很多的书籍或者方法论中，认为SaaS产品应该实现标准的需求，当遇到个性化需求的时候，要把它抽象化，抽象成很多企业可以共用的样子。
开始的时候我信了，数十次碰壁之后我发现，这可能也是中国没有一个可以走向世界的SaaS产品的原因原因之一。
聊聊第一个坑：我们做To B的SaaS服务，有一天，一个客户跟我说，我要看我们公司不同门店的数据，你帮我处理下吧。
那时候使用系统的基本都是餐饮类企业，调研了多家企业又分析了竞品，发现这是个标准需求呀，我们挺高兴，在系统里增加了一个“门店”的标签。
好多用户反馈，你们这个功能好呀，我都能按门店查询啦，再也不用导出来一点点对账啦……
随着业务发展，慢慢接入了好多房地产行业的用户，客户说，我得按小区统计数据，你们支持吗？
我们一看，这跟门店不是一个意思嘛，问人家门店行不行，客户说：我是小区，不是门店。
我们想，书上说了，要抽象，专门开了10次会议讨论，终于确定了一个词“业务类型”。
那时候觉得自己特牛，终于可以支持多个行业场景啦。什么餐饮门店、物业小区、建筑项目、不同业务线，都往上靠吧！
然后，业务又发展了，有了更多的合作伙伴，更多的行业使用这个产品。
于是，每天每天，电话、微信群、面对面会议，总有人问“业务类型”是什么呀？怎么用呀？
在同一个人第80次问我的时候，我哭了。边挠桌子边问：“姐，我如果让它叫门店你能理解吗？”
东北小姐姐扯着嗓门说：“那有啥不理解的呀，你早这么叫我都不问你。”
除了跪下，我还能怎么办……
这时候我不得不想，抽象，是不是错了。
如果同一个概念，门店就叫门店，小区就叫小区。
在客户使用系统前，选择下行业，系统根据行业区分后显示对应名词，是不是这个沟通和学习成本就没这么高了？
或者，还有哪些更好的方式，能即使用客户常用的名词，系统又能兼顾不同情况呢？
SaaS化，到底是把客户的需求抽象后实现，还是直接实现客户的需求，系统通过灵活的配置兼容多场景，低学习成本推广呢？
我倾向于后者。
这篇文章从写完到发布，经历了大约一个月左右的时间。
我在网络言论方面，是个胆子有点小的人，对于这种理论与实践冲突比较大的情况，总想多方位的求证，在不同的场景和行业里得到证实之后，才敢胡说八道。
在求证过程中，我发现有太多太多名词无法理解，因为用词不一致导致大量无效沟通甚至产品推进难度大的情况。
究其原因，是大家在常识方面不一致。
常识，让有些人心有灵犀，默契自成；常识，也让一些人，说着同一种语言却无法沟通。
不同地区、行业、职业、教育背景、原生家庭甚至不同性别的人，都各自有自己的常识。这些在C端产品中备受重视的客户细分，到了B端，因为业务的复杂性，有时候会被无意识的忽略。
尊重对方的习惯的时候，同样获得尊重。不论是人还是产品。
而抽象，属于一种融合，是进行了深入理解甚至逻辑处理后的结果。首先挑战人的习惯，其次挑战人的惰性，再次考验人的记忆力和理解力。
遇到类似问题时，多想几套方案，不局限于抽象，不拘泥于常识，也许会遇见更多的惊喜。
二、要解决某个场景下某个问题，而非支持某个功能
这个坑，部分原因来自公司的组织架构过于细碎，另一部分原因，可能来自于需求提出人及接收人的认知偏差。
我曾在一个产品群问小伙伴“你们公司有售前、需求分析师、产品经理”这些岗位吗？
有很多小伙伴所在的公司，都同时存在这三个岗位。
to B 的SaaS服务，常常会包含定制化，项目和产品并存。这种情况下，需要设计及处理某需求的人，接收到的需求，中间被转了多手的情况，屡见不鲜。
需求方需要从执行人或者子公司中将需求收集上来，这是第一波信息传递。这个时候，多数情况下还是在表述执行人在做某件事的过程中遇到了什么问题，期望得到解决。
如果需求方有IT部门，业务同事会将需求转达给IT部门，这是第二波信息传递。
之后，再由需求方的业务同事或IT同事将需求转述给供应商的销售或售前经理，售前经理再转述给需求分析师或产品经理，中间经过多次的信息传递。
产品经理听到的需求，很多时候会被表述为“希望支持一个功能，方便客户在做XX的时候更XX”。
中间夹杂了不知道多少人在听到需求时，下意识给出的解决方案。
如果做信息传递的所有人，对要使用的系统都充分理解，并行业知识扎实，所提出的解决方案很有可能是可用的，但这种情况极少存在。
所以，需求保鲜，是一种能力.
对需求的准确表达，能让SaaS路上的坑少很多。
有些需求，确实需要通过系统支持某个功能来实现，可是还有很多，需要通过服务、培训等等其他方式实现。
这在信息传递的过程中，常常被关注于系统的同事们忽略。
三、某个需求不管怎么实现，都觉得怪怪的，那可能不该你来实现
这是中台路上好大的一个坑。
不同系统间互相依赖，进度不同步，信息不同步，客户需求迫切等等原因，最容易孕育畸形。
中台是这几年才有的一个概念，概念提的很好，对公司的统一性管理，确实有效。
但因为它是新事物，产品的融合过程中，已有的业务系统，往往会比中台进度更快。
有些权限类需要用户体系中台实现的功能。客户马上就要用，中台还在开发基础功能，在中台重要紧急程度不够；在业务系统，重要紧急程度却极高，业务系统有时候不得不单独创造一个概念，先支持需求，让客户可用。
等后续中台跟上来的时候，发现业务系统的好些概念，跟中台的功能冲突；这时候再跟客户解释，可能已经解释不通。
怪胎，就这么产生了。
三国有言“天下大势，合久必分，分久必合”。
在产品发展过程中，总会包含很多阶段性产物。某一个阶段觉得很合理的场景，后续总觉得越看越怪，还找不到原因。
这时候，不妨跳出当前这个圈圈，到更大的圈子里俯瞰全局，也许只是路在别人的脚下而已。
四、加法做多了，容易找不到路
这是欲望的坑。
市场机会和开发周期是有限的，欲望是无限的，有时候，接受不完美，也是一种能力。
每一次新做一个产品，总有人觉得你描绘的，不是这个产品全部的样子。
期望你能描绘的更大更全更广阔。于是，本是想做一颗玻璃球，让娃娃在沙发上就能玩耍，公司的销售能力也是在这个程度。
可是，因为不够大不够全，可能最后变成了做一个足球。产品是做大了，好不好的不好说。问题是：去哪里找个足球场供娃娃踢足球呢？又去哪里找一起玩耍的小伙伴呢？
欲望可以有，梦想也是个伟大的词；一旦脱离了本心和能力范围，有可能连本可以走出去的那条路，最后都找不到了。
中国很多的企业，活不过五年。总结失败原因的时候，得有多少是因为产品越滚越大，获客越来越难造成的呢？
小而精未必不美。
精准定位、快速试错、逐次迭代，对于团队的资源使用情况及市场把握情况可能更合适。
作者：一米；公众号：产品人儿
本文由 @一米 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
