eol-checklist

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

EOL Checklist

EOL检查清单

Purpose

目的

Turn a sunset decision into a phase-gated operational plan: what must happen, in which lifecycle phase, and who owns it. The output is a working checklist — sticky-note-sized items, each with a verb and a named function — not a strategy document.

The checklist is sized to the sunset. A deprecated internal tool gets a dozen items across three phases. A regulated hardware line gets a cross-functional playbook across six phases with gate criteria between them. Both are correct; using the wrong one is the failure.

将产品退役决策转化为分阶段的操作计划：明确必须完成的事项、所属生命周期阶段以及负责人。输出结果是一份可落地的检查清单——每个事项都是便签大小的条目，包含动词和指定职能角色——而非战略文档。

检查清单的规模与产品退役的复杂度匹配。一款已废弃的内部工具可能只需要涵盖3个阶段的十几个条目；而受监管的硬件产品线则需要一份跨6个阶段、包含阶段准入标准的跨职能执行手册。两种形式都是合理的，错误地使用不匹配的规模才是问题所在。

Input

输入信息

Works best with: The product being sunset and any dates you're already committed to.

Also useful: Customer and revenue scale, whether a replacement exists and how ready it is, contract or regulatory obligations, and whether hardware, inventory, or channel partners are in play.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended

ARGUMENTS:

line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks up to three questions — what's being sunset and at what scale, whether there's a replacement, and what hard deadlines exist — then picks a level and builds. Unknowns become labeled assumptions rather than blockers.

Example invocations:

EOL checklist for our legacy reporting module, shutting down Dec 31, ~400 accounts.

Build the heavy checklist for a hardware retirement — service contracts, 8 resellers, UL certified.

最适配的输入： 即将退役的产品以及已确定的相关日期。

有用的补充信息： 客户规模与收入情况、是否存在替代产品及替代产品的就绪度、合同或监管义务，以及是否涉及硬件、库存或渠道合作伙伴。

调用技能时提供的任何信息——技能名称后的文本、粘贴的上下文内容，或附加的

ARGUMENTS:

行——都视为已提供的答案，直接使用即可，无需重复询问。

完全没有输入信息也可以： 该技能最多会提出三个问题——退役的产品是什么、规模如何，是否有替代产品，以及存在哪些硬性截止日期——然后选择合适的规模级别并构建检查清单。未知信息会被标记为假设，而非阻碍项。

调用示例：

EOL checklist for our legacy reporting module, shutting down Dec 31, ~400 accounts.

Build the heavy checklist for a hardware retirement — service contracts, 8 resellers, UL certified.

Key Concepts

核心概念

Right-Size Before You Build

先匹配规模再构建

Not all EOLs play out the same. Most land in the middle. Pick the level deliberately:

	Level 1 — Light	Level 2 — Standard	Level 3 — Heavy
Typical scope	Feature, internal tool, unversioned API	Commercial product, active customers	Revenue-critical, hardware, regulated
Phases used	2-3 (NSC, EOS, EOL)	4-5 (NSC, EOS, EOE, EOM, EOL)	All 6 (NSC through EOSRV)
Functional areas	4	11	15
Gate criteria	Not needed	Between major phases	Between every phase, with approvers
Output feel	Punch list	Working checklist with owners and dates	Cross-functional playbook

Level 2 is the default. Recommend a level, say why in one line, and let the user move it. If they go lighter, name the specific area that drops out so the choice is informed. Never default to Level 3 — a heavy checklist applied to a light sunset teaches teams that EOL process is ceremony, and they'll skip it next time when it matters.

The level is yours to change mid-build. "Actually make this heavier" is a normal thing to hear after the Legal row surfaces something.

并非所有产品退役流程都相同，大多数处于中等复杂度。需谨慎选择规模级别：

	Level 1 — 轻量化	Level 2 — 标准型	Level 3 — 重型
典型范围	功能模块、内部工具、无版本API	商业化产品、活跃客户	收入核心型产品、硬件、受监管产品
使用的阶段	2-3个（NSC、EOS、EOL）	4-5个（NSC、EOS、EOE、EOM、EOL）	全部6个（NSC至EOSRV）
职能领域	4个	11个	15个
阶段准入标准	无需	主要阶段之间设置	每个阶段之间均设置，并指定审批人
输出形式	任务清单	包含负责人和日期的可执行检查清单	跨职能执行手册

Level 2为默认级别。先推荐一个级别，用一句话说明理由，再让用户自行调整。如果用户选择更轻量化的级别，需明确说明会省略的具体领域，确保用户的选择是知情的。切勿默认使用Level 3——将重型检查清单用于轻量化退役流程，会让团队认为EOL流程只是形式主义，下次遇到真正重要的退役时就会跳过流程。

