原则系列－2020年终章之SaaS能够走多远

编者按：本文来自微信公众号“SaaS产品说”（ID:meetsaas），作者：李东林，36氪经授权发布。

今天想跟大家讨论的是笔者觉得作为SaaS公司非常非常重要的一个话题，SaaS产品的可持续发展性。

不知道大家有没有发现发现一个有趣的现象，2000年前后几年，实际上在中国大量的管理软件公司成立，每个赛道都有相对比较优秀的几家公司，人事，CRM,ERP赛道都是如此，在市场上面也有相当的知名度。

但是20年过去了，我们看到每个赛道又开始有大量新的创业公司出现，占据了头条以及所有的目光，很多老牌的供应商仿佛从我们的视野里面消失了一般，他们还在吗？如果他们还在，为什么这么多年的客户，品牌，产品技术积累居然干不过新的创业公司呢？

实际现实是，这些公司很多还活着，依据老客户的维护费以及每年波澜不惊的新增活着，死不了，也活不好，也很难前进了。这几年我们很多新成立的SaaS创业公司实际上也在走他们的老路，正在走入泥潭，只是还需要几年的时间才能陷得和他们一样深，才能陷入一样的状况。

很多时候我们在评估一家公司的时候，我们看销售增长率，看续约率，看销售投入产出比。

但是在B端产品里面，特别是面向中大型客户的市场，很多时候销售是依靠资源驱动的，不是靠产品力，所以销售市场能力以及融资能力强的公司是容易拿到客户的，60分的产品打败90分的产品是常事（当然也有例外的场景，比如说笔者正在做的菜小秘，产品达不到很高的门槛，这群低文化老百姓是没有办法使用的）。

另外一点是B端客户在使用产品之后，三五年内是很难弃用的，因为弃用成本实在太高，做决策的人也很难打自己的脸，所以续约率在三五年内都是很高的。所以大家可以看到，只要有钱，有资源，我们这三个数据似乎很容易做起来，在投资市场也很受热捧，似乎产品只要马马虎虎，能够凑合用就行了。

我们在产品上面马马虎虎，我们不断的依据客户需求凑合粗糙的增加新功能，慢慢的我们的产品越来越臃肿，易用性越来越差，我们发现：

1: 新客户的实施周期越来越长，回款周期越长越长，很多尾款还收不到了。

2: 产品的新功能开发速度越来越慢，开发成本以及维护成本越来越高。

3: 产品越来越难用，客户在忍受了三五年之后，实在受不了，还是转投别人怀抱。

这个时候我们发现已经陷入泥潭，我们发现产品需要做一些减法，但是已经有一些量的客户在用了，我们做减法比登天还难；产品用户体验差，实施周期长，维护成本高，开发速度越来越慢，用户口碑越来越差，我们却也无能为力。

另外我们还不能速死，也很难发展，经过了很多年的挣扎，直到泥潭里面的泥没过头顶，也许我们内心终于松一口气，我们终于死了。

在中国，B端这块，大家都说重视产品，但是实际上一直最重视的都是销售。这么多年中国B端的产品力实质上是没有多少进步的。除了续约，增长，销售投入产出比等指标以外，笔者强烈建议所有的SaaS创业公司以及投资公司好好的去评估一下自家产品另外一个重要指标，那就是产品的可持续发展指数。

产品的可持续发展指数由很多因素决定，包括产品业务架构，功能架构，数据库架构，逻辑耦合度，产品易用性等一系列因素决定。

可持续发展性好的产品公司，会维持良好的用户体验；产品可扩展性，可维护性强；新的开发效率高以及低以及实施培训周期短，回款快；另外客户口碑好，用户获客成本不断降低，会形成一个良好的正向发展循环。

怎样实现产品的可持续发展是SaaS产研团队最核心的课题，笔者最近在崔牛会年会的产品闭门会以及人人年会上面做过一些关于可持续发展的产品原则的分享，再这里再整理分享一下这些原则：

1: 整个产品策略先做薄，再做厚，每个迭代做小，做少，做极致。

在产品MVP的阶段，要围绕核心痛点，选择客户愿意买单并且形成最小闭环的最小功能组合来进行切入，整个产品路径先做薄，再做厚，通过厚度来提升客单价以及客户黏性。

比如说菜小秘刚开始找到的场景就是农批商行赊欠管理的痛点，通过开单赊欠管理切入获取到客户，通过不断的验证迭代，慢慢延展到库存，结算以及上游的货主以及下游的买家的相关场景以及功能。

B端产品功能一旦被客户使用之后，做减法和调整难度是极大的。所以在每个迭代过程中，遵循一个原则，就是做小，做少，做极致，怎样控制需求以及设计的范围是对产品力一个很大的挑战。

