本文深入探讨了作者在转行过程中面临的困境、所采取的策略以及最终实现的转变。通过系统性解决方案的实施，作者不仅克服了“老好人病”，还帮助企业在SaaS领域寻找到了新的成长路径。这篇文章不仅是个人职业转型的记录，更是对SaaS产品开发和需求管理策略的深刻洞察，提供了宝贵的经验和启示，推荐同行业的产品经理阅读。

2022年9月从工作多年的教育行业，转行至企业服务赛道。准确来说是从做教育行业To B产品转为HR SaaS产品，将近2年时间。

在【如何在入职1周内，输出产品规划？】一文中，简单聊过当时转行的基本情况。

当时自己是有疑惑跟焦虑的，不确定是否可以顺利转行，更不确定HR SaaS产品的产品空间跟想象空间多大。

唯一确定的就是：HR SaaS产品赛道是市场足够细分，产品足够聚焦。所以它与教育行业B端产品所需的能力模型、方法论等，应该具备一定匹配度。

换句话说，产品能力与方法论足够抽象的话，它是具备穿透行业的迁移能力的。甚至不夸张地说，它不局限于做产品。

比如你的学习力、抽象能力、思维方式等是可迁移的。所以面对新业务、新环境、新系统，比拼这些能力时，我是自信的。

比如你提炼/运用方法论的能力以及方法论本身，是可迁移的。

比如需求是0，方案是1、站在用户视角看待问题、PM首先是用户、从系统结构层面解决问题，而不是通过改变症状或人解决问题等方法论。

过程中，你也会发现有些方法论的局限性。

比如目标<=>任务=行为1…+行为N和行为=动机+能力+触发，它只适用于角色类的工作台之类的产品设计，不够通用；

一问二定三量四确定：它不够抽象，不具备迁移能力，只适用于某个足够细分、足够聚焦的角色或业务；

你也会重新发现或提炼一些“新”方法论（可能只是对于我来说新，实际对你已经是常识）

比如以终为始，全局思考；从始至终，最小闭环，它适用于B端产品的微积分模式；

KISS原则：SaaS产品设计最重要的原则的“三层八化”，它适用于SaaS产品的全局体验设计提升与优化，它也再次印证了做企业产品的抽象能力的重要性。

如果时光倒流至两年前的秋天，面对那时的自己，我可能会说：“恭喜你，你的判断基本正确，你确实胜任了这份工作。”

然而，有两件事是你未曾预料到的：

一是做SaaS产品竟然可以治好“老好人病”。

另一件是，虽然你胜任了这份工作，却也和企业一起步入了寒冷的SaaS“冰封期”。

一、SaaS企业的需求长尾效应

在教育行业的ToB产品领域，当业务趋于成熟且未发生结构性变化时，面向内部教师、运营、学科等角色的需求往往会显著减少。这种需求的减少可能会导致企业不得不投入资源去满足一些成本高但价值相对较低的需求，这或许可以看作是行业内卷的一种体现。

以我们公司为例，我们几乎每年都会对1-2个系统进行重构，如CRM系统、业务系统、客服系统、教师时段系统、教师管理平台、教研系统、教师工作台等。这些重构的目的是为了支持业务未来5-10年的发展（主要体现在系统的扩展性上），以及提升用户体验和工作效率（主要体现在交互设计上）。每次这样的重构工程至少需要半年时间才能完成。

此外，我们也会不断地深入优化核心模块的产品功能，如课程产品规则、课程销售方式、续报流程、排班系统等。这些工作可以被看作是精细化产品运营的一部分，尽管有人可能会戏称为“没事找事”。

因此，我曾经认为，产品经理最重要的能力是产品规划能力。只有那些能够进行半年甚至更长时间的产品规划的产品经理，才能被称为资深或专家级别的产品经理。