在构建过程中可以随时调整级别。比如当法务团队提出新问题后，“实际上需要调整为更重型的清单”是很常见的需求。

The Lifecycle Gates

生命周期阶段节点

GA (General Availability): Actively sold and fully supported
NSC (Notice of Status Change): The decision is communicated; planning begins
EOS (End of Sale): No new customers can purchase
EOE (End of Expansion): Existing customers cannot add capacity or seats
EOR (End of Renewal): Existing contracts will not be renewed
EOM (End of Maintenance): Bug fixes and patches stop
EOL (End of Life): The product is retired
EOSRV (End of Service): All support and service obligations end

Which of these become checklist phases: GA is a state, not a phase of work — nothing is checklisted there. EOR is contract-driven and only appears when renewals are in play. So working checklists usually span the six actionable phases: NSC, EOS, EOE, EOM, EOL, EOSRV, with EOR inserted when subscription or service contracts run past EOS.

Naming the gates you're not using is as useful as naming the ones you are. A Level 1 checklist should say "EOE and EOSRV don't apply — nothing to expand, nothing to service."

GA (General Availability)： 产品处于活跃销售和全面支持状态
NSC (Notice of Status Change)： 发布退役决策通知，启动规划工作
EOS (End of Sale)： 停止新客户购买
EOE (End of Expansion)： 现有客户无法扩容或增加席位
EOR (End of Renewal)： 现有合同不再续约
EOM (End of Maintenance)： 停止bug修复和补丁更新
EOL (End of Life)： 产品正式退役
EOSRV (End of Service)： 所有支持和服务义务终止

哪些节点会成为检查清单的阶段： GA是一种状态，而非工作阶段，因此不会纳入检查清单。EOR由合同驱动，仅在涉及续约时才会出现。因此，可执行的检查清单通常涵盖6个可操作阶段：NSC、EOS、EOE、EOM、EOL、EOSRV，当订阅或服务合同期限超过EOS时，需插入EOR阶段。

明确说明未使用的节点与明确使用的节点同样重要。Level 1检查清单应注明“EOE和EOSRV不适用——无扩容需求，无服务义务”。

The Fifteen Functional Areas

15个职能领域

Filtered by level. The parenthetical marks the lowest level where each appears:

Area	Level
Product and Strategy	1
Engineering and Technical	1
Support	1
Documentation and Training	1
Legal and Contractual	2
Financial Planning	2
Sales	2
Marketing	2
Customer Success	2
IT Systems	2
Data Management	2
Inventory and Supply Chain	3
Channel and Partner Management	3
Regulatory and Compliance	3
Internal Organizational Alignment	3

根据级别筛选，括号内为该领域首次出现的最低级别：

领域	级别
产品与战略	1
工程与技术	1
客户支持	1
文档与培训	1
法务与合同	2
财务规划	2
销售	2
营销	2
客户成功	2
IT系统	2
数据管理	2
库存与供应链	3
渠道与合作伙伴管理	3
监管与合规	3
内部组织对齐	3

The Sticky-Note Rule

便签规则

