新知一下
海量新知
6 6 7 6 2 7 7

大厂SaaS,坚守5年,为何还是失败了?

王戴明 | 多年B端产品经验 2022/10/12 10:54

晚上10点多,一位SaaS公司CEO发了一篇文章给我,里面讲述了某市值近万亿的大公司,经过2年的孵化,推出了一款HR SaaS产品。但是在商业化3年以后,于今年6月宣布终止,并解散产品团队。

其实这个消息我几个月前就知道了,因为我的一位粉丝就是该团队的核心成员。他在6月中旬给我发过一篇自己的总结,文中写道:

三年同行,今日一别,后会无期。

这款SaaS产品的起点颇高,号称融合了母公司30余年成功管理经验,是“CEO为CEO设计的经营系统”。由于母公司名气很大,销售渠道也颇为完善,产品一上线,就吸引了众多潜在客户前来问询。

除了母公司的渠道支持,团队建设也是高举高打,员工按照大厂标准招聘。以我的这位粉丝为例,他就曾经在“四大”咨询公司担任Workday解决方案专家。

那么, 为什么不缺资源、不缺客户、不缺人才的SaaS产品,最终却以解散团队的方式黯然退场呢?

根据多方来源的信息, 最直接的原因,还是产品标准化能力不足,由此导致的定制化开发让几乎每个项目都无法盈利。

在商务谈判阶段,对于需要一定程度的定制化开发,甲乙双方肯定都是心知肚明的。但定制化项目最可怕的地方在于:由于在售前阶段主要依靠PPT进行交流,对定制开发的程度容易预估不足。结果最后一方面客户抱怨产品太差,另一方面项目方也陷入苦苦挣扎。

实际上, 做标准化SaaS产品,拼的并不是名气,也不是资源,而是科学的产品方法论 。不尊重产品标准化的规律,即便是市值万亿的大厂,也难逃失败的结果。


01 标准化的窘境

我曾经在文章《SaaS行业2023年十大预测》中写道:

在做大做强国有企业的大背景下,中国SaaS公司不得不主动适应传统企业、国有企业或者政府的需求。

但是,一方面,SaaS规模化盈利的前提就是标准化;另一方面,传统大企业又更喜欢本地化部署、个性化交付的传统模式。这就使得在2023年,标准化和定制化的矛盾将愈加突出。

王戴明,公众号:ToB老人家 SaaS行业2023年十大预测

实际上,大部分SaaS公司的CEO都意识到了标准化的重要性。但是,在推行标准化的过程中,却很容易陷入以下危险的陷阱:

1、被项目拉扯的标准化

很多粉丝告诉我,公司本来想做标准化的产品,但是客户总有个性化的需求,而如果不满足这些需求,客户就会拒绝购买。

最终,为了生存,公司只能接受定制,同时为了控制成本,又拼命压迫产品经理加班。结果就是:员工怨声载道、公司赚不到钱,也构建不出有竞争力的产品。而缺乏好的产品,公司又只能继续做定制项目,从而陷入恶性循环。

这和文章开头的故事,如出一辙。

2、变了味的标准化

有的SaaS公司由于具备大型软件的经验,一开始就很注重产品的标准化。他们会建立专门的产品部,甚至打造PaaS平台,用于满足客户的个性化需求。

但是,标准化的目标并非简单的“降低软件交付成本”,实际上,标准化还有以下两个核心目标:

1)打造极致产品

标准化最大的魅力在于“复用”。哪怕一个功能投入再多资源,只要有足够的客户使用,成本就可以被无限摊薄。

“复用”定律可以支撑我们极致化打造每一个功能,从而显著提升产品的竞争力。

2)沉淀最佳实践

标准化的另一个核心目标是沉淀最佳实践。

为什么客户愿意购买SaaS,而不是选择让PaaS公司定制?其中一个重要的原因就在于,客户在购买前可以试用已经成熟的产品,从而更加确定产品与需求的匹配度。

标准化的功能,也有利于SaaS公司将历史经验进行沉淀,从而在项目售前、交付和服务的过程中,减少对员工个人能力的依赖。

但是,在实践中, SaaS公司往往更关注对当下问题的解决,而忽略标准化的长期价值。结果匆忙上线的所谓标准化功能“复用能力”不强,或者用户体验糟糕,不足以形成有竞争力的产品。


02 标准化的解答

面对以上问题,SaaS公司正确的做法应该是怎样的呢?

首先,我们必须意识到: 标准化表面上是产品设计的问题,但本质上是公司战略的问题。 如果产品的定位不恰当,标准化就很难实现。

比如,在本文开头的案例中,该大厂产品的定位就几乎注定了它的失败。

中国管理型HR软件领域,其实是一个成熟、竞争充分的市场。而该SaaS软件商业化的第一批客户就是追求精细化管理的大型企业。这样的客户,在B端软件的应用上已经有非常成熟的经验,而且往往有较为复杂的个性化需求。即便是世界领先的HR软件,也不可避免一定程度的二次开发,何况是一款刚开始商业化不久的SaaS软件呢?

同时,这款SaaS软件非常强调自己的咨询属性,售卖的是一整套“从咨询到落地”的解决方案,这也极大的提高了客户的期望,以及项目交付的难度。

说白了, 这是一次非常外行的失败:高估了管理咨询的效果,低估了软件研发的难度。

除了正确的定位,我们还需要有实现标准化的智慧。

事实上,并非每一个领域都适合创业公司切入,我们要善于从市场中发现标准化的机会,并且用正确的策略去抓住它。

切记:产品策略决定了标准化的成败。

1、从大到小,还是从小到大?

