eol-process

EOL 流程

目的

端到端完成产品退役：判断是否退役，让有权叫停此事的人达成一致，制定运营计划，让将要面向客户的团队做好准备，发布公告，并妥善收尾。流程分为六个阶段，阶段之间设有决策点。

整个流程的指导目标，也是值得始终牢记的一句话：淘汰产品，但不失去客户。 后续的大部分内容，都是为了守住这句话的后半部分。

这是一项编排技能。它不会取代各项产物技能，而是告诉你何时该使用哪项技能，以及继续推进前必须满足什么条件。

输入

最适合提供： 正在退役的产品，以及你目前所处的阶段——正在考虑、已经决定、计划进行中，或已发布公告但进展不顺。

也有帮助的信息： 规模（客户、收入、合同）、是否有替代方案，以及哪些人已经知情。

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

两手空空也没关系。 流程会先确认要退役的产品以及你目前所处的阶段，然后引导你进入相应阶段。如果你已在进行退役，但遇到了问题，请说明情况——“中途加入”中的诊断会找出被跳过的阶段。

调用示例：

• 为我们的旧版报告模块运行完整的 EOL 流程——已做出决定，其他事项均未开始。
• 我们三周前宣布了退役计划，现在 Support 忙得不可开交。我们漏掉了什么？

---

关键概念

六个阶段

#	阶段	要回答的问题	主要产物
1	决策	我们应该退役此产品吗？规模有多大？	准备情况评估 + 强度级别
2	协调	谁能叫停此事？他们掌握了哪些我们不知道的信息？	利益相关方沟通顺序
3	规划	需要做什么、何时做、由谁负责？	按阶段设置关卡的检查清单
4	准备	客户获知前，我们的团队准备好了吗？	内部赋能资料包
5	公告	客户会听到什么？何时听到？	面向客户的 EOL 消息
6	收尾	我们完成了吗？从中学到了什么？	EOL 复盘

第 6 阶段是大家最容易跳过的阶段。 它也是能让你下一次退役成本更低的阶段。请提前为此安排预算，因为事后没人会主动承担。

这是一条路线，而非流水线

本套件中的每项技能都可以独立使用，彼此之间没有先后依赖关系。本流程是穿行于独立环节的一条推荐路线，而不是传送带——这意味着：

• 你可以从任何阶段进入。 决策已经做出且理由充分？从第 2 阶段开始。
• 在级别允许时，你可以跳过阶段。 一级退役通常可以把第 2 至第 4 阶段压缩到一个下午完成。
• 你可以回退，有时也必须回退。 第 2 阶段经常会把你送回第 1 阶段——法律部门的发现或销售承诺都可能推翻原有决策。这说明流程正在发挥作用，而非失效。
• 阶段之间不会移交任何固定格式。 在不同阶段之间传递上下文，只需告诉下一项技能“二级”，并粘贴已有材料。无需保留任何架构。

这套顺序之所以有价值，是因为每个阶段都会揭示下一阶段所需的信息。有意偏离，而不要无意偏离。

合理确定整个流程的规模

并非所有生命周期结束都一样。 流程会随着退场规模而缩短或延长：

	级别 1 — 轻量	级别 2 — 标准	级别 3 — 重量
典型范围	功能、内部工具、API	商业产品、活跃客户	收入关键业务、硬件、受监管领域
用时	数天至数周	6-12 个月	12-24 个月
第 2 阶段的停止条件	3-4 项	7-8 项	10+ 项
第 3 阶段的关卡	2-3 个阶段，无关卡标准	4-5 个阶段，设有关卡	全部 6 个阶段，关卡设有审批人
第 4 阶段的产出	支持常见问题解答	+ 销售要点、异议、升级路径	+ 渠道简报、培训
第 5 阶段的消息	简短通知	含阶段表的标准通知	完整分阶段通知，包含合规内容
第 2-4 阶段	通常可合并为一次会议	各阶段独立且依序进行	各阶段独立，并有各自的工作流