Every item is 4 to 8 words, names a verb, and carries a named owner (a function, not a person's calendar). "Legal reviews contracts" is an item. "Ensure appropriate review of all relevant contractual obligations across the customer base" is a paragraph wearing a checkbox.

Why the owner is mandatory: an unowned item is a wish. Forcing a function onto every line surfaces cross-functional gaps early — when you can't name who owns "notify channel partners," you have just discovered that nobody does.

每个条目需满足4-8个单词，包含一个动词，并指定负责人（职能角色，而非具体个人）。例如“法务审核合同”是合格的条目，而“确保对客户群中所有相关合同义务进行适当审核”则是伪装成复选框的段落。

为何必须指定负责人： 无人负责的条目只是空想。强制为每个条目指定职能角色，能尽早暴露跨职能缺口——当你无法确定“通知渠道合作伙伴”的负责人时，就意味着你发现了一个无人负责的工作。

Phase Gates Are Commitments, Not Dates

阶段节点是承诺，而非日期

A phase gate is what must be true before you advance, with an approver. "EOS to EOE: last-time-buy orders closed — Approver: Sales VP." This is what stops an EOL from being one announcement followed six months later by somebody quietly pulling a plug.

阶段节点是进入下一阶段必须满足的条件，并需指定审批人。例如“从EOS到EOE：最后一次采购订单关闭——审批人：销售副总裁”。这能避免EOL流程变成仅发布一次通知，六个月后有人悄悄关停服务的情况。

Anti-Patterns (what this is NOT)

反模式（本工具不适用的场景）

Not a project plan. No Gantt, no dependencies graph, no resource loading.
Not exhaustive by default. Coverage proportional to risk, not maximum ceremony.
Not the decision. If the sunset itself is still in question, this is premature.
Not a substitute for the conversations. A checklist item saying "align with Legal" is not alignment with Legal.

不是项目计划：不包含甘特图、依赖关系图或资源负载规划。
默认不追求面面俱到：覆盖范围与风险成正比，而非追求形式主义。
不是决策工具：如果产品退役的决策尚未确定，使用本工具为时尚早。
不能替代沟通：检查清单中“与法务对齐”的条目，并不等同于实际完成了与法务的对齐工作。

Application

应用步骤

Step 1: Set the level

步骤1：确定规模级别

Recommend from blast radius — customers, revenue, contracts, hardware, partners — then present all three and let the user choose. If the level is genuinely unclear, ask:

"How complex is this sunset?

Light — a feature, internal tool, or unversioned API. Few users, all reachable.
Standard — a commercial product with paying customers and contracts.
Heavy — revenue-critical, hardware in the field, channel partners, or regulated.

Most sunsets are Standard. Which sounds like yours?"

根据影响范围——客户、收入、合同、硬件、合作伙伴——推荐级别，然后展示三个级别供用户选择。如果级别确实不明确，可询问：

“本次产品退役的复杂度如何？

轻量化——功能模块、内部工具或无版本API，用户数量少且均可触达。
标准型——有付费客户和合同的商业化产品。
重型——收入核心型产品、已投入使用的硬件、涉及渠道合作伙伴或受监管产品。

大多数产品退役属于标准型。你的情况更符合哪一种？”

Step 2: Select phases in scope

步骤2：选择涵盖的阶段

Map the level to phases, then check for the two overrides:

Contracts running past EOS? Insert EOR.
No service obligations at all? Drop EOSRV and say so.

If a date is genuinely unknown, write

TBD

— and if a date shouldn't be set yet (no migration path exists), write

Not scheduled

and add an item naming the precondition. An invented EOL date is a promise you will break in public.

根据级别匹配对应的阶段，然后检查两个例外情况：

合同期限超过EOS？ 插入EOR阶段。
完全无服务义务？ 删除EOSRV阶段并说明原因。

如果日期确实未知，填写

TBD

——如果日期暂时不应确定（例如迁移路径尚未存在），填写

Not scheduled

并添加一个条目说明前置条件。随意设定EOL日期相当于公开做出一个会被打破的承诺。

Step 3: Build items per phase, per area

步骤3：按阶段和领域构建条目

For each phase in scope, walk the functional areas warranted by the level. Each item:

Starts with a verb
Is 4 to 8 words
Names an owning function
Belongs to exactly one phase — the phase where the work happens, not where it's announced

Cover, at minimum, the four things sunsets most often strand:

Data — export format, availability window, deletion schedule
Contracts — renewal language, SLA terms, refunds or credits owed
Access — API keys, integrations, SSO, downstream systems that read from it
Money — forecast adjustment, revenue recognition, cost of the sunset itself

针对每个涵盖的阶段，遍历对应级别下的职能领域。每个条目需：

以动词开头
长度为4-8个单词
指定负责职能
仅属于一个阶段——即工作执行的阶段，而非发布通知的阶段

至少需覆盖产品退役最常遗漏的四个方面：

数据——导出格式、可用窗口期、删除时间表
合同——续约条款、SLA条款、应退款或抵扣金额
访问权限——API密钥、集成、SSO、依赖该产品的下游系统
财务——预测调整、收入确认、产品退役的成本

Step 4: Write gate criteria (Level 2+)

步骤4：编写阶段准入标准（Level 2及以上）

For each phase transition, list what must be true and who signs. Three to five criteria per gate is plenty. If you can't name an approver, the gate isn't real.

针对每个阶段转换，列出必须满足的条件和审批人。每个节点3-5条标准即可。如果无法指定审批人，说明该节点并非真正的准入节点。

Step 5: Post-EOL actions and assumptions

步骤5：退役后行动与假设

Always include a short post-EOL block — archival, final report, and a lessons-learned review. The review is the item teams cut first and regret most; the next sunset is always easier when someone wrote down what surprised you in this one.

Close with assumptions to validate — every unknown from Step 1, stated plainly.

始终包含一个简短的退役后模块——归档、最终报告和经验复盘。复盘是团队最先省略但事后最后悔的环节；当有人记录下本次退役中的意外情况时，下一次产品退役会变得更容易。

最后列出需要验证的假设——即步骤1中所有未知的信息，清晰陈述。

Final Step: Offer what comes next

最终步骤：提供后续选项

"Where next?

Map the stakeholder conversations — who to talk to, in what order (Recommended)
Draft the customer announcement — see
```
eol-message
```
Build the internal enablement pack — support FAQ, sales talking points, objections
Convert this to a dated timeline — calendar dates against each phase

Reply with a number, a combination ('1 & 3'), or your own path."

“下一步可以选择：

梳理利益相关方沟通顺序——确定沟通对象和顺序（推荐）
起草客户通知——参考
```
eol-message
```
构建内部赋能包——支持FAQ、销售话术、异议处理方案
转换为带日期的时间表——为每个阶段添加日历日期

回复数字、组合选项（如'1 & 3'）或自定义需求。”

Examples

示例

```
examples/sample.md
```
— Fieldlight Classic Dispatch (SaaS, Level 2, five phases)
```
examples/sample-industrial.md
```
— NFA-200 controller line (industrial, Level 3, six phases with a deliberately undated EOL)

```
examples/sample.md
```
— Fieldlight Classic Dispatch（SaaS产品，Level 2，5个阶段）
```
examples/sample-industrial.md
```
— NFA-200控制器产品线（工业产品，Level 3，6个阶段，EOL日期暂未确定）

Common Pitfalls

常见陷阱

Pitfall 1: Ceremony Inflation

陷阱1：形式主义膨胀

Symptom: Every sunset gets the 15-area, six-phase playbook because it's "more thorough."

Consequence: Teams learn EOL process is theater, skip it entirely on the next one — and the next one is the one with the contracts.

Fix: Right-size deliberately. A Level 1 checklist that gets used beats a Level 3 that gets ignored.

症状： 所有产品退役都使用涵盖15个领域、6个阶段的执行手册，理由是“更全面”。

后果： 团队会认为EOL流程只是形式主义，下次遇到真正重要的退役时会完全跳过流程——而下次往往涉及合同问题。

解决方法： 谨慎匹配规模级别。被实际使用的Level 1检查清单，好过被忽略的Level 3检查清单。

Pitfall 2: Unowned Items

陷阱2：无人负责的条目

Symptom: "Ensure customer data is exported." Owner: blank, or "the team."

Consequence: Everyone assumes someone else has it. On shutdown day, nobody did.

Fix: Every item names a function. If you can't name one, that's the finding — escalate it rather than papering over it.

症状： “确保客户数据导出”，负责人为空或“团队”。

后果： 所有人都认为别人会处理这件事，结果在关停当天无人执行。

解决方法： 每个条目都指定职能角色。如果无法确定角色，这就是需要解决的问题——需升级处理，而非敷衍了事。

Pitfall 3: The Invented Date

陷阱3：随意设定日期

Symptom: An EOL date gets written down because the checklist template had a blank for it.

Consequence: You announce a date, discover the migration path doesn't exist, and move it. Customers who planned around the first date stop believing the second.

Fix:

Not scheduled

is a legitimate entry. Pair it with the precondition that would let you schedule it.

症状： 因为检查清单模板有空白，就随意填写EOL日期。

后果： 你发布了日期，却发现迁移路径不存在，不得不更改日期。根据第一个日期做规划的客户会不再相信第二个日期。

解决方法：

Not scheduled

是合理的填写内容。同时需注明能够确定日期的前置条件。

Pitfall 4: Phase Collapse

陷阱4：阶段合并

Symptom: Everything lands in one phase called "EOL."

Consequence: You stop sales, stop support, and shut down on the same day. Customers experience it as an outage with advance notice.

Fix: Separate the gates. Stopping sales is cheap and early; stopping service is expensive and last.

症状： 所有工作都归到一个名为“EOL”的阶段。

后果： 你在同一天停止销售、停止支持并关停服务，客户会将其视为有提前通知的停机事件。

解决方法： 拆分阶段节点。停止销售成本低且可提前进行；停止服务成本高且应最后执行。

Pitfall 5: Forgetting the Downstream Readers

陷阱5：忽略下游依赖系统

Symptom: The checklist covers the product and its customers, but not the four internal systems that quietly query its API.

Consequence: The product retires on schedule and three dashboards, a billing job, and a partner integration break the next morning.

Fix: The IT Systems and Data Management areas exist for this. At Level 1, still ask once: what reads from this?

症状： 检查清单覆盖了产品及其客户，但未涵盖悄悄调用其API的四个内部系统。

后果： 产品按时退役，但第二天有三个仪表盘、一个计费任务和一个合作伙伴集成出现故障。

解决方法： IT系统和数据管理领域就是为此设置的。即使是Level 1，也要问一次：哪些系统依赖该产品？

References

参考资料

Related Skills

External Frameworks

外部框架

Industry EOL lifecycle practice (GA/NSC/EOS/EOE/EOM/EOL/EOSRV)
RACI — for assigning the owner on each item

行业EOL生命周期实践（GA/NSC/EOS/EOE/EOM/EOL/EOSRV）
RACI — 用于为每个条目分配负责人

Provenance

来源

Adapted from

prompts/eol-checklist.md

in the

https://github.com/deanpeters/product-manager-prompts

repo.

改编自

https://github.com/deanpeters/product-manager-prompts

仓库中的

prompts/eol-checklist.md

。