2. 产品的新功能开发速度越来越慢，开发成本以及维护成本越来越高。3. 产品越来越难用，客户在忍受了三五年之后，实在受不了，还是转投别人怀抱。这个时候已经陷入泥潭，产品需要做一些减法。但是已经有一些量的客户在用了，做减法比登天还难；产品用户体验差，实施周期长，维护成本高，开发速度越来越慢，用户口碑越来越差，企业却也无能为力。另外企业还不能速死，也很难发展，经过了很多年的挣扎，直到泥潭里面的泥没过头顶，也许内心终于松一口气，终于死了。在中国，B 端这块，大家都说重视产品，但是实际上一直最重视的都是销售。这么多年中国 B 端的产品力实质上是没有多少进步的。除了续约、增长、销售投入产出比等指标以外，建议所有的 SaaS 创业公司以及投资公司好好地去评估一下自家产品另外一个重要指标，那就是产品的可持续发展指数。产品的可持续发展指数由很多因素决定，包括产品业务架构、功能架构、数据库架构、逻辑耦合度、产品易用性等一系列因素决定。可持续发展性好的产品公司，会维持良好的用户体验；产品可扩展性，可维护性强；新的开发效率高以及低以及实施培训周期短，回款快；另外客户口碑好，用户获客成本不断降低，会形成一个良好的正向发展循环。怎样实现产品的可持续发展是 SaaS 产研团队最核心的课题，笔者最近在崔牛会年会的产品闭门会以及人人年会上面做过一些关于可持续发展的产品原则的分享，在这里再整理分享一下这些原则：01先薄再厚，做到极致在产品 MVP 的阶段，要围绕核心痛点，选择客户愿意买单并且形成最小闭环的最小功能组合来进行切入，整个产品路径先做薄，再做厚，通过厚度来提升客单价以及客户黏性。菜小秘刚开始找到的场景就是农批商行赊欠管理的痛点，通过开单赊欠管理切入获取到客户，通过不断的验证迭代，慢慢延展到库存，结算以及上游的货主以及下游的买家的相关场景以及功能。B 端产品功能一旦被客户使用之后，做减法和调整难度是极大的。所以在每个迭代过程中，遵循一个原则，就是做小，做少，做极致，怎样控制需求以及设计的范围是对产品力一个很大的挑战。另外一点对于 B 端产品产品就是不能先有再优，对于数据库设计，功能架构，页面架构更是要努力做到极致，否则后续调整成本是非常大的。02架构设计
一、业务架构，数据库架构，功能架构是地基，地基错了上面的一切都是错的
对于 C 端，有一个很经典的怎样做 MVP 以及产品验证的图，如下：但是我们在 B 端产品里面，这样去打造一个产品的 MVP 以及进行需求验证的话，就会发现每一次都要做完全的重构，这种思路在 B 端产品一定是毁灭性的灾难。我曾经打过一个比方，C 端产品更像是盖大平房，B 端产品更像是盖小高楼，平房是很容易重构的，但是高楼的地基没有打好，后续的调整是毁灭性的，很多时候不得不推倒重来。所以如果我们真的要造一辆汽车，可能首先还是要先造一下发动机还有四个轮子，然后慢慢补充车窗，转向灯，车盖等物件。作为 B 端产品来说，业务架构、数据库架构、功能架构极其重要，初创公司如果早期没有合适的人才，也应该找高手作为顾问来把关，否则不仅会浪费大量时间和金钱，还会后患无穷。二、产品是不断生长的，要找到最好的分类以及架构方式，为产品的生长留下空间我们需要记住的一点就是产品是不断生长的，一点业务或者逻辑的增长，这一点业务或者逻辑都会不断的去进行生长，开枝散叶，最后变得非常复杂。所以在做产品的时候除了需要需求克制以外，保证业务架构、页面架构、数据库架构的合理性，实际上就是为了给产品的生长留下最合适的空间。王兴说过一句话，战略就是分类，在思考产品架构的时候，实际上也是找到最好的分类方式。03让功能和数据来找用户一、精确的分发功能以及数据来给到每个场景下面的角色和用户这句话似乎有点像推荐算法，实际上思路确实是类似的，大型复杂的 ERP 系统动不动就有几百上千个菜单，在这里面去找数据和功能是极其痛苦的。很长一段时间，企业管理软件就是体验差的代名词，但是随着 iPhone 以及移动互联网的出现，很多设计理念开始普及，B 端软件的设计概念正在发生改变。基于场景的简约式设计越来越普遍，整个思路从让用户去找功能和数据，变成了让功能和数据精确分发给每个场景下面的用户角色。在这个过程中，理解用户、理解场景变得非常重要。二、做好系统首页以及每个模块，功能首页的设计作为 B 端产品来说，首页的设计很重要，这里的首页包括系统首页以及每个模块，以及复杂功能的首页面。要了解的一点就是：B 端产品可能功能非常多，但是每个角色每天高频使用的功能一定是很有限的，所以很关键的一点是做好首页的设计。企业要了解每个角色每天最关心的数据，最高频使用的几个功能，一些关键的信息通知，以及建议需要做的事情，实际上将首页设计好，你会发现客户只需要通过几个首页就可以完成 80% 以上的工作，这样产品才能大幅降低学习成本。04真实的需求与长期的解决方案一、客户说的大多数都是期望的解决方案，要找到客户真实的需求客户很多时候提的需求都是他们希望的解决方案，不是真实的需求。最近经常出现的一个需求就是客户提出创建订单之后，需要手工去修改订单的时间，用户需求很强烈。如果不做，客户不愿意继续使用系统。这看起来很奇怪，了解真实的情况之后发现，原来客户经营的菜品很多，高峰期的时候特别忙碌，搜索菜品开单开不过来，都是事后录入订单，所以需要修改订单时间到真实的订单时间便于统帐。真实的需求实际上是客户要提升菜品很多的时候，需要提升开单时候选择菜品的效率。二、找到长期的，产品级别的最佳解决方案，否则需求很容易项目制实际上，每个需求都有很多可能的解决方案，我们不能一家家去做，需要找到这类客户的最佳业务实践并且产品化，这样可以避免不同客户需求分化导致的项目制。另外这样的最佳实践可以大大提升客户的效率，增加产品的附加价值。05取舍一、不要想面面俱到，必须要有所取舍在做产品的时候，不要想面面俱到，面面俱到的产品一定是一个平庸的产品。曾经遇到一个经验非常丰富非常努力的产品经理, 在做新产品的时候，业务需求写得极其详尽，各种极端 case 的考虑极其全面，但是由于没有取舍，没有优先级，产品迟迟无法推出。另外复杂度都花在极端 case 的处理上面，没有轻重之分，团队疲惫不堪，产品体验差，bug 多，最后产品的结果是非常失败的。二、低频，极端 case 不要想一定支持得非常友好，保证有路可走即可不要想把所有 case 都支持得非常方便，一般来说极端的 case 很多时候都要打破正常的主体逻辑。系统就要来建立一套规则的，如果需要打破规则之后还要把逻辑做圆，复杂度是非常高而且系统非常脆弱。所以对于极端，低频 case 不要想支持得非常友好，保证有路可走即可。支持得非常好，就一定程度牺牲了高频 case 的体验，也从某种角度上面鼓励大家去走小路了，对于业务也是不利的。比如说休假申请审批过程中，已经到了第二级审批人，这个时候申请人突然想修改申请单子，调整日期之类的，我们是否需要去支持一个审批过程中修改单子的功能呢？
也许是不需要的，针对这个 case，可能最合适的解决方案，就是让申请人跟上级线下说一下，让上级拒绝申请，然后申请人重新提交就可以了，这样的话已有系统不需要做任何改变。这里的一个诀窍就是，对于低频极端 case，很多时候需要产品功能和线下动作配合去解决，不要想所有动作都线上化。06围绕场景，避免过度设计
C 端产品更多面向是点状的需求，B 端产品更多面向的是面状的需求，需求之间的耦合度极高，在进行产品设计开发的时候需要遵循降耦的原则，否则耦合度太高之后，后续的维护成本会非常高，产品的稳定性也会变得比较差。09找到业务、产品、技术的最佳平衡点
不能完全产品或者需求驱动。
综合考虑技术的实现成本，可扩展性，可维护性，找到最佳的平衡点。
我们的口号一直说业务驱动，产品驱动。但是作为 B 端产品来说，没有考虑技术角度的输入，完全业务或者产品驱动会导致灾难性的后果。需要找到业务、产品、技术之间的最佳平衡点，保证产品的易用性、实现成本、可维护性、可扩展性，实现产品的可持续发展，这对于所有SaaS公司来说都是综合性的挑战。作为 SaaS，中国最缺的不是产品或者技术，而是能够快速理解业务，懂产品和技术类似解决方案架构师这样的复合性人才。红旗能打多久，SaaS 能够走多远，除了产品的定位、战略以外，产品的可持续发展指数是非常非常核心的。
Saanet 