默认采用级别 2。 在第 1 阶段设定级别，并以此确定后续所有环节的规模。 切勿默认采用级别 3——小规模退场搞形式主义，会让所有人到了大规模退场时也忽视流程。

中途加入

大多数人是在退场过程中才发现这项技能的，而且往往是在问题重重时。症状对应着被跳过的阶段：

症状	跳过的阶段	现在该怎么做
“法务刚发现合同问题”	2（对齐）	暂停。返回第 1 阶段——原决定可能经不起审视
“销售说他们承诺过会永久提供”	2（对齐）	在进一步沟通前，盘点一线团队做出的承诺
“支持团队被工单淹没了”	4（准备）	今天就发布常见问题解答和升级流程；其余内容随后补齐
“客户说他们从未听说过”	5（公告）	重新公告并注明日期；第一次通知没有传达到位
“没人知道各自负责什么”	3（计划）	制作检查清单；无人负责的事项就是失败的根源
“我们关闭了它，结果出了问题”	3（计划）	从未盘点下游使用方
“我们做完了，却什么也没学到”	6（复盘）	现在就进行复盘——记忆很快会淡去

协作引导的事实依据

以 workshop-facilitation 作为任何阶段以对话方式进行时的互动流程。提前告知、收集背景信息、提供带编号的选项，并允许参与者转到指定阶段。

反模式（这不是什么）

• 不是项目计划。 它安排的是决策和产出物，而不是任务和资源。
• 不要求完整执行。 在级别 1 的情况下仍走完六个阶段，正是这套流程要避免的形式主义。
• 不能替代沟通。 第 2 阶段需要人们交谈，而不是编写文档。
• 不是单向流程。 返回第 1 阶段是成功的表现，而不是回滚。

---

应用

使用 template.md 作为正在进行的退场项目的一页式跟踪表。

此工作流包含 6 个阶段，每个阶段之后都有一个决策点。用时从级别 1 的数天到级别 3 的两年不等——在第 1 阶段设定级别，以此确定后续流程的规模。每个阶段都会注明负责产出相应成果的技能，但所有这些技能也都可以独立运行，因此可以从你实际所处的阶段开始。

---

第 1 阶段：决策

问题： 我们应该退场吗？规模应该多大？

活动

1. 如实说明触发因素——某项指标、战略转变、成本问题或高管的一句评论。触发因素预示着可能的失败模式。
2. 根据保留信号评估退场信号。两个或更多强烈的退场信号意味着确实有必要退场；但义务方面的限制或缺少合适的承接方案，可能比所有退场信号都更重要。
3. 设定强度级别。 根据影响范围提出建议，再审慎选择。此级别决定后续每个阶段的规模。
4. 确认承接方案：替代方案、迁移方案或平稳退出方案——并确认其是否已准备就绪。

本阶段运行 eol-readiness-advisor。

输出

• 一个判断：Go、附带条件的 Go、Hold 或 Harvest
• 一个强度级别（1、2 或 3）
• 一个指定的承接方案及其准备状态
• 一份宣布前需核查的义务清单

决策点 1：这是 Go 吗？承接方案是否切实可行？

• Go → 进入第 2 阶段
• 附带条件的 Go → 进入第 2 阶段，并将该条件作为第 5 阶段的门槛
• Hold → 停止。设定重新评估的触发条件。考虑更低成本的措施（仅停止销售、调整价格、修复 Bug）是否能满足实际需求
• Harvest → 停止投入，而非停止产品。设定复审日期

如果承接方案尚未准备就绪，可以继续进行第 2 至第 4 阶段，但不能进入第 5 阶段。不要宣布尚无法支持的转型。

---

第 2 阶段：协调

问题： 谁能叫停此事？他们掌握了哪些我们不知道的信息？

活动

