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公司来说,这可能是一个巨大的风险。
那么,什么时候是最好的改造时机呢?
我觉得应该符合以下两个条件:
- 已经验证了PMF。
- 确认走大客户路线。
没有验证PMF,搭建PaaS可能是白费力气;如果还不确定走大客户路线,就没有建设PaaS的必要。
满足了这两个条件,越早建设往往就意味着越低的重构成本和风险。
3. 规模化陷阱
如果目标赛道不够大,比如某些行业垂直型SaaS,如果贸然投入PaaS,可能就会掉入规模化陷阱,即PaaS的投入不能得到合理的回报。
目前来看,PaaS建设比较成功的SaaS公司,都有几个特点:
- 产品线长,比如北森的产品涵盖了从人事、招聘到BI的完整HR模块。
- 覆盖行业广,比如纷享销客就重点覆盖了装备制造、快消品等八大行业。
- 建设早,比如北森在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只是一种手段,真正重要的,是要把自己打磨成一家“不一样”的企业。
作者
王戴明,微信公众号:To B老人家,多年互联网产品与信息化管理经验。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!