曾经和一位投资人朋友讨论:SaaS公司到底应该先从小企业做起,还是先从大企业做起?

从小企业做起,我们容易掌控主动权,但是要实现规模化盈利,SaaS公司就必须攻克大企业市场。而小企业市场的经验,往往不足以应对大企业的需求。

从大企业做起,更容易做大收入规模,但是大企业的个性化需求很多,会带来很大的产品和服务压力。

而我的建议是: 在能力积累上,从大企业出发;在产品实现上,从小企业出发。

1)在能力积累上,从大企业出发

小企业的需求往往很简单,管理也非常灵活、易于变通。如果一个产品经理只有面向小企业的SaaS产品经验,他的架构能力实际上非常薄弱,也很难承担起服务大企业的重任。

实际上,不管是Salesforce还是Workday,他们的核心团队都有丰富的大企业B端产品经验。

比如,Salesforce的创始人和部分早期高管都来自于Oracle公司,而Workday的创始人曾经研发出了大名鼎鼎的Peoplesoft。

因此, 一家有远大理想的SaaS公司,一定会从大企业身上汲取宝贵经验,用来提升产品的行业深度,以及产品团队的架构能力。

从这个角度来说,即便是做定制化,拿下行业标杆企业的订单,仍然有着非常深远的意义。

2)在产品实现上,从小企业出发

每个人对小企业的定义不太一样。我对小企业的定义是:规模较小,但能够为SaaS产品持续付费的企业客户。

比如,在快消品行业,经销商的年销售规模在2000万以上,制造厂商的年销售额在2亿以上,这样的企业除了具备一定的持续付费能力,数量也较多,适合打造标准化的SaaS产品。

如果在产品的MVP版本,我们直接根据大企业的需求研发——除非产品团队的架构能力足够强大、产品研发的资源足够丰富——那么产品团队很容易疲于满足客户的各种细致、个性化的需求,无力打磨标准化的产品。

反之, 如果在产品的MVP版本,我们根据小企业的需求研发。那么不但产品团队的压力较小,而且可以具有很强的主动性:我们可以按照自己的规划,在雕琢用户体验、沉淀行业经验的基础上,做好每一个功能的标准化。

说白了,让一个小孩直接去挑战世界拳王是不妥当的。最佳的路径应该是:用最好的方法去培训小孩,但在实战的时候,还是应该挑选一个合适的挑战对象。

2、聚焦:成败的关键

在标准化产品的构建上,选择从小企业入手,除了免受强势客户的干扰,也能够让我们聚焦核心资源。

我曾经做过简单估算:做好同一个功能,“标准化”所耗费的资源,是“定制化”的7倍。

这也是很多从传统软件转型SaaS的创业公司,常犯的一个错误:他们一开始就低估了研发标准化产品所需的投入,结果构建了一个大而全,但是在可配置性、用户体验方面都比较粗糙的SaaS产品。

当然了,有朋友会说:只有大而全的产品,客户才会买单。

其实这是一个失败的隐喻:客户说,只要你有了XX功能我就买单——这往往说明,我们一开始的定位,就没有抓住企业的一个普遍痛点。

质量不够,数量来凑——但是全面铺开的结果,往往就是全面失控。

只有聚焦于核心功能,我们才可能在资源有限的情况下,同时实现标准化的三个核心目的:

1)提升复用能力

2)打造极致体验

3)沉淀行业经验

3、架构:标准化的底层逻辑

很多CEO忽略了一点:不同的产品经理,会塑造出不同的SaaS产品。

一个只有小企业服务经验的产品经理,他的产品设计往往也比较短视,也很难与大企业管理层进行高效的沟通。

这就是我常说的:缺乏产品架构能力。

在产品设计上,从抽象到具体、从复杂到简单总是相对容易的——如果你掌握了复杂、抽象的产品设计框架,再去设计一款简单、针对小范围客群的SaaS产品,那么难度其实是很小的。你只需要解决好用户体验问题就可以了。

但是如果你只有简单、针对小范围客群的产品经验,要去设计一款复杂、抽象的SaaS产品,那难度其实是相当大的。

虽然很多CEO的说辞是:根据多个项目的经验进行归纳和抽象。但是这样的效率其实非常低。而且我也很怀疑能否找到业务归纳和抽象能力如此强大的产品经理。

其实, 最简单的做法,就是去研究那些已经经过世界500强企业验证过的B端产品。虽然他们不是SaaS模式,但是也面对和SaaS产品一样的客户、以及更加复杂的客户需求。

我的一位Oracle课程学员告诉我,学习Oracle之后,他对Salesforce的理解加深了(他们公司实施了Salesforce)。这也许能够说明,世界顶级B端软件在一定程度上都遵循了类似的架构设计。

这就是我们常说的“最佳实践”。

4、SaaS为主,PaaS为辅

最后,我要提醒大家,不要过于依赖PaaS,因为PaaS有其难以克服的局限性。

首先,它高度依赖于实施人员的素质;其次,高度的抽象往往是以牺牲用户体验为代价的,特别是一些高频功能,用户体验其实非常重要。

再次,PaaS搭建应用的成本较低,但是并非没有成本。反复搭建类似功能,也是严重的资源浪费。

最后,也是最重要的一点, 过于依赖PaaS,会导致SaaS产品停止进化。

企业购买SaaS产品,不仅仅是购买应用搭建的能力,更重要的是购买SaaS公司的行业经验,以及固化在SaaS产品中的成功实践。

PaaS能力虽然重要,但是切莫搞错了主次关系。 

更多“SaaS”相关内容

更多“SaaS”相关内容

新知精选

更多新知精选