然而，当我进入HR SaaS行业时，我面临的挑战与教育行业的ToB产品截然不同。入职时，我面前有1736条待解决的需求。在近两年的工作中，我解决了近1000条需求，但待解决的需求却增加到了5219条。每周，我们还会收到超过10条新的需求。

更令人惊讶的是，至少90%的这些需求都是合理的。需求的分散性非常严重，呈现出一种长尾状态。这意味着，很少有需求是超过20家客户需要的，一部分需求是10-20家客户需要的，更少的需求是5-10家客户需要的，而最多的需求是只有1-5家客户需要的。

二、“老好人”型PM的精疲力尽

SaaS业务的根本在于续费能力，而系统的稳定性、安全性和持续的免费迭代是确保续费的基础。因此，我们全力以赴地接受并实现客户的需求。

销售团队为了签约客户，如果存在5%-10%的需求未能得到满足，他们往往会将这些需求写入合同，并承诺客户在某个特定时间点前解决，这就形成了倒排期的项目。

实施团队为了缩短实施周期并确保客户能够顺利运行系统，会尽力解决任何阻碍性问题，这通常也意味着系统需要升级迭代，从而成为倒排期的项目。

客户成功团队为了提高续费率，会在续费期采取“用需求换续签”的策略，即承诺在某个时间点解决客户的需求，这同样导致了倒排期的项目。

为了“讨好”客户和内部团队（包括销售、实施和客户成功），我全力以赴地迭代需求，不愿拒绝任何人，担心说“不”会让他们感到失望或愤怒，害怕拒绝可能引发的冲突（我厌恶冲突中的相互指责和无能为力）。

随着时间的推移，我发现了几个问题：

1. 我们的需求迭代速度，只能达到新增需求的1/5（甚至更低）。即使我们有很长一段时间的每周“1096”（即每天10点-21点，每周6天）；
2. 我们重点投入的大项目、大需求，却只解决5%-10%客户需求，投入产出比不合理。例如，我们花费1-2个月时间完成了一些销售新签的承诺需求，但这些需求上线后，并没有带来预期的收益（如更多客户使用或更高的续费率），反而可能带来一些负面影响（如因交互设计或逻辑变化导致的客户投诉）
3. 如果一个人发现用策略（或手段）可达到独占公共资源的话，TA不会因“得了便宜”而收敛，而是会“变本加厉”的持续占用，这是典型属于“公地悲剧”。例如，总是那么2-3个销售人员在签约时将承诺需求写入合同，他们可能还来自同一个团队；或者在续费卡单时，总是那么几个客户成功人员提出必须承诺解决的需求，他们可能只是因为距离产品经理的物理位置更近。
4. 产品经理的“老好人病”由整个团队买单，而不只是你自己。例如，你轻易承诺的需求变成了倒排期项目，所有产研团队成员只能加班工作，甚至为了按时交付不得不放弃一些扩展性的考虑。或者，在承诺需求之前未能充分沟通需求场景，承诺后才发现所需的投入资源是你最初预估的2-3倍，但由于已经承诺，只能硬着头皮去做，导致投入产出严重不合理。

经过近一年的心力交瘁和团队人员变动，我逐渐领悟到了几个重要的道理：

1. 再极限的“老好人”，也解决不了需求过剩问题，这是资源与能力的匹配问题。这就好比修建再多的路，也不一定能解决拥堵问题一样；
2. 通用需求的解决与客户续费之间存在滞后效应，所以你无法有效衡量，通用需求的迭代，可以有效解决客户满意度（尤其是客户老板、HRD等决策人）；
3. 需求的长尾效应是SaaS行业是通病。一定要寻求根本解，而不能依赖PM或相关伙伴；
4. 你是“老好人”或“老恶人”，都不影响事情的结局，除了自我的内耗。所以寻求减少内耗的方式，才是解决问题的核心，而不是改变自己的性格

这些认识帮助我重新审视了工作的方式和方法，促使我寻找更加合理和高效的需求管理策略，以确保团队能够在满足客户需求的同时，保持健康的工作节奏。

