eol-stakeholder-sequence

EOL 利益相关方沟通顺序

目的

规划 EOL 沟通的顺序，以及每次沟通必须涵盖的内容。输出是一份按顺序排列的沟通对象清单——每一站都列明你需要从对方那里获得什么、你需要向对方交代什么、需要留意哪些危险信号，以及沟通必须产出什么。

EOL 不是一次广播，而是一系列彼此衔接的沟通：每次沟通都会为下一次提供信息，也会发现上一次遗漏的问题。顺序安排得当，棘手的问题会在会议室里浮现；安排不当，它们就会在公告发布后，当着客户的面公开爆发。

输入

最适用的情况： 即将停止支持的产品，以及目前已知情的人。

也很有用： 影响范围（客户、收入、合同）、是否涉及渠道合作伙伴或监管机构，以及需要提前规划的政治敏感因素、紧张关系或过往意外情况。

随调用一并提供的任何内容——技能名称后面的文本、粘贴的背景信息，或附加的 ARGUMENTS: 行——都视为已回答的信息。请使用这些内容，并跳过其中已涵盖的问题；不要重复提问。

手头没有信息？也没关系。 此技能最多会问三个问题——即将停止支持什么、谁已知情、影响范围有多大，以及是否有需要提前规划的历史情况——然后制定沟通顺序。政治敏感因素是可选信息；没有也能制定顺序，提供了则能让顺序更精准。

调用示例：

• 为淘汰我们的旧版报告模块，安排利益相关方沟通顺序。
• 关于停止支持一条有 8 家经销商的硬件产品线，我该按什么顺序和哪些人沟通？

---

核心概念

排序原则

先和能叫停计划的人沟通，再和需要执行计划的人沟通。

每次沟通都应为下一次提供信息。首先评估法律风险，因为合同条款可能让讨论就此终止。其次评估财务影响，因为这会决定后续各项工作的规模。然后沟通面向收入的团队、面向客户的团队，最后是负责执行的技术团队。

如果顺序颠倒——先向支持团队说明，最后才找法务——你可能已经把计划告诉了 40 个人，却发现一项合同条款就能让计划失效。

匹配适当的沟通规模

EOL 的情况各不相同。 大多数介于中间：

	级别 1 — 轻量	级别 2 — 标准	级别 3 — 重型
典型范围	功能、内部工具、API	商业产品、有活跃客户	收入关键型产品、硬件、受监管产品
沟通对象数	3-4	7-8	10+
包含对象	工程、支持、受影响用户	+ 法务、财务、销售、市场营销、客户成功、难沟通的客户	+ 高管、渠道、监管机构、重点客户
无特殊原因可跳过	法务、财务、销售、渠道	渠道、监管机构	—

默认采用级别 2。 给出建议级别并说明理由，然后让用户自行调整。绝不要默认采用最重型的沟通顺序——为一项功能弃用安排十站沟通，会消耗你在真正需要时才想动用的信誉。

如果有人选择缩减范围，请指出他们要删掉哪个沟通对象，以及该对象通常能发现什么问题。如果产品有合同却要跳过法务，这是值得仅提出一次异议的情况——之后应尊重他们的决定。

标准顺序

按级别筛选，但相对顺序保持不变：

级别 1+

1. 工程 — 技术上有哪些依赖项
2. 支持 — 支持运营会有哪些变化
3. 受影响的用户或内部团队 — 谁最先受到影响

级别 2+（插入到上述顺序之前）

1. 法务 — 合同和监管方面的风险
2. 财务 — 收入影响和预测变化
3. 销售 — 销售管道、捆绑方案，以及在一线做出、却从未写入合同或工单的承诺
4. 市场营销 — 你不会想发现，他们刚为你终止的产品买下了为期一个季度的需求生成服务
5. 客户成功 — 他们将承受最大的冲击；要与他们合作，而不是绕过他们
6. 最难应对的客户 — 他们会发现你遗漏的三件事，而这些事本可能在六个月后引发重大问题

级别 3+

• 高管领导层 — 战略审批
• 渠道合作伙伴 — 库存、承诺及其自身的客户关系
• 监管机构 — 申报和合规
• 重点客户 — 单独的迁移沟通

为什么要将最难应对的客户纳入沟通顺序

这有悖直觉，也是团队最常跳过的一步。那个提交工单最多、在季度业务回顾中施压最狠的客户，必然对你的产品有最深入、最独特的使用方式。他们会发现你忘记的集成、没人读过的合同条款，以及在替代方案中找不到对应项的工作流。

你现在可以通过一次预先安排的通话从他们那里了解到这些，也可以之后从他们在公开论坛上的发言中得知。

你需要什么 / 你欠他们什么

每个沟通对象都涉及两个方向。跳过第二个方向，就会让利益相关方沦为旁听者：

• 你需要他们提供什么 — 只有他们掌握的意见、审批或知识
• 你欠他们什么 — 他们做好本职工作所需的背景信息、承诺或提前通知时间

只索取信息的沟通能换来配合。双向沟通则能让你了解到他们原本没人询问的事情。

便利贴规则

每条要点为 4 到 8 个词。大家会在走廊里、会议前或用手机阅读沟通顺序。

反模式（本指南不是什么）