1. 按顺序征询相关方意见：法务、财务、销售、营销、CS、难以应对的客户、工程、支持——根据级别筛选；第 3 级还包括高管、渠道和监管部门。
2. 对每个相关方，准备好你需要他们提供的内容，以及你应向他们提供的内容。
3. 按顺序进行沟通。每次沟通都会为下一次提供参考。
4. 记录发现的事项，尤其是现场承诺、合同条款和隐藏的依赖关系。

此阶段运行 eol-stakeholder-sequence。

输出

• 已完成的沟通顺序，并为每个相关方记录输出
• 发现的承诺、义务和依赖关系清单
• 根据最难应对的客户修订后的影响清单

决策点 2：是否有任何情况使决策失效？

这是整个流程中最重要的关卡，也是团队最容易流于形式的一环。

• 没有阻碍事项 → 进入第 3 阶段
• 合同、法规或承诺阻碍了时间安排 → 返回第 1 阶段。根据新证据重新评估。调整日期、范围，或改变判断
• 承接方案的实际可行性低于预期 → 返回第 1 阶段。这是最常见的发现，通常来自与难以应对的客户沟通时

此时返回第 1 阶段，代价很小。第 5 阶段之后才发现同样的问题，代价就不小了。

---

第 3 阶段：规划

问题： 必须完成哪些事项、何时完成、由谁负责？

活动

1. 选定适用的生命周期关卡，并列明有意不采用的关卡。
2. 按阶段、按职能领域并依照设定的级别，列出事项。每项都要包含一个动词、4–8 个词，以及一个明确的负责职能。
3. 为每个阶段转换编写关卡标准并指定审批人（第 2 级及以上）。
4. 覆盖产品退场会影响的四个方面：数据、合同、访问权限、资金。
5. 将第 4 阶段的“赋能完成”日期安排在计划中，且必须早于第 5 阶段的公告日期。

此阶段运行 eol-checklist。

输出

• 包含负责人和日期、按阶段设关卡的检查清单
• 关卡标准及明确指定的审批人
• 已明确负责人的 EOL 后续行动，包括第 6 阶段的复审
• 待验证的假设

决策点 3：每项事项是否都有人负责？每个日期是否都切实可行？

• 事项无人负责 → 这就是发现的问题。应升级处理，而不是掩盖问题
• 无法证明合理的日期 → 写上 TBD，或写 Not scheduled 并注明前提条件。凭空编造 EOL 日期，就是承诺一个你会在公开场合违背的日期
• 赋能日期没有早于公告日期 → 现在就调整；实际上，这两个日期会重合

---

第 4 阶段：准备

问题： 在客户得知之前，我们的员工准备好了吗？

活动

1. 根据客户的实际提问整理支持常见问题，按来电量从高到低排序。
2. 编写销售要点，并附上诚实的对比表——包括差距。
3. 使用“认可-重构-提供”的方式撰写异议处理话术，每项提供的方案都必须事先获批。
4. 明确升级阶梯——四个层级，且都是真人。
5. 在 Level 3，添加渠道合作伙伴简报，并通过角色扮演开展现场培训。

在此阶段运行 eol-internal-enablement。

交付物

• 与级别相匹配的赋能资料包
• 销售代表在周五下午 4 点也能使用的升级阶梯
• 在公开通知前向合作伙伴做好简报（Level 3）

决策点 4：赋能工作真的完成了吗？

这是公告发布的前置条件。 EOL 沟通中最严重的失误，就是在客户收到公告前五分钟才把公告交给支持和销售团队。

测试方法：问一位销售代表，客户扬言要流失时应该联系谁；再让他大声回答最棘手的异议。如果任一问题的回答都只是耸耸肩，那就还没准备好发布公告。

---

阶段 5：公告

问题： 客户会听到什么，什么时候听到？

活动