三、系统性解决方案：超越个人角色的战略视角

一个SaaS企业是一个复杂的系统，它与其服务的客户群体共同构成了一个更大的生态系统。因此，解决问题的方法应当围绕整个系统构建，而不是仅仅依赖于系统中的个别角色。

例如，让一个“讨好型”性格的产品经理不断地通过上线需求来满足销售、客户成功、实施团队或客户，其效果是有限的。同样，要求销售团队在新签合同时不承诺需求，或者让客户成功团队不利用个人关系来推动需求排期，这些都不是长期的解决方案。

1. 明确战略选择和目标，实现需求优先级的精准定位

系统可以定义为：系统 = 目标 * 连接关系。

我们的目标从追求增长转变为追求盈利，而盈利的关键在于降低成本和提高效率。降低成本主要包括控制产品研发、营销、销售和服务的成本，而这些成本的核心在于提升续费率和降低新签成本。

首先，企业战略选择是关键，它涉及到企业定位、客户心智和企业资源匹配度的权衡。

例如，根据客户规模，可以分为巨型、超大型、大型、中型、小型和迷你型客户；根据行业，可以分为制造业、互联网、医疗医药、服务业、渔业、畜牧业、物业管理、娱乐业等；根据地域分布，可以分为国内不同区域和国外市场；根据客户阶段，可以分为意向、新签、签约和续签客户，每个阶段的客户需求也有所不同。

在资源有限的情况下，聚焦是明智的选择。我们经过一段时间的探索，最终确定了我们的战略方向。

第一阶段，我们试图从中小型企业转向服务大型客户，希望通过提高客单价来实现盈利。我们选择了每个行业的1-2个标杆企业，围绕它们的需求进行产品迭代，希望标准化产品能够满足更多同行业中小企业的需求。然而，经过半年的执行和复盘，我们发现标杆客户的效果未达预期，原因主要包括：

• 用户心智。我们在用户心智中定位为中小型企业的SaaS服务商，想要改变这一形象并非易事；
• 管理机制与理念。即使是同一行业的相似规模和阶段的企业，也可能因管理机制和理念的差异而有显著不同的需求；
• 投入产出比。我们半年的努力仅满足了3-4家大型客户的需求，而这些需求并未被同行业其他企业采纳。

第二阶段，我们回归到中小型企业客户群，并专注于关键成长潜力的行业，如新兴互联网、制造业、医疗医药等。

在需求规划时，我们聚焦于目标客户群体的需求，策略性地放弃全局通用性需求和非目标客户群体的需求。在与销售、客户成功、实施团队沟通需求排期时，也优先考虑目标客户群体的需求。

通过这些措施，我们算是迈出了构建系统性解决方案的关键一步，尽管还有很长的路要走。

2. 插件化：解决需求长尾效应的潜在方案

目前，有效解决SaaS行业长尾需求的方案主要有两种：PaaS（包括低代码平台）和插件化市场。

PaaS兼具创造性和风险，它既能解决个性化的长尾需求，也可能带来高昂的研发成本。

插件化市场虽然不易实施，但对于标准化SaaS产品企业来说，它具有可行性和想象力。其目标是解决客户个性化需求，底层逻辑是有效利用社会资源。即标准化SaaS企业搭建插件平台并运营插件市场，每个插件由自研或第三方团队开发，旨在解决特定需求，同时可以在市场上销售，以回收研发成本。

尽管成功不易，插件化是我们必须探索的路径。在中国SaaS市场，标准化SaaS产品的优势已经不如以往。

3. 重塑系统要素之间的连接关系，改善需求流转机制

我们主要通过机制、流程和工具来重塑产品经理与客户、销售、实施、客户成功团队之间的需求流转关系，以实现系统性解决方案。

具体措施包括：