另外一点对于B端产品产品就是不能先有再优，对于数据库设计，功能架构，页面架构更是要努力做到极致，否则后续调整成本是非常大的。

2: 做好架构设计，为产品的生长留下空间。

• 业务架构，数据库架构，功能架构是地基，地基错了上面的一切都是错的。

对于C端，我们有一个很经典的怎样做MVP以及产品验证的图，如下：

但是我们在B端产品里面，我们这样去打造一个产品的MVP以及进行需求验证的话，你会发现每一次都要做完全的重构，这种思路在B端产品一定是毁灭性的灾难。

我曾经打过一个比方，C端产品更像是盖大平房，B端产品更像是盖小高楼，平房是很容易重构的，但是高楼的地基没有打好，后续的调整是毁灭性的，很多时候不得不推倒重来。所以如果我们真的要造一辆汽车，可能首先还是要先造一下发动机还有四个轮子，然后慢慢补充车窗，转向灯，车盖等物件。

作为B端产品来说，业务架构，数据库架构，功能架构极其重要，初创公司如果早期没有合适的人才，也应该找高手作为顾问来把关，否则浪费大量时间和金钱不说，后患无穷。关于怎样做B端产品的MVP, 我原来写过一篇专门的文章“关于如何定义B端产品的MVP”，有兴趣的关注一下SaaS产品说公众号进去阅读。

• 产品是不断生长的，要找到最好的分类以及架构方式，为产品的生长留下空间。

我们需要记住的一点就是产品是不断生长的，一点业务或者逻辑的增长，这一点业务或者逻辑都会不断的去进行生长，开枝散叶，最后变得非常复杂。

所以在做产品的时候除了需要需求克制以外，保证业务架构，页面架构，数据库架构的合理性，实际上就是为了给产品的生长留下最合适的空间。

王兴说过一句话，战略就是分类，在思考产品架构的时候，实际上也是找到最好的分类方式。

3: 让功能和数据来找用户。

• 精确的分发功能以及数据来给到每个场景下面的角色和用户。

这句话似乎有点像推荐算法，实际上思路确实是类似的，大型复杂的erp系统动不动就有几百上千个菜单，在这里面去找数据和功能是极其痛苦的。

很长一段时间，企业管理软件就是体验差的代名词，但是随着iphone以及移动互联网的出现，很多设计理念开始普及，B端软件的设计概念正在发生改变。

基于场景的简约式设计越来越普遍，整个思路从让用户去找功能和数据，变成了让功能和数据精确分发给每个场景下面的用户角色。在这个过程中，理解用户，理解场景变得非常重要。

• 做好系统首页以及每个模块，功能首页的设计。

作为B端产品来说，首页的设计很重要，这里的首页包括系统首页以及每个模块，以及复杂功能的首页面。

我们要了解的一点就是B端产品可能功能非常多，但是每个角色每天高频使用的功能一定是很有限的，所以很关键的一点是做好首页的设计。

我们要了解每个角色每天最关心的数据，最高频使用的几个功能，一些关键的信息通知，以及建议需要做的事情，实际上将首页设计好，你会发现客户只需要通过几个首页就可以完成80%以上的工作，这样产品才能大幅降低学习成本。

4: 找到真实的需求以及长期的解决方案。

• 客户说的大多数都是期望的解决方案，要找到客户真实的需求。

很多时候我们都有这样的经验，客户很多时候提的需求都是他们希望的解决方案，不是真实的需求。

比如笔者最近碰到这样的一个需求，就是客户提出创建订单之后，需要手工去修改订单的时间，用户需求很强烈。

如果不做，客户不愿意继续使用系统。我们觉得很奇怪，了解真实的情况之后发现，原来客户经营的菜品很多，高峰期的时候特别忙碌，搜索菜品开单开不过来，所以都是事后录入订单，所以需要修改订单时间到真实的订单时间便于统帐。真实的需求实际上是客户要提升菜品很多的时候，需要提升开单时候选择菜品的效率。

• 找到长期的，产品级别的最佳解决方案，否则需求很容易项目制。

在面对每个需求的时候，我们会发现实际上有很多可能的解决方案，我们不能一家家去做，需要要找到这类客户的最佳业务实践并且产品化，这样可以避免不同客户需求分化导致的项目制。另外这样的最佳实践可以大大提升客户的效率，增加产品的附加价值。

5: 区分需求的高低频，普遍程度，价值高低，做好主线，保证极端情况有路可走。

• 不要想面面俱到，必须要有所取舍。

在做产品的时候，不要想面面俱到，面面俱到的产品一定是一个平庸的产品。我曾经碰到一个经验非常丰富非常努力的产品经理, 在做新产品的时候，业务需求写得极其详尽，各种极端case的考虑极其全面，但是由于没有取舍，没有优先级，产品迟迟无法推出。另外复杂度都花在极端case的处理上面，没有轻重之分，团队疲惫不堪，产品体验差，bug多，最后产品的结果是非常失败的。