1. 确定消息篇幅：简短版、标准版或完整版。
2. 选择路径：替换、迁移或平稳退出——每种路径对应不同的消息。
3. 按照九部分框架起草，先承认影响，再介绍收益。
4. 用客户能理解的后果说明各个关口，不要使用内部缩写。
5. 执行便利贴测试：读一遍后，客户能否写下要做什么以及截止时间？
6. 在必要时按客户群体细分——企业客户、中小企业、存在流失风险的客户以及合作伙伴需要不同的信息。

在此阶段运行 eol-message。

交付物

• 确定篇幅和路径的客户公告
• 必要时提供不同客户群体的版本
• 覆盖各个关口的沟通日历，而非只发送一次

决策点 5：公告经得起实际检验吗？

发送前，检查以下三点：

• 法务已审阅——尤其是涉及合同、退款或认证的内容
• 内容不与客户已购买的承诺相矛盾——对照阶段 2 的一线承诺进行检查
• 支持团队先拿到公告——并留出充足时间阅读

---

阶段 6：收尾

问题： 我们完成了吗？又学到了什么？

活动

1. 随着各关口到来逐一推进。每次转换都必须满足相应标准，并取得审批人的签字确认——关口代表承诺，不是日历上的事项。
2. 对照阶段 3 的目标跟踪迁移或过渡进度。尽早升级处理毫无进展的客户，不要等到最后一个关口才处理。
3. 完成收尾事项：遵守数据导出期限、安排数据删除、结清合同、结束收入确认、停用基础设施、归档文档。
4. 开展经验总结。 有什么出乎意料？哪个阶段投入不足？难应对的客户发现了哪些我们遗漏的问题？实际留存率与预测相比如何？
5. 对于尚未安排 EOL 日期的情况，将前置条件交接给指定负责人，并设定复查日期。

交付物

• 已关闭并完成签字确认的关口
• 最终留存率或过渡数据与预测的对比
• 书面经验总结
• 明确指定负责人的所有延期决策

决策点 6：真的收尾了吗？

收尾不等于停用日期。只有在数据已删除或交付、合同已结清、收入已确认，并且有人记录了整个过程时，才算真正收尾。如果尚未开展复盘，日落流程就还没结束——只不过暂时没了动静。

---

完整工作流：端到端总结

PHASE 1: DECIDE                          -> eol-readiness-advisor
  Trigger -> signals -> intensity level -> landing place
  DP1: Go / Go-with-conditions / Hold / Harvest
       Landing place not ready? Phases 2-4 OK, Phase 5 blocked
       |
PHASE 2: ALIGN                           -> eol-stakeholder-sequence
  Legal -> Finance -> Sales -> Marketing -> CS -> difficult customers
  -> Engineering -> Support  (+ Execs, Channel, Regulatory at L3)
  DP2: Did anything invalidate the decision?  --[yes]--> back to Phase 1
       |
PHASE 3: PLAN                            -> eol-checklist
  Gates in scope -> items with owners -> gate criteria -> data,
  contracts, access, money -> enablement date BEFORE announce date
  DP3: Every item owned? Every date real?
       |
PHASE 4: PREPARE                         -> eol-internal-enablement
  Support FAQ -> sales points with gaps -> objections (offers
  pre-approved) -> escalation ladder -> channel brief + training (L3)
  DP4: Enablement complete?  --[no]--> DO NOT ANNOUNCE
       |
PHASE 5: ANNOUNCE                        -> eol-message
  Size -> path -> draft -> sticky-note test -> segment -> comms calendar
  DP5: Legal read it? Consistent with field promises? Support has it?
       |
PHASE 6: CLOSE                           -> (this skill)
  Walk gates -> track progress -> close data/contracts/money ->
  LESSONS-LEARNED REVIEW -> own any deferred decisions
  DP6: Data settled, contracts closed, review written?

Level 1 精简方案： 阶段 2、3 和 4 往往会合并为一次会议——准备一份简短的利益相关者名单、一份待办事项清单和一份支持常见问题。阶段 1、5 和 6 仍然要执行，尤其是阶段 6。

