eol-readiness-advisor

EOL 准备度顾问

目的

判断是否真的应该停用某个产品或功能；如果应该停用，还要决定这项工作值得投入多少精力。本技能会给出继续／不继续的结论、列明证据、由你选择的强度级别，以及一份简短清单，列出忽视后会让你付出代价的义务。

大多数 EOL 指南都假设决定已经做出，直接进入计划。本技能着眼于更早的阶段：在这场对话中，“我们大概应该砍掉它”会变成一个有人能在会议上据理力争的决定。

它也同样愿意告诉你不要停用。“暂缓”或“维持运营”的结论在这里都是实际结果，不是安慰奖。

输入

最适合提供： 正在评估的产品或功能，以及引发这场讨论的原因（使用量下降、战略转变、支持成本方面的抱怨、高管随口提到等）。

也很有帮助： 营收和客户数量、是否已有替代方案、合同或法规承诺，以及你已知的任何政治敏感因素。

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

手头没有信息？也没关系。 技能会先询问评估对象和原因，然后逐个问题引导你梳理影响范围、强度和过渡路径。你不必事先准备好数据——“我不知道”也是有效回答，最终会作为标注过的假设写入结论。

调用示例：

• 我们应该停用旧版报表模块吗？使用量下降了 60%，支持成本也在上升。
• 对我们的 NFA-200 控制器产品线进行 EOL 准备度检查——已安装 120 台，有渠道合作伙伴，已获 UL 认证。

---

核心概念

规模调节盘

EOL 的实施方式并非千篇一律。 有些只需更新一条变更日志并准备一条支持回复模板；有些会让全公司忙上三个季度。大多数则介于两者之间。EOL 最常见的失败情况，无论轻重，都是退场规模与应对规模不匹配——旗舰产品退场只当作一张 Jira 工单处理，或一个功能弃用却成立了指导委员会。

因此，强度是由你设定的调节盘，不是框架给出的结论：

维度	级别 1 — 轻量	级别 2 — 标准	级别 3 — 重量
典型范围	功能、内部工具、未版本化的 API	有活跃客户的商业产品	营收关键型产品、硬件、受监管产品
利益相关方环节	3-4	7-8	10+
使用的生命周期关卡	2-3（NSC、EOS、EOL）	4-5（NSC、EOS、EOE、EOM、EOL）	全部 8 个（从 GA 到 EOSRV）
涉及的职能领域	产品、工程、支持、文档	+ 销售、营销、客户成功、财务、法务、IT、数据	+ 供应链、渠道、监管、组织
支持准备	仅支持 FAQ	+ 销售沟通要点、异议应对、升级处理	+ 渠道简报、客户分级、培训
客户通知	简短通知	含阶段表的标准通知	含合规章节的完整通知
典型提前期	数周	6-12 个月	12-24 个月

大多数退场适合采用级别 2。 将其视为默认级别，再说明选择更高或更低级别的理由。

调节盘由你掌控。 推荐一个级别并解释理由，然后让用户自行决定调高或调低，之后也可以再次调整。如果 PM 说“给我轻量版，我了解自己的组织”，这是在行使判断力，并非犯错。请尊重这一选择，并用一句话说明较轻级别无法覆盖哪些事项，让用户在充分知情的情况下做出选择，而不是盲目决定。

生命周期关卡（通用词汇）

EOL 不是一个日期，而是一系列关卡。客户的大多数不满，都源于把它们合并成一则公告：

• GA（正式发布）： 正在积极销售并获得全面支持
• NSC（状态变更通知）： 对外传达决策；开始规划
• EOS（停止销售）： 不再接受新客户购买
• EOE（停止扩容）： 现有客户不能增加容量或席位
• EOR（停止续约）： 不再续签现有合同
• EOM（停止维护）： 停止提供错误修复和补丁
• EOL（生命周期终止）： 产品退役
• EOSRV（停止服务）： 所有支持和服务义务终止

轻量级退场会用到其中三项，全面退场会用到全部八项。明确说明不采用哪些关卡，和说明采用哪些关卡一样有用。

四项退役信号

支持作出推进退役判定的证据。若其中两项或更多信号明显存在，就构成了充分理由：

1. 财务可行性——成本超过收入；支持负担耗费了不成比例的资源
2. 战略一致性——与公司方向冲突；你们正在退出这个市场
3. 解决方案替代——内部后继产品取代了它；你们正在整合平台
4. 市场无关性——需求已变化、技术已发展、核心问题已不复存在

四项暂缓信号

即使退役信号很强，这些证据也表明现在不应退役：