• 不是利益相关方地图。 没有权力/关注度矩阵。这是一份按顺序排列的沟通行程。
• 不是群发计划。 客户公告是另一份材料。
• 默认不能并行处理。 价值在于顺序；仅在注明时并行处理。
• 不是 RACI。 决策权归属与沟通顺序是两个不同的问题。

---

应用

步骤 1：确定级别

根据影响范围给出建议，列出全部三个级别供用户选择。如果不明确，请询问：

“这次停止服务有多复杂？

1. 轻量 — 一项功能或内部工具。用户很少，且都能联系到。
2. 标准 — 有付费客户和合同的商业产品。
3. 重大 — 对收入至关重要、涉及硬件、渠道合作伙伴或受监管。

大多数情况属于标准级。哪种情况更符合你的实际情况？”

步骤 2：排列沟通对象

按标准顺序并根据级别筛选。值得考虑两项调整：

• 有必要时将沟通对象提前。 如果上次销售团队措手不及，就比模板建议的时间更早向销售团队通报，并说明原因。
• 当一个职能部门涉及两种不同的沟通时，将其拆分。 “法务（合同）”和“法务（监管）”往往由不同的人负责，也会给出不同的答复。

步骤 3：完善每个沟通环节

为每个沟通对象填写五项内容：

1. 时间 — 在哪个里程碑或其他沟通环节之前或之后
2. 此环节对 EOL 的重要性 — 用 4-8 个词说明
3. 你需要他们提供什么 — 列出具体问题，而不是笼统地写“意见”
4. 你欠他们什么 — 背景信息、提前通知时间、承诺
5. 需要留意的危险信号 — 表明此环节刚刚发现阻碍因素的信号

然后说明产出：这次沟通必须形成的决策、审批或材料。没有产出的沟通只是状态更新，不算一个沟通环节。

第 4 步：标注并行与顺序关系

说明哪些环节必须严格按顺序进行，以及原因；哪些环节可以安全地并行推进。明确这一点，团队才能把十个环节压缩到三周，同时不破坏关键依赖关系。

第 5 步：说明假设

最后说明你的假设——你认为谁了解相关情况、合同中有哪些约定，以及哪些关系仍然牢固。

最后一步：提供后续选项

“接下来要做什么？

1. 构建分阶段检查清单 — 制定可执行计划（推荐）
2. 为三个最敏感的环节起草谈话要点
3. 构建内部赋能资料包 — 支持常见问题、销售谈话要点、异议处理
4. 起草客户公告 — 参见 eol-message

回复一个数字、组合（例如“1 和 3”），或提出你自己的方案。”

---

示例

• examples/sample.md — Fieldlight Classic Dispatch（SaaS，Level 2，八个环节）
• examples/sample-industrial.md — NFA-200 控制器产品线（工业，Level 3，十一个环节）

---

常见陷阱

陷阱 1：先公告，后询问

症状： 流程一开始就是一封面向全公司的邮件。

后果： 后续每次沟通都变成与某人的谈判：对方以错误的方式得知消息，现在只顾维护自己的利益，而不是帮助你。

解决方法： 公告是内部流程的终点，不是起点。

---

陷阱 2：最后才找法务

症状： 计划制定完成后才让法务介入“审查”。

后果： 一条合同条款或监管义务推翻了四十人已经承诺执行的计划。现在你只能重新讨论，而非付诸实施。

解决方法： 法务是 Level 2 及以上流程中的第一个环节。花五分钟确认“这里是否存在承诺”，胜过花五周重新规划。

---

陷阱 3：把销售团队当成接收者

症状： 只是告知销售团队 EOL 日期，而不是询问他们做出过哪些承诺。

后果： 从未写入合同的销售承诺会在公告后浮出水面，从客户角度看，就像你们不守诚信。

解决方法： 明确询问销售团队：有人承诺过这款产品未来会怎样吗？先问，再告知。

---

陷阱 4：跳过难沟通的客户

症状： 流程涵盖内部职能后就结束了。

后果： 你的边缘情况会被那些最不可能保持沉默的人发现。

解决方法： 在公开公告前，先联系两三位最难沟通的客户，必要时签署 NDA。为他们发现的问题预留预算。

---

陷阱 5：只索取信息的谈话

症状： 每个环节都列出你需要的东西，却没有任何回馈。

后果： 利益相关者只回答被问到的问题，不会主动补充。真正让你陷入困境的，恰恰是没人想到要问的事。

解决方法： 在进行每个环节前，先填写“你欠他们什么”。

---

参考资料

相关技能

这些技能各自独立——没有哪个是本技能的前置条件，本技能也不是它们的前置条件。如果你已在其他地方选择了级别，只需说“Level 2”，本技能就会据此展开。

• eol-checklist — 分阶段的可执行计划
• eol-internal-enablement — 这些谈话后提供给面向客户团队的资料
• eol-readiness-advisor — 如果仍需论证是否做出决定
• eol-message — 面向客户的公告
• stakeholder-map — 用于非 EOL 工作的一般权力／利益映射

外部框架

• Mendelow 矩阵 — 按权力／利益进行优先级排序，有助于确定每个环节所需的沟通深度
• DACI / RACI — 决策权，与谈话顺序是两个不同的问题

来源

• 改编自 https://github.com/deanpeters/product-manager-prompts 仓库中的 prompts/eol-stakeholder-sequence.md。