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

　　晚上10点多，一位SaaS公司CEO发了一篇文章给我，里面讲述了某市值近万亿的大公司，经过2年的孵化，推出了一款HRSaaS产品。但是在商业化3年以后，于今年6月宣布终止，并解散产品团队。
　　其实这个消息我几个月前就知道了，因为我的一位粉丝就是该团队的核心成员。他在6月中旬给我发过一篇自己的总结，文中写道：
　　三年同行，今日一别，后会无期。
　　这款SaaS产品的起点颇高，号称融合了母公司30余年成功管理经验，是“CEO为CEO设计的经营系统”。由于母公司名气很大，销售渠道也颇为完善，产品一上线，就吸引了众多潜在客户前来问询。
　　除了母公司的渠道支持，团队建设也是高举高打，员工按照大厂标准招聘。以我的这位粉丝为例，他就曾经在“四大”咨询公司担任Workday解决方案专家。
　　那么，为什么不缺资源、不缺客户、不缺人才的SaaS产品，最终却以解散团队的方式黯然退场呢？
　　根据多方来源的信息，最直接的原因，还是产品标准化能力不足，由此导致的定制化开发让几乎每个项目都无法盈利。
　　在商务谈判阶段，对于需要一定程度的定制化开发，甲乙双方肯定都是心知肚明的。但定制化项目最可怕的地方在于：由于在售前阶段主要依靠PPT进行交流，对定制开发的程度容易预估不足。结果最后一方面客户抱怨产品太差，另一方面项目方也陷入苦苦挣扎。
　　实际上，做标准化SaaS产品，拼的并不是名气，也不是资源，而是科学的产品方法论。不尊重产品标准化的规律，即便是市值万亿的大厂，也难逃失败的结果。
　　01标准化的窘境
　　我曾经在文章《SaaS行业2023年十大预测》中写道：
　　在做大做强国有企业的大背景下，中国SaaS公司不得不主动适应传统企业、国有企业或者政府的需求。
　　但是，一方面，SaaS规模化盈利的前提就是标准化；另一方面，传统大企业又更喜欢本地化部署、个性化交付的传统模式。这就使得在2023年，标准化和定制化的矛盾将愈加突出。
　　王戴明，公众号：ToB老人家
　　实际上，大部分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能力虽然重要，但是切莫搞错了主次关系。
　　最后，欢迎大家扫码添加“ToB老人家”主理人个人微信，加入中国（可能）最大的SaaS微信群，领取资料大礼包。
　　请用个人微信添加
　　已有3万来自Salesforce、腾讯云、阿里云、北森等公司的SaaS产品经理、高管和创始人加入。现在加入，还可以领取资料大礼包
　　也欢迎大家了解我亲自主理的。
　　作为全网唯一的SaaS星球，已有6000星友加入。很多星友成功转型SaaS产品经理，或者成功跳槽、加薪、晋级。
　　以下是已有的40节课程列表，现在加入，还可以享受未来一年24节课直播，以及每天免费APP向我提问。
　　注：请购买的朋友，及时下载APP，并加入VIP群。
　　关于星球更多信息，大家可以点击了解：