1. 义务约束——合同、SLA、监管承诺或“终身”承诺仍然有效
2. 战略牵制——收入不高，但产品存在于你们最重要的客户中
3. 无处可迁——没有替代方案，也没有第三方替代品；客户将无所适从
4. 退出成本高于维持成本——退场的成本高于再安稳维护一年

反模式（本技能不是什么）

• 不是橡皮图章。 如果暂缓信号占主导，结论就是暂缓，本技能会明确说明。
• 不是产品组合筛查。 本技能评估单个产品。筛查产品目录是另一项工作。
• 不是计划。 结论和强度等级是规划的输入，而非计划本身。
• 不是财务模型。 本技能会定性分析收入和成本，但不会进行预测。

---

应用

默认使用 workshop-facilitation 作为本技能的交互协议。

本技能会提出最多 4 个自适应问题，然后给出结论、强度等级和编号的后续步骤。开始时先告知对方：会有四个问题，大约需要十五分钟；他们可以随时补充背景信息，以跳过提问。

---

问题 1（共 4 个）——正在审查什么？是什么触发了这次审查？

Agent 询问：

“正在考虑终止生命周期（EOL）的产品或功能是什么？是什么让大家开始讨论这件事？触发因素和产品本身同样重要——指标下滑、战略转变、对支持成本的抱怨，以及高管随口一提，都会导向截然不同的评估。”

现在就该讨论退役吗？ 此技能评估的是一种做法：退役。在成熟期转入衰退期的拐点，有三种选择——延长产品生命周期、用后继产品替代，或将其退役。如果用户尚未确定退役是要采取的做法，请指出这一点，并提供上游诊断：

“在评估退役之前——你们已经决定要退役了吗？还有另外两种选择（延长产品生命周期，或用后继产品替代），lifecycle-play-advisor 可以帮你判断哪种更合适。如果已经决定了，我很乐意继续在这里进行评估。”

不要强行引导用户绕道。如果用户说“我们已经决定了，请评估退役方案”，就进行评估。

留意触发因素的类型，因为它预示着可能出现的问题：

触发因素	需要留意
指标下滑	这是实际下滑，还是季节性波动／测量方式变化？
战略转变	产品与战略不再契合，还是只是不再时髦？
支持成本	解决办法是退役，还是修复漏洞？
高管发言	有证据支持吗？还是只是一个带头衔的观点？
替代产品已发布	对这些客户而言，替代产品真的已达到功能对等吗？

如果触发因素是没有证据支持的高管发言，请在给出结论时直言不讳。这是导致产品过早被淘汰的最常见原因。

---

问题 2（共 4 个）——影响范围有多大？

Agent 询问：

“请帮我估算影响范围。大致数字就可以，回答‘我不知道’也完全可以：

1. 客户： 有多少账户或用户在使用它？
2. 收入： 大致占多少收入？收入是否集中在少数几个账户？
3. 承诺： 是否涉及合同、SLA、续约日期或监管义务？
4. 实物或渠道： 是否涉及硬件、库存、备件，或有合作伙伴在转售？”

说明为什么要了解这些（请明确说出来）： 这四项回答决定了应采取的工作强度。第 3 项最常让一次“简单的”产品退市变成法律问题——特意把它放在前面询问。

将任何未知项标记为假设，并在结论中注明。不要为了追查某个数字而让流程停滞；带有三条明确标注的假设的评估，也好过始终没有完成的评估。

---

问题 3（共 4 个）——确定工作强度

Agent 先给出建议，然后让用户选择强度：

“根据你的描述，我对所需工作量的判断如下：

建议：级别 [N] — [轻量／标准／重型] 原因：[从用户的回答中提取两三项具体依据]

1. 级别 1 — 轻量。 待办清单、3-4 位利益相关者、简短通知。适用于影响范围仅限内部，或用户数量很少且容易联系的情况。
2. 级别 2 — 标准。 跨职能检查清单、7-8 位利益相关者、分阶段的客户沟通。适用于有实际客户、没有监管牵连的商业产品。大多数退市工作都属于这一类。
3. 级别 3 — 重型。 完整方案手册、10 位以上利益相关者、涵盖全部八个关卡，并包含渠道和监管工作流。适用于收入至关重要、硬件已投入使用，或涉及合规要求的情况。

你可以接受这个建议，也可以选择其他级别——你更了解自己的组织。之后也可以调整；后续工作不会因这项选择而锁定。”

如果用户调低强度， 接受该选择，并补充一句：“低于建议级别会导致 [具体未覆盖的事项——通常是法务审查、渠道通知或迁移支持] 未得到处理。先提醒你，这样的选择就不会让你感到意外。”

如果用户调高强度， 不要争辩，直接接受。为 EOL 做过度准备，代价很小。

---

第 4 个问题（共 4 个）——客户会去哪里？

Agent 询问：

“使用它的人会怎么样？大致有三种走向：