1. 工具：建立需求池的反馈机制作为缓冲区，让所有需求正常流转，减轻产品经理的决策压力。 例如，当销售、实施或客户成功团队提出需求时，如果不是紧急需求，可以建议他们先将需求提交到需求池，然后统一进行规划排期。

2. 流程：基于目标与战略选择，转化为需求规划以及对应原则，并文档化与透明化，让合作伙伴清晰需求机制，有效构建需求流转流程。

基于系统的目标与战略，落地为产品规划原则与机制，并完成（季度/半年）产品规划。同时，无论是产品规划原则，还是产品规划，最终都实现100%对外开放与透明，让所有伙伴可随时查阅，确保其提需求时，可查看规划与原则。

3. 模式：用插件化模式，撬动社会化研发资源，解决个性需求。

首先，构建插件需求响应机制。

第二，基于SaaS的标准版本，构建可支持插件化的平台。

第三，打造插件化案例，并开放对应插件平台给第三方。

4. 双向需求通路机制：这一机制旨在区分并解决个性紧急需求和通用性需求。

对于个性且紧急的需求，我们优先推荐插件化解决方案。如果客户拥有自己的产研团队，我们建议他们自行开发插件；如果没有，我们会评估人力资源情况，并根据客户的付费意愿来确定需求的优先级。

对于通用性需求，我们会评估其优先级。如果客户愿意付费（或需求直接影响续签），我们会适当调整其优先级以加快处理；否则，我们将这些需求纳入常规规划流程。

在资源与排期出现冲突时，我们会将涉及的多方及其领导拉入同一个群组，共同决定需求的最终优先级。

5. 法务介入的邮件确认流程：为了防止销售团队因新签压力而随意承诺需求，我们引入了法务部门的介入。

销售团队在承诺任何需求之前，必须通过邮件与产品经理确认需求的排期和解决方案。法务团队将参与评估，以确保承诺的可行性。只有当承诺被认为是可以执行的，销售团队才能进行排期；否则，他们不得承诺。

通过这些流程、机制、模式的建立，我们不仅提高了需求管理的效率，还降低了潜在的法律风险和运营成本。

四、总结一下

做SaaS产品是否可以治愈PM的“老好人病”？这个说法既有其合理性，也有其局限性。

合理性在于，通过实施系统性解决方案，我不再因需求问题给自己过大压力，不再因害怕拒绝或讨好别人而轻易承诺需求。我现在完全遵循流程、机制和模式来解决问题，即使是拒绝，我也能轻松且坦然地说“不”，避免自己和团队承担不必要的责任。

然而，这并不意味着我的性格发生了根本改变，而是我解决问题的方法变了。原本由我个人决策和控制的事情，现在转变为依靠系统性解决方案（即流程、机制和模式），从而减轻了决策者的压力。

系统性解决方案的含义是：系统 = 目标 * 连接关系。

系统性解决方案 = 通过重塑系统目标以及要素之间的连接关系来解决问题（而不是依赖人来解决）的方案。

例如，在SaaS行业中解决大量的长尾需求，并非仅靠PM（或其他角色）的努力就能实现，而是需要新模式、新流程、新机制。

系统性解决方案的关键要素包括：

• 目标：由追求增长转变为追求盈利。
• 战略：确定将三大行业的中小型企业作为核心客户群。
• 工具：使用需求池的反馈机制作为缓冲区，让所有需求正常流转，减少PM的决策精力和压力。
• 流程：根据目标和战略选择，转化为需求规划和对应原则，并将其文档化和透明化，让合作伙伴清晰了解需求机制，有效构建需求流转流程。
• 模式：采用插件化模式，利用社会化研发资源，解决个性化需求。
• 机制：实施双向需求通路，解决不同类型的需求。
• 流程：通过法务的介入，采用邮件确认形式，解决销售随意承诺需求的问题。

通过这些措施，SaaS产品的需求管理变得更加系统和规范，从而有助于PM克服“老好人病”，实现更加健康和可持续的工作方式。