---

示例

• examples/sample.md — Fieldlight Classic Dispatch（SaaS，级别 2，六个阶段历时十个月全部完成）
• examples/sample-industrial.md — NFA-200 控制器产品线（工业领域，级别 3，阶段 2 会将流程退回阶段 1 并改变结果）

---

常见陷阱

陷阱 1：从阶段 5 开始

症状： 团队着手构建的第一份材料就是客户公告。

后果： 公告发布后，你才发现合同条款、对客户的承诺和缺失的迁移路径有问题——而且消息已经公开，日期也已承诺。

解决方法： 公告之所以是第五阶段，自有其道理。前面的所有工作都是为了让公告发布后能够妥善应对。

---

陷阱 2：把决策点 2 当成走过场

症状： 与利益相关者沟通，记录调查结果，计划却原封不动地继续执行。

后果： 你进行了沟通却置之不理，这比跳过沟通更糟——现在有亲历者可以证明他们曾警告过你。

解决方法： DP2 是一道真正的关卡。如果法务或难以应对的客户提出了重大问题，就退回阶段 1 重新评估。这个循环正说明流程正在发挥作用。

---

陷阱 3：在做好准备之前就发布公告

症状： 阶段 4 和阶段 5 在同一周完成，或者阶段 4 延误而阶段 5 未作调整。

后果： 支持团队只能临时应对三天，而他们临时想出的办法会变成事实上的政策，且执行不一。

解决方法： DP4 应根据计划为 DP5 把关，并分别设定日期。如果准备工作延误，公告也应延后。

---

陷阱 4：为小规模退役走形式

症状： 一个已弃用的功能也要经过十轮利益相关者沟通和一套培训计划。

后果： 大家会觉得 EOL 流程就是官僚主义，下次就会跳过——而下次涉及的可能就是合同。

解决方法： 在阶段 1 如实确定级别。级别 1 的退役如果能在一个下午内完成并妥善收尾，就是成功。

---

陷阱 5：跳过阶段 6

症状： 产品停用，团队转向其他工作，没人留下任何记录。

后果： 下一次退役会重蹈所有覆辙，数据删除和合同终止事项也会悄悄被搁置。

解决方法： 趁大家还在关注时，就把复盘列入阶段 3 的检查清单，并指定负责人。收尾不等于停用日期。

---

陷阱 6：产品退役时也失去了客户

症状： 每个阶段都执行得很到位，却只用内部完成情况来衡量成效。

后果： 产品顺利退役，客户流失却激增。流程执行得很好，关系却依然流失。

解决方法： 用客户留存率衡量结果，而不是检查清单的完成情况。目标是在失去产品的同时不失去客户——如果后半部分没做到，流程就没有成功。

---

参考资料

相关技能

以下每项技能都可以独立使用。此流程会建议一条使用路径；这些技能都不依赖本技能，本技能也不要求你全部使用。通过说“级别 2”并粘贴现有内容，在各阶段之间传递上下文。

• eol-readiness-advisor — 阶段 1
• eol-stakeholder-sequence — 阶段 2
• eol-checklist — 阶段 3
• eol-internal-enablement — 阶段 4
• eol-message — 阶段 5
• workshop-facilitation — 全流程中的互动协议
• positioning-statement — 阶段 5 的转型解决方案
• stakeholder-map — 通用利益相关者梳理；如果阶段 2 需要先扩大范围，可使用此技能

外部框架

• 产品生命周期（PLC）——EOL 处于衰退阶段
• 行业 EOL 生命周期实践（GA/NSC/EOS/EOE/EOR/EOM/EOL/EOSRV）
• 认可-重新解读-提供方案——阶段 4 的异议处理

来源

• 编排 https://github.com/deanpeters/product-manager-prompts 仓库中的 EOL 提示词系列。