• 低频，极端case不要想一定支持得非常友好，保证有路可走即可。

不要想把所有case都支持得非常方便，一般来说极端的case很多时候都要打破正常的主体逻辑。系统就要来建立一套规则的，如果需要打破规则之后还要把逻辑做圆，复杂度是非常高而且系统非常脆弱。

所以对于极端，低频case不要想支持得非常友好，保证有路可走即可。你支持得非常好，就一定程度牺牲了高频case的体验，也从某种角度上面鼓励大家去走小路了，对于业务也是不利的。

这里打一个简单的比方，比如说休假申请审批过程中，已经到了第二级审批人，这个时候申请人突然想修改申请单子，调整日期之类的，我们是否需要去支持一个审批过程中修改单子的功能呢？

也许是不需要的，针对这个case，可能最合适的解决方案，就是让申请人跟上级线下说一下，让上级拒绝申请，然后申请人重新提交就可以了，这样的话已有系统不需要做任何改变。

这里的一个诀窍就是，对于低频极端case，很多时候需要产品功能和线下动作配合去解决，不要想所有动作都线上化。

6: 围绕场景，避免过度设计

• 过度设计是对场景以及业务把握程度不够。

• 过度设计会导致产品体验不贴身，实施成本高的问题。

很多时候我们会走入一个误区，为了避免定制开发，我们很多时候将产品做得特别灵活，可配置性做的特别强，但是配置性做得特别强会带来一些问题，比如说开发成本高，实施成本高，实施周期长，用户体验不贴身。

就像做衣服一样，有的人胖一点，有些人瘦一点，为了做一件所有人都能穿的衣服，最后做了一件特别宽松的衣服，实际上这种衣服对于所有人都是不贴身的。在面向不同客户的时候，每个人的需求形状都是不一样的，有的是长方形，有的是正方形，有的是圆形，有的不规则，最简单的办法就是画一个大圆，把所有需求都满足。但是真正的高手是做一个最小形状的需求，刚好把所有形状都能包含，非常贴身，无法做减法的产品才是最高境界的产品设计。

为了追求灵活度，我们看到有些公司的产品的数据库都可以配置，最后导致的数据库字段意义无法固定，所有逻辑都要可配置化，这种后果是很恐怖的。

所以从长期的角度来看，所有的HR,CRM,ERP市场最终的格局是产品越来越垂直化，基于客户size有不同的产品线来满足，另外大的垂直市场的垂直SaaS都会有很大机会，垂直化细分化的产品一定是长期的大势所趋。

关于PaaS，在中国我并不看好，原因很多，可以以后单独写一篇。

7: 合并同类项，减少复杂度

• 每一条小的逻辑支线都会随着业务的发展不断生长，开枝散叶。

• 由于产品不断生长，前端设计也好，后端逻辑也好，尽量抽象合并，减少支线。

做产品，就是和复杂度做斗争，所有的业务，逻辑都会开枝散叶，越来越复杂。我们怎样用简洁的逻辑支持复杂的case，我们怎样在业务以及设计角度进行抽象，合并同类项，用已有功能或者逻辑组合来满足新的功能以及逻辑需求，是减少复杂度的非常重要的原则。

我们前端时间大热的所谓中台，核心逻辑其实也是合并同类项，实现共享，用这样的思想去做系统就好了，不要过分追求概念化。

8: 尽一切可能降低耦合度

• 耦合度的增加会导致产品的可维护，可扩展性变差。

• 尽一切可能让产品功能侧，逻辑层的耦合度降低。

C端产品更多面向是点状的需求，B端产品更多面向的是面状的需求，需求之间的耦合度极高，在进行产品设计开发的时候需要遵循降耦的原则，否则耦合度太高之后，后续的维护成本会非常高，产品的稳定性也会变得比较差。

9: 找到业务，产品，技术之间的最佳平衡点。

• 不能完全产品或者需求驱动。

• 综合考虑技术的实现成本，可扩展性，可维护性，找到最佳的平衡点。

我们的口号一直说业务驱动，产品驱动。但是作为B端产品来说，没有考虑技术角度的输入，完全业务或者产品驱动会导致灾难性的后果。需要找到业务，产品，技术之间的最佳平衡点，保证产品的易用性，实现成本，可维护性，可扩展性，实现产品的可持续发展，这对于所有SaaS公司来说都是综合性的挑战。

作为SaaS，中国最缺的不是产品或者技术，而是能够快速理解业务，懂产品和技术类似解决方案架构师这样的复合性人才。

红旗能打多久，SaaS能够走多远，除了产品的定位，战略以外，产品的可持续发展指数是非常非常核心的。