大厂SaaS，坚守5年，为何还是失败了？

　　作为蓝海市场的SaaS行业，尽管大厂们投入了大量的人力和资金，依旧没能获得很好的盈利。很大部分原因在于，公司提供标准化的产品，但客户总有各种个性化需求，为了满足客户，只能增加成本做定制化产品。面对这样的困局，应该如何突破？一起来看看作者的观点。
　　晚上10点多，一位SaaS公司CEO发了一篇文章给我，里面讲述了某市值近万亿的大公司，经过2年的孵化，推出了一款HR SaaS产品。但是在商业化3年以后，于今年6月宣布终止，并解散产品团队。
　　其实这个消息我几个月前就知道了，因为我的一位粉丝就是该团队的核心成员。他在6月中旬给我发过一篇自己的总结，文中写道：
　　三年同行，今日一别，后会无期。
　　这款SaaS产品的起点颇高，号称融合了母公司30余年成功管理经验，是＂CEO为CEO设计的经营系统＂。由于母公司名气很大，销售渠道也颇为完善，产品一上线，就吸引了众多潜在客户前来问询。
　　除了母公司的渠道支持，团队建设也是高举高打，员工按照大厂标准招聘。以我的这位粉丝为例，他就曾经在＂四大＂咨询公司担任Workday解决方案专家。
　　那么，为什么不缺资源、不缺客户、不缺人才的SaaS产品，最终却以解散团队的方式黯然退场呢？
　　根据多方来源的信息，最直接的原因，还是产品标准化能力不足，由此导致的定制化开发让几乎每个项目都无法盈利。
　　在商务谈判阶段，对于需要一定程度的定制化开发，甲乙双方肯定都是心知肚明的。但定制化项目最可怕的地方在于：由于在售前阶段主要依靠PPT进行交流，对定制开发的程度容易预估不足。结果最后一方面客户抱怨产品太差，另一方面项目方也陷入苦苦挣扎。
　　实际上，做标准化SaaS产品，拼的并不是名气，也不是资源，而是科学的产品方法论。不尊重产品标准化的规律，即便是市值万亿的大厂，也难逃失败的结果。
　　01 标准化的窘境
　　我曾经在文章《SaaS行业2023年十大预测》中写道：在做大做强国有企业的大背景下，中国SaaS公司不得不主动适应传统企业、国有企业或者政府的需求。
　　但是，一方面，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功能我就买单——这往往说明，我们一开始的定位，就没有抓住企业的一个普遍痛点。
　　质量不够，数量来凑——但是全面铺开的结果，往往就是全面失控。
　　只有聚焦于核心功能，我们才可能在资源有限的情况下，同时实现标准化的三个核心目的：
　　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能力虽然重要，但是切莫搞错了主次关系。
　　专栏作家#
　　王戴明，微信公众号：To B老人家，人人都是产品经理专栏作家，多年互联网产品与信息化管理经验。
　　本文原创发布于人人都是产品经理，未经许可，禁止转载。
　　题图来自 Unsplash，基于 CC0 协议。
　　该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。