eol-checklist

--- name: eol-checklist argument-hint: "[product being sunset, and any hard dates]" description: "Build a phase-gated EOL checklist sized to the sunset, with a named owner on every item. Use when the decision to retire is made and you need the operational plan." intent: >- Generate a phase-gated EOL checklist tailored to the complexity of the sunset. Covers up to 15 functional areas across the lifecycle gates, but right-sizes the output so a minor feature deprecation gets a short punch list while a flagship product retirement gets the full cross-functional playbook. Every item names a verb and an owner. type: component theme: eol-transition best_for: - "Turning a sunset decision into an operational plan with owners and dates" - "Making sure a retirement doesn't strand data, contracts, or inventory" - "Right-sizing process so a feature deprecation doesn't get a flagship playbook" scenarios: - "We've decided to retire the legacy module in December — what actually has to happen between now and then?" - "Hardware line with channel partners and service contracts; I need the full cross-functional checklist" estimated_time: "20-40 min" --- # EOL Checklist ## 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. ## 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.` --- ## 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. ### 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." ### The Fifteen Functional Areas 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 | ### 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. ### 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. ### 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 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? 1. **Light** — a feature, internal tool, or unversioned API. Few users, all reachable. 2. **Standard** — a commercial product with paying customers and contracts. 3. **Heavy** — revenue-critical, hardware in the field, channel partners, or regulated. Most sunsets are Standard. Which sounds like yours?" ### Step 2: Select phases in scope 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. ### Step 3: Build items per phase, per area 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: 1. **Data** — export format, availability window, deletion schedule 2. **Contracts** — renewal language, SLA terms, refunds or credits owed 3. **Access** — API keys, integrations, SSO, downstream systems that read from it 4. **Money** — forecast adjustment, revenue recognition, cost of the sunset itself ### Step 4: Write gate criteria (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. ### Step 5: Post-EOL actions and assumptions 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. ### Final Step: Offer what comes next "Where next? 1. **Map the stakeholder conversations** — who to talk to, in what order (Recommended) 2. **Draft the customer announcement** — see [`eol-message`](../eol-message/SKILL.md) 3. **Build the internal enablement pack** — support FAQ, sales talking points, objections 4. **Convert this to a dated timeline** — calendar dates against each phase Reply with a number, a combination ('1 & 3'), or your own path." --- ## 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) --- ## Common Pitfalls ### Pitfall 1: Ceremony Inflation **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. --- ### Pitfall 2: Unowned Items **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 **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. --- ### Pitfall 4: Phase Collapse **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. --- ### Pitfall 5: Forgetting the Downstream Readers **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? --- ## References ### Related Skills These stand on their own — none is a prerequisite for this skill, and this skill isn't a prerequisite for them. If you already picked a level elsewhere, just say "Level 2" and this skill will build to it; there's no handoff artifact to carry. - [`eol-readiness-advisor`](../eol-readiness-advisor/SKILL.md) — if the decision itself still needs a case, or you want the level recommended for you - [`eol-stakeholder-sequence`](../eol-stakeholder-sequence/SKILL.md) — who to talk to and when - [`eol-internal-enablement`](../eol-internal-enablement/SKILL.md) — readying customer-facing teams - [`eol-message`](../eol-message/SKILL.md) — the customer-facing announcement ### External Frameworks - Industry EOL lifecycle practice (GA/NSC/EOS/EOE/EOM/EOL/EOSRV) - RACI — for assigning the owner on each item ### Provenance - Adapted from `prompts/eol-checklist.md` in the `https://github.com/deanpeters/product-manager-prompts` repo.