作为蓝海市场的SaaS行业，虽然大厂们投入了大量的人力和资金，但始终未能获得不错的利润。 很大一部分原因是公司提供的是标准化的产品，但客户总是有各种个性化的需求。 为了满足客户，他们只能增加成本来制作定制产品。 面对这样的困境，我们该如何突破？ 我们来看看作者的观点。
晚上10点左右，某SaaS公司的CEO给我发了一篇文章，说一家近万亿市值的大公司经过两年的孵化，推出了一款HR SaaS产品。 然而，经过三年的商业化，它在今年6月宣布终止，并解散了产品团队。
其实几个月前我就知道这个消息了，因为我的一个粉丝是战队的核心成员。 他在 6 月中旬向我发送了他自己的摘要，他在其中写道：
我们相伴三年，今日告别，以后再无相见。
这个SaaS产品的起点是相当高的。 号称整合了母公司30多年的成功管理经验，是“CEO为CEO设计的管理体系”。 由于母公司的良好声誉和完善的销售渠道，产品一经推出，便吸引了众多潜在客户前来咨询。
除了母公司的渠道支持，团队建设也被高举，按照大厂标准招人。 以我的这位曾经在四大咨询公司担任解决方案专家的粉丝为例。
那么，为什么不缺资源、不缺客户、不缺人才的SaaS产品，最终会以解散团队的方式退出市场？
从多方信息来看，最直接的原因是缺乏产品标准化能力，由此产生的定制化开发几乎让每个项目都无利可图。
在商务谈判阶段，甲乙双方必须清楚地意识到需要进行一定程度的定制化开发。 但定制项目最可怕的是，由于售前阶段主要靠PPT进行沟通，很容易低估定制开发的程度。 结果，一方面客户抱怨产品太差，另一方面项目方也苦不堪言。
其实，做标准化的SaaS产品，不是拼名气，拼资源，而是拼科学的产品方法论。 如果不遵守产品标准化的规律，即使是万亿市值的大厂商也难逃失败的结局。
01 标准化的困境
我曾在《2023年SaaS行业十大预测》一文中写道：
在国有企业做大做强的背景下，中国SaaS企业不得不主动适应传统企业、国有企业或政府的需求。
但是，一方面，SaaS规模化盈利的前提是标准化； 另一方面，传统大企业更喜欢本地化部署、个性化交付的传统模式。 这使得标准化与定制化的矛盾在2023年更加突出。
事实上，大多数 SaaS 公司的 CEO 都意识到标准化的重要性。 然而，在推进标准化的过程中，很容易陷入以下危险陷阱：
1.项目拉动的标准化
很多粉丝告诉我，公司本来是想做标准化的产品，但客户总是有个性化的需求，如果这些需求得不到满足，客户就会拒绝购买。
最后，公司为了生存，只能接受定制，同时为了控制成本，拼命给产品经理加班加点压力。 结果：员工抱怨，公司没有赚钱，也没有打造出有竞争力的产品。 没有好的产品，企业只能继续做定制项目，从而陷入恶性循环。
这与文章开头的故事如出一辙。
2. 标准化
一些SaaS公司因为有大型软件的经验，从一开始就非常注重产品的标准化。 他们会成立专门的产品部门，甚至打造PaaS平台来满足客户的个性化需求。
然而，标准化的目标不仅仅是“降低软件交付成本”。 事实上，标准化还有以下两个核心目标：
1）打造极致产品
标准化最大的魅力在于“重用”。 无论在一个功能上投入多少资源，只要有足够多的客户使用，就可以无限摊薄成本。
“再利用”的规律可以支持我们把每一个功能都创造到极致，从而显着提高我们产品的竞争力。
2) 沉淀最佳实践
标准化的另一个核心目标是沉淀最佳实践。
为什么客户愿意购买SaaS而不是选择让PaaS公司定制？ 其中一个重要原因是客户在购买前可以试用成熟的产品，从而更加确定产品与需求的匹配度。
功能标准化也有助于SaaS企业积累历史经验，减少项目售前、交付和服务过程中对员工个人能力的依赖。
然而在实践中，SaaS企业往往更注重解决眼前问题，而忽视了标准化的长期价值。 结果，仓促上线的所谓标准化功能的“复用性”不强，或者用户体验差，不足以形成有竞争力的产品。
02 标准化答案
面对以上问题，SaaS企业的正确做法应该是什么？
首先，我们必须认识到，标准化表面上是产品设计的问题，但本质上是企业战略的问题。 如果产品定位不当，就很难实现标准化。
比如本文开头的案例，大厂的产品定位几乎就注定了它的失败。
中国管理人力资源软件领域实际上是一个成熟且竞争激烈的市场。 这款SaaS软件商业化的首批客户是追求精细化管理的大型企业。 这类客户在B端软件应用方面已经有非常成熟的经验，往往有更复杂的个性化需求。 即便是全球领先的HR软件，一定程度的二次开发也是不可避免的，更何况是一个刚刚开始商业化的SaaS软件？
同时，这款SaaS软件非常强调自身的咨询属性，销售一整套“从咨询到实施”的解决方案，也大大增加了客户的期望值和项目交付的难度。
说白了，这是一个很外行的失败：高估了管理咨询的效果，低估了软件开发的难度。
除了正确的定位，我们还需要有实现标准化的智慧。
其实并不是每个领域都适合创业公司进入。 我们要善于在市场中发现规范化的机会，并用正确的策略去抓住它们。
请记住：产品策略决定标准化的成败。
1. 从大到小，还是从小到大？
我曾经和一个投资朋友讨论过：SaaS公司应该从小企业做起还是从大公司做起？
从小企业做起，我们很容易掌握主动权，但要实现规模化盈利楼宇自控售前技术规范最新版，SaaS企业必须攻克大企业市场。 小企业市场的经验往往不足以满足大公司的需求。
从大企业做起，收入规模更容易扩大，但大企业有很多个性化需求，会给产品和服务带来很大压力。
而我的建议是：在产能积累方面，从大企业做起； 在产品变现方面，从小企业做起。
1）在产能积累方面，从大企业做起
小企业的需求往往很简单，管理也很灵活，容易适应。 如果一个产品经理只有小企业SaaS产品的经验，他的架构能力其实很薄弱，很难承担起服务大公司的重任。
其实不管是不是，他们的核心团队都有丰富的大企业B端产品经验。
比如公司的创始人和一些早期的高管都是公司出身，公司的创始人都开发出了名牌产品。
所以，有远大理想的SaaS公司，一定会向大公司学习宝贵的经验，提升产品的行业深度和产品团队的结构能力。
从这个角度来看，即便是定制化，对于拿下行业标杆企业的订单，依然有着非常深远的意义。
2）在产品变现方面，从小企业做起
每个人对小企业的定义都不一样。 我对小型企业的定义是：可以持续为 SaaS 产品付费的小型企业客户。
例如，在快速消费品行业，经销商年销售额超过2000万元，制造商年销售额超过2亿元。 此类企业不仅具备一定的持续付费能力，而且数量众多，适合打造标准化的SaaS产品。
如果在产品的MVP版本中，我们直接按照大企业的需求来开发——除非产品团队的架构能力足够强，产品开发的资源足够丰富——那么产品团队很容易厌倦满足客户' 各种细致的个性化需求。 需求，无法打磨标准化产品。
相反，如果我们在产品的MVP版本中，我们是根据小企业的需求来开发的。 那么不仅产品团队的压力小了，还可以有很强的主动性：我们可以在提炼用户体验和积累行业经验的基础上，按照自己的规划去标准化每一个功能。
说白了，一个孩子去直接挑战世界拳王是不合适的。 最好的路径应该是：用最好的方法训练孩子，但在实战中，还是要选择合适的挑战对象。
2. 专注：成功的关键
在打造标准化产品方面，选择从小做起，既可以避免强大客户的干扰，又可以让我们专注于核心资源。
我曾经做过一个简单的估算：做好同样的功能，“标准化”消耗的资源是“定制”的7倍。
这也是很多从传统软件向SaaS转型的初创公司常犯的错误：他们从一开始就低估了开发标准化产品所需的投入，构建了一个庞大而全面的产品，但在可配置性和用户体验方面却没有做到。 比较粗糙的SaaS产品。
当然，有些朋友会说：只有大而全的产品，客户才会买单。
其实这是一个失败的隐喻：客户说，只要你有XX功能，我就买单——这往往说明我们最初的定位没有抓住企业的一个共同痛点。
质量不够，数量也足够——但全面传播的结果往往完全失控。
只有聚焦核心功能，才能以有限的资源同时实现标准化的三个核心目的：
3、架构：标准化的底层逻辑
很多CEO忽略了一点：不同的产品经理会塑造不同的SaaS产品。
一个只有服务小企业经验的产品经理，在产品设计上往往目光短浅，很难与大公司的管理层进行有效的沟通。
这就是我常说的：缺乏产品架构能力。
就产品设计而言，由抽象到具体，由复杂到简单，总是比较容易的。 如果掌握了复杂抽象的产品设计框架，再针对小客户群设计一个简单的SaaS产品，那么难度其实很小。 你只需要很好地解决用户体验问题。
但是如果你只有针对小客户群的简单产品体验，设计一个复杂抽象的SaaS产品其实是相当困难的。
虽然很多CEO的豪言壮语是：基于多个项目的经验归纳和抽象。 但是这个效率其实很低。 而且我也怀疑是否有可能找到一个业务归纳和抽象能力这么强的产品经理。
其实最简单的方法就是研究那些经过世界500强企业验证的B端产品。 它们虽然不是SaaS模式，但也面临着和SaaS产品一样的客户，以及更复杂的客户需求。
我的一位课程参与者告诉我，在学习之后，他对软件（由他们公司实施）的理解加深了。 这或许可以说明，全球顶级的B端软件在一定程度上都遵循着类似的架构设计。
这就是我们常说的“最佳实践”。
4. 基于SaaS，PaaS辅助
最后提醒大家不要过分依赖PaaS，因为PaaS有其不可逾越的局限性。
首先，它高度依赖于实施者的素质； 其次，高度的抽象往往是以牺牲用户体验为代价的，尤其是一些高频功能，用户体验其实非常重要。
同样，使用 PaaS 构建应用程序的成本较低，但并非没有成本。 重复构建相似的功能也是一种严重的资源浪费。
最后，也是最重要的一点，过度依赖 PaaS 会导致 SaaS 产品停止进化。
企业购买SaaS产品，购买的不仅仅是构建应用的能力，更重要的是购买了SaaS企业的行业经验，以及固化在SaaS产品中的成功实践。
尽管 PaaS 能力很重要，但不要搞错主次关系。
专栏作家#