1. 替换——由你的另一款产品接手
2. 迁移——他们转到不同的配置、层级或平台
3. 平稳退出——没有产品接替；他们需要数据、通知和替代方案

属于哪一种？这条路径目前准备得如何？”

路径准备情况是决定是否推进的依据，而非细节。 如果替换产品尚未达到这些特定客户所需的功能平价，它就还不是可行的去处。如果路径尚未准备就绪，结论通常是“推进，但等到满足[具体准备条件]后再发布公告”。

---

最后一步：给出评估结果

按以下结构生成：

## EOL Readiness Assessment: [Product]

**Verdict:** [Go / Go-with-conditions / Hold / Harvest]
**Intensity:** Level [N] — [Light/Standard/Heavy] *(user-selected)*
**Confidence:** [High/Medium/Low] — based on [what's known vs. assumed]

### The Case to Retire
- [Retire signal + the evidence behind it]

### The Case Against (or: Conditions)
- [Hold signal + the evidence behind it]

### Assumptions I Made
- [Anything answered "I don't know," stated plainly]

### Obligations to Check Before Announcing
- [Contracts, SLAs, regulatory, "lifetime" promises, channel agreements]

### Landing Place
- **Path:** [Replacement / Migration / Graceful exit]
- **Readiness:** [Ready / Gap: specific gap / Not started]

### What This Level Covers — and Doesn't
- Covers: [gates, stakeholder count, artifacts implied by the level]
- Does not cover: [what the level deliberately skips]

然后提供编号的后续步骤：

“你接下来想做什么？

1. 制定运营计划——Level [N] 停用的分阶段检查清单
2. 梳理利益相关方沟通——与谁沟通、按什么顺序，以及每次沟通必须涵盖什么
3. 为内部团队做好准备——支持 FAQ、销售沟通要点、异议处理
4. 起草客户公告——参见 eol-message
5. 用更准确的数据重新进行评估，前提是你已查明未知信息

选择一个数字，将它们组合起来（“2 和 4”），或告诉我你更想做什么。”

关于结论名称：

• 推进——停用；理由明确
• 有条件推进——停用，但公告发布前必须满足某项具体条件
• 暂缓——目前不要停用；暂缓信号占主导；设定明确的触发条件，届时重新评估
• 收割——既不停用，也不投入；以精简方式运营，获取剩余收入，并设定复审日期
• 延展——不要停用；产品仍有发展空间。当暂缓信号占主导，且压力最终被证实来自需求侧或分销侧时得出此结论——例如可以通过变体服务的客户群，或被产品问题掩盖的渠道与定价问题。交由 lifecycle-play-advisor 评估这一策略的规模

暂缓和延展代表不同的评估结果。 暂缓表示不是现在；延展表示这款产品仍有可行的行动方案。不要混为一谈——被告知“暂缓”的 PM 会等待，被告知“延展”的 PM 会采取行动。

---

示例

示例 A — SaaS，根据建议下调级别

PM：“我们应该停掉 Fieldlight Classic 吗？它是我们的旧版调度模块。管理层已经暗示了两个季度。”

Agent（Q1）：“这些暗示是由什么引发的——某项指标、战略调整，还是成本方面的抱怨？”

PM：“支持工单。Classic 产生的支持量约占 40%，但收入可能只占 15%。而且我们去年推出了 Fieldlight Next。”

Agent（Q2）：“影响范围有多大——客户、收入、承诺，以及任何渠道或硬件方面的影响？”

PM：“大约 800 个账户，ARR 为 240 万美元。年度合同，标准条款，没有监管要求。纯 SaaS，直接销售。”

Agent（Q3）：“建议：级别 2 — 标准。 800 个账户、年度合同和实际收入意味着需要分阶段沟通和跨职能检查清单，但没有监管或渠道方面的工作流，因此不需要采用最重的方案。[展示三个级别]”

PM：“说实话，我们只有 40 人。给我级别 1。”

Agent：“按级别 1 执行。这里选择更轻的方案，意味着跳过对续约日期相关措辞的正式法务审查，以及分阶段的销售赋能工作——面对 800 份年度合同，我最不希望看到遗漏的就是续约日期。先提醒你，这样做是主动选择，而不是意外。要不要保留级别 1，再加一项法务检查？这是常见的折中方案。”

PM：“好，就这么办。”

Agent（Q4）：“这 800 个账户将转向哪里——Fieldlight Next，还是其他方案？”

PM：“转到 Next。除了大约 30 个账户使用的自定义调度规则外，功能都已持平。”

**结论：**可以推进，但需满足条件。级别 1 + 法务检查。条件：公告前必须为使用自定义规则的 30 个账户制定明确方案，否则他们会成为升级处理队列。已标注的假设：支持量数据来自记忆，并非实际提取的数据。

---

示例 B — 工业产品，上调级别，最终暂缓

PM：“我们想停产 NFA-200 改造控制器。NFA-500 已经上市，制造部门希望腾出生产线。”

Agent（Q1）：“所以触发因素来自内部——制造产能加上已推出的继任产品。客户方面有任何信号吗？还是这完全是供应侧的决定？”

PM：“完全是供应侧的决定。客户对 200 很满意。”

Agent（Q2）：“影响范围有多大——已安装设备、收入、承诺、硬件和渠道？”

PM：“大约 120 套已安装设备。八家渠道合作伙伴在转售。部分服务合同持续到 2028 年。产品通过了 UL 和 CE 认证。还有备件库存。”

Agent（Q3）：“建议：级别 3 — 重型。 服务合同持续到 2028 年、八家渠道合作伙伴、监管认证和实体备件——这是四项独立工作流，较轻的级别无法涵盖。”

PM：“同意，级别 3。”

Agent（Q4）：“这 120 套已安装设备将转向哪里？NFA-500 能否直接替换现有的 NFA-200？”

PM：“不完全行。500 需要不同的安装支架，而且改造情况嘛……每套都得上门处理。”

**结论：**暂缓。 停产信号确实存在，但完全来自供应侧。与之相对的是：服务合同持续到 2028 年（义务锁定），而且没有可直接替换的方案——120 次现场上门并不是迁移路径，而是需要单独拨款的项目。客户并没有提出这项要求。

建议改为：立即 EOS，稍后 EOL。 停止销售 NFA-200，在合同到期前继续提供服务，并为支架和改造工作拨款，将其作为实际的前置条件。待改造方案落实或合同逐步到期后再重新评估——以先发生者为准。EOS 后制造部门就能腾出生产线，这才是真正的诉求。

注意，这项结论将表面问题（停产该产品）与根本问题（腾出生产线）区分开来——并以更低成本解决了后者。

---

常见陷阱

陷阱 1：带头衔的意见

症状： 整个案例都基于某位高管的一句“我们应该砍掉那个东西”。

后果： 你花两个季度退役一个一直悄悄盈利的产品，等客户流失出现时，却没人记得这是谁的主意。

解决方法： 在评估中明确写出触发因素。如果证据只有一句话，结论应是“暂缓——等待证据”，而不是“推进”。

---

陷阱 2：一刀切地日落

症状： 每个 EOL 都采用相同处理方式——要么所有事情都走工单流程，要么所有事情都交给指导委员会。

后果： 轻量级日落会在繁文缛节上耗尽政治资本。重度日落则会引发公开危机。

解决方法： 有意设定工作强度，明确说出来，并指出所选级别会略过哪些事项。

---

陷阱 3：跳过义务核查

症状： 影响范围只按客户和收入衡量；没人询问合同和认证。

后果： 有记录以来最严重的 EOL 失败都出在法律层面，而非商业层面——因硬件“终身”承诺而下令退款，因退役服务没有充分替代方案而遭罚款。

解决方法： 询问承诺事项时，同时询问收入。这是第 2 个问题，自有其原因。

---

陷阱 4：把“没有替代方案”当作小事

症状： 结论是推进，而后续安排却是“客户会自己找办法”。

后果： 你不是在退役产品，而是在赶走客户。他们会记住这件事。

解决方法： 妥善退出是合理的路径——但这需要数据导出、更长的通知期和诚实的替代方案。如果这些都尚不存在，结论就应是“有条件地推进”。

---

陷阱 5：只解决表面问题

症状： 有人提出退役产品的请求；评估就只评估退役产品。

后果： 你启动了完整的日落流程，而实际需求本可以通过停止销售、涨价或修复缺陷来满足。

解决方法： 询问触发因素背后的真正原因。“腾出生产线”可以通过 EOS 解决，而不是 EOL。发现更低成本的解决方案时，就明确指出。

---

参考资料

相关技能

以下每项都可以独立使用——都不要求先运行此技能，此技能也不是其中任何一项的前置条件。如果你确实运行了这项评估，只需在开始时说“Level 2”，沿用相同的工作强度级别即可；无需保留任何交接格式。

• eol-message — 面向客户的公告
• incoming-request-advisor — EOL 请求以消息形式到达、需要先解读时使用
• stakeholder-map — 通用利益相关者映射
• business-health-diagnostic — 触发因素与财务有关，且你希望妥善分析相关数据时使用
• workshop-facilitation — 互动流程

外部框架

• 产品生命周期（PLC）——EOL 决策属于衰退阶段
• Mendelow 矩阵——按权力／关注度对利益相关者进行优先级排序

来源

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