PaaS的诅咒

面向大客户的SaaS中，既然PaaS平台更为易用，而且通过聚焦垂直赛道，在满足个性化需求的能力大大增强，但为什么会容易被撤掉呢！

一位朋友告诉我，不久前，某知名SaaS公司正式解散了PaaS项目组，并裁掉了相关团队。

要知道，该公司在去年才融资了几个亿，正是要大展拳脚的时候。推翻这样一个战略级项目，无疑是一个重大而又痛苦的决定。

但是，在我看来，这件事件并非个例。它反映了在“看起来很美”的背后，也隐藏着致命的诅咒。如果只看到其美好的一面，这样的裁员故事，未来还会重演。

一、绕不开的PaaS

只要是面向大客户的SaaS产品，都绕不开PaaS这个话题。

十几年前，我还在Oracle公司的时候，我们的项目就已经有很大一部分个性化需求，通过PaaS来交付。

效果当然立竿见影。

和全代码开发相比，PaaS不但可以快速满足客户需求，更重要的是可以节约大量二次开发成本。

和过去Oracle的PaaS相比，如今的PaaS平台不但更为易用，而且通过聚焦垂直赛道，满足个性化需求的能力大大增强。

一家头部SaaS公司的PaaS负责人告诉我：对于大部分企业，他们的SaaS产品能满足70%的通用需求，而剩余30%个性化需求，基本都能够通过PaaS的无代码、低代码能力完成交付。

这意味着，拥有成熟PaaS平台的SaaS公司，在交付效率和成本上都拥有着巨大优势，从而对竞争对手形成降维打击。

然而，PaaS这么美好，为什么知名SaaS公司还要主动放弃呢？

二、PaaS的诅咒

如果美好愿望变成不可承受之重，原因很可能在于我们过于关注美好的一面，而忽略了其背后巨大的风险。

1. 烧钱机器

Paas的美妙之处在于积木化、低成本的程序搭建能力。

为了尽可能多的降低开发成本，同时尽可能高的匹配用户需求，PaaS往往需要搭建一个强大而又复杂的功能架构。而强大能力的背后，则是巨大的投入。即便是在2007年就开始建设PaaS的Salesforce，在几年前仍然保持着4000人的PaaS团队。

这个规模甚至超过国内大部分SaaS公司。

除了强大的能力——和SAP、Oracle等传统软件不同——SaaS公司对PaaS的交互体验也有着更高的要求。

毕竟，只有让企业用户、合作伙伴都能够低成本的使用，PaaS的价值才能得到最大程度的挖掘。

而“高度复杂功能+高标准交互体验”，就必然导致PaaS系统的构建需要耗费大量资金——根据可靠消息，国内相对成熟的PaaS系统，耗资都在数亿以上。

这可能就是，该知名SaaS公司最终推翻PaaS项目的主要原因。

2. 改造风险

2014年，北森决定搭建PaaS平台。

然而他们很快发现，独立存在的PaaS平台价值不大，必须让SaaS在新的PaaS平台上重新“长出来”。

这是因为，最常见的个性化需求，往往不是在标准功能外新增一个独立表单或流程，而是对现有标准功能或流程的“二次改造”。

结果，北森顶着巨大的压力，将所有SaaS产品在PaaS平台上“重做”了一遍。用北森联合创始人纪伟国的话来说，“之后在生死边缘徘徊了好几年”。

造成这一局面的关键在于，2014年的北森SaaS已经不是一个简单的产品，而是一个包含招聘云、继任云、绩效云等多个模块的大型SaaS产品。

对于北森来说，这无异于打碎骨头，再重新拼起来。也就是说，越是成熟、庞大的SaaS产品，将底层改造为PaaS平台就越为困难。对于创业已经好几年的SaaS公司来说，这可能是一个巨大的风险。

那么，什么时候是最好的改造时机呢？

我觉得应该符合以下两个条件：

1. 已经验证了PMF。
2. 确认走大客户路线。

没有验证PMF，搭建PaaS可能是白费力气；如果还不确定走大客户路线，就没有建设PaaS的必要。

满足了这两个条件，越早建设往往就意味着越低的重构成本和风险。

3. 规模化陷阱

如果目标赛道不够大，比如某些行业垂直型SaaS，如果贸然投入PaaS，可能就会掉入规模化陷阱，即PaaS的投入不能得到合理的回报。

目前来看，PaaS建设比较成功的SaaS公司，都有几个特点：

1. 产品线长，比如北森的产品涵盖了从人事、招聘到BI的完整HR模块。
2. 覆盖行业广，比如纷享销客就重点覆盖了装备制造、快消品等八大行业。
3. 建设早，比如北森在2014年就把PaaS平台作为战略目标。

这些特点使得SaaS公司有更大的机会获得回报。

这也意味着，后入场的SaaS公司——特别是所在行业已经有成熟PaaS平台的公司——需要更谨慎的衡量ROI。

4. 创新风险

在某种意义上来说，PaaS是SaaS的替代——对于交付人员来说，如果能用PaaS搭出一个60分的系统“应付”客户，又何必用10倍的时间和成本去交付一个100分的标准化功能呢？

这就导致了PaaS的终极风险：创新风险。即对SaaS功能的过度替代效应。

我注意到，凡是PaaS能力很强的公司，项目组的重要性都在逐步升高，而产品部的重要性则在逐步降低。

这就意味着，SaaS公司正在变成项目制公司。

虽然它的交付成本远低于传统软件公司，但也正在丧失作为一家SaaS公司最宝贵的东西：产品创新能力。比如，面对一个新需求，如果标准功能不满足，项目人员大概率会通过PaaS能力进行交付，而不是给产品部提交一个功能需求。

这就意味着，客户的需求无法传递到产品部，从而错失了产品化的潜在机会。

但实际上，SaaS标准功能的意义，远不止满足需求。在提升用户体验，以及沉淀最佳实践等方面，也具有不可替代的作用。

而用PaaS搭建的应用，往往追求60分原则——用户接受即可——这也导致它不如SaaS功能完美，后期维护的成本、风险也很高。

另外，PaaS能力足够强大以后，项目经理的重要性大大增强，成为“最懂客户的人”。

这当然是好事。但也意味着产品经理的重要性和专业性都大大弱化。我们曾经自嘲的“原型仔”，在未来可能成为更普遍的现象。

然而，项目经理的本职工作是交付项目，而不是产品迭代。其他部门又缺乏对一线场景的把握，那么未来，谁又来负责SaaS公司的产品创新呢？

三、不要盲目追逐PaaS

Paas不是SaaS成功的唯一路径。

对于以中小企业为主，或者专注于细分赛道的SaaS公司来说，打磨好行业解决方案，深挖专业护城河，才是优先级最高的工作。

更重要的是，一个细分行业不需要两家一样的企业。

良性的生态应该充满多样性。优秀的企业家，也不应该去做“别人已经做得足够好的事情”。

PaaS只是一种手段，真正重要的，是要把自己打磨成一家“不一样”的企业。