首页专业知识 CEO来信 | SaaS行业即将迎来的顿悟

CEO来信 | SaaS行业即将迎来的顿悟

来源：晰数塔互联网快讯时间：2019年11月26日 15:02

本文来自“CEO来信”栏目，如果您想普及行业知识、展示对未来趋势判断、收获同行者支持，欢迎点击查看详情。

文/明道云创始人任向晖

周末在杭州开了两天的崔牛会年会。这是一个氛围分外热烈的中年男性社群，从全国各地赶到杭州，完全不是为了找客户，而是为了解开心中的困惑。为什么这个明明优越的产品和商业模式，在中国市场的发展速度迟缓。无论是创业者，还是投资人，明显都对自己不够满意。是产品能力不够强吗？还是中国的客户吝啬？

会场酒店有一个大堂吧，外面还有一座不大的庭院。整个会议期间，参会的同行们几乎不间断地在这两个场所三两成群，交换心得。

CEO来信 | SaaS行业即将迎来的顿悟

谈了哪些话题呢？

除了抱怨几句获客难，研发成本高以外，今年的交谈明显开始转向“怎么办”的话题。

问题大多数时候都只是表象，它有时候距离根源很远，而根源的寻找并不是一朝一夕的事情。创始人们难免会有幻想和执念，不撞南墙，就很难真正去反思。反思之后，才可能有零零星星的顿悟。这些顿悟加总起来，才会推动行业的转折。

产品的边界是命根

SaaS企业已经普遍感受到必须严格控制产品的边界。硅谷产品的专注简洁特征不是偶然现象，而是这个产业的必然。

在中国SaaS界，很多人都拿Salesforce作为标杆和榜样，认为这才是成功SaaS企业的模范形象。销售云，营销云，服务云，XX云，只要是客户需要的，都可以加一个“云后缀”。但是，Salesforce的今天是从Salesforce的昨天发展而来的。Salesforce，SAP，Oracle，微软的昨天才是我们的榜样。

在20年前，Salesforce只是一个在浏览器中运行的Sales Pipeline，它的复杂度甚至不如今天月费20美元的轻型CRM。在企业软件领域中，没有一个公司可以做到在开端的前三年建立一个庞大和复杂的产品体系。在站稳脚跟之前，每一个企业软件都应该极其专注和收敛的，即便拥有一定量的客户以后，还要设法提升产品成熟度，建立牢不可破的高留存。在留存率问题没有解决之前，就急于通过扩展产品宽度来拓客，就会在获客和留存两个环节都困难重重。

产品边界松弛还因为我们会对研发成本的不当预期。像金蝶用友的传统软件产品，研发投入的确是周期性的，建立一个产品，投入一轮研发，交付产品以后一段时间，研发成本就可以消除，从而投入到新的产品当中去。可是SaaS不一样，研发成本不会消除，甚至都不会减少。任何产品只要上线以后，就是始终不断地迭代，一个接一个技术问题的解决，特性的增加和调整，新技术的运用。这本身并不是问题，因为理想情况下，收入也是叠加的。但是，如果初创SaaS企业放松了产品边界，从一个职能延伸到另一个职能，从一个行业拓展到另一个行业，研发成本就不仅是持续，而且是倍数叠加的。

更要命的是，复杂软件产品的研发效率和人数根本不成正比。研发人数越多，消耗在计划和沟通上的成本就会额外增加，导致研发边际效能严重下降。读过《人月神话》的人必然知道这其中的奥秘。如果产品的模块化设计程度较低，那么这种叠加的研发投入还会带来质量和用户体验的灾难。

有加法，也可以有减法。理论上，加减相抵也许能够控制复杂度。但是，做这行的都明白，除非你做了一个完全错误的决定，导致新的扩展没有人使用。你也许可以悲伤地砍掉这个产品。但是遗憾的是，这种极端情况很少见，大多数的叠加总会发展一些客户。发展了客户，就有合同，有了合同就有了承诺，有了承诺，你就很难做减法。一个不能做减法的行业，是多么可怕。

所以，第一个顿悟就在于产品边界的控制。我们再也不能轻率地决定开发新的功能，增加新的模块，发布新的产品。保持产品的单一和简洁不一定能够SaaS产品成功，但却是保证存活的生命线，是我们的命根子。

终于开始彻底信任开放

小客户缺乏支付力，所以国内不少SaaS产品开始转向服务大中客户。但是一进入这个服务区间，马上就面临了现实的问题——客户的议价能力。

议价能力并不一定指的是砍价，更重要的是对需求满足度的刚性要求。你见过几个大客户的需求描述是正好吻合或者小于一个SaaS产品的既有产品能力边界的？一个都没有。所有的客户原生需求或多或少都会超过单个产品的能力范畴。比如采购渠道管理系统的客户会自然提出管理库存、物流、培训等模块的需求。

没有这个功能，怎么办？

面对大客户，牙关是咬不紧的。只能做！这几年，SaaS公司的销售和研发不知道为这些问题花了多少口水，多少CEO都为了这个问题纠结万分。答应得容易，做起来难，于是SaaS产品界出了很多很多奇葩的做法，各种版本，各种方案，林林总总，就是为了满足多样化的需求。当复杂到一定程度，干脆，产品自助试用环节也被砍了，因为完全不知道该怎么给一个陌生客户试用什么样的版本。

单一代码库是别指望了。模块化设计得好的，还能够进行必备的代码分离，主产品的迭代还能保证；急于业务，疏于技术管理的，干脆就加团队算了，反正账上还有钱。一个又一个的项目，一个又一个的版本。

为什么客户的需求都要通过一个产品满足呢？因为我们既无法说服客户，又无法调动行业。渠道管理产品无法简单地和仓库管理应用打通，当渠道商下一个订单的时候，不知道需要从哪些仓库发出哪些物流，怎样组合是最经济的。于是明明做渠道管理的产品，不得不调研和开发WMS，TMS系统。而同一时间，WMS厂商和TMS厂商也被同样的客户要求追加订货系统。客户把每一家SaaS企业都当作SAP和微软了，这是一个多么糟糕的世界？

答案在哪？

开放。通过相对标准和安全的授权模式（API Key或者Open Auth）提供公开的API，让任何开发者（包括其他厂商和客户自己）都可以轻松读取和写入业务数据。有健壮和完善的API，就等于将自己的产品和所有其他产品的集成创造了条件。于是上面的问题就有很好的解决方案，我们只需要创建一个简单的服务，让渠道管理应用的渠道订单触发生成WMS系统的出货单，从而继续触发TMS的物流单。虽然这个过程还需要一些定制开发，但它无疑保护了每一个产品的边界。

令人高兴的是，在过去一年内，开始提供标准范式API的SaaS产品越来越多，只不过有很多还不够开放，比如没有Open Auth体系，APIKey要单独申请。这种本来可以快速实现的对接开发还必须伴随很多线下的沟通和协作。

围绕产品之间的集成需求而出现的IPaaS品类也开始出现。将集成服务产品化，让用户或者厂商通过表单配置来完成API之间的调用，甚至建立SaaS产品的集成用例库，零代码实现任何两个产品之间的场景对接。

今天，这样的路已经有了，只是还不够通畅。我相信顿悟的SaaS厂商接下来会不遗余力地推动它，让产品聚焦不至于在满足客户需求的压迫下而土崩瓦解。在这次崔牛会精彩的辩论赛上，有厂商甚至还在喊出客户需求第一的口号，认为只要是客户的需求，我们就应该不惜一切代价去满足。这个逻辑只会让企业走向深渊，让行业开放无限期推迟。任何有商业常识的人都知道，客户的需求应该满足，但绝不是没有取舍的。

流量从何而来

最后的一个顿悟，其实是不言自明的。用户流量从何而来？钉钉吗？企业微信吗？绝不是。我相信未来SaaS产品的主要流量除了来自自己品牌本身口碑以外，就来自于自身的开放性，而不是因为巨头产品中有一个应用市场。

因为我买的飞利浦显示器同时支持HDMI和USB-C，而我的电脑是Macbook Pro，所以我选择了飞利浦显示器。因为明道云有Webhook触发接口，而我用的金数据表单带有Webhook输出，所以我选择了明道云。IT产业中相当比例的用户流量就是这样流动的。即便是企业微信用户选择应用市场中的应用，本质上也是因为用户账号和消息已经和所有应用打通，而不是因为有一个集市在促销。

其实，企业软件的获客通路是非常显然的，那就是其他企业软件。真正有价值的企业客户肯定不会只依赖一个单项产品，所以当已经在使用某个产品的用户选择扩展场景时，优先选择的当然是能够和现有产品低成本高质量集成的那一些。所以SaaS产品两两之间建立互补性获客是非常容易的事情。

北美市场在这个问题上已经达到了极致，因为任何两个产品之间都不存在集成困难，某公司使用Salesforce的销售管理，同时使用Netsuite的ERP，没有任何问题，还有Zapier这样的厂商早就建立好了Salesforce vs. Netsuite的集成场景，甚至这个集成场景用Microsoft Flow也没有任何问题，更不用说Slack用户还可以轻松创建一个消息提醒到群组。Slack为什么能够增长这么快啊？因为使用任何一个与它集成的SaaS应用的用户都多了个使用Slack的理由，而这样的应用超过1000个。

产品简洁和专注是我们的命根，开放性解决如何兑现客户繁复需求的问题，而同时，开放性也打开了整个行业自然有机获客的大门。有这个意识的SaaS企业已经不少了，接下来，是我们落实行动，大干一场的时候了。