我在B端SaaS化路上，挖了多少坑 .docVIP

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