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.

[{"step":"Gather critical inputs","action":"Collect the product/service name, sunset date, key stakeholders (e.g., IT, Marketing, Finance), and dependencies (e.g., integrations, third-party vendors). Use a spreadsheet or project management tool like Jira/Asana to centralize this data.","tip":"Validate the sunset date with legal/compliance teams to ensure alignment with contracts or regulatory requirements."},{"step":"Customize the phase-gated structure","action":"Adjust the 4-phase template (Planning, Communication, Migration, Decommissioning) to match your organization’s EOL process. For example, add a 'Risk Assessment' phase if your industry requires it (e.g., healthcare).","tip":"Use the [DEPENDENCIES] field to flag tasks that could delay the entire project (e.g., budget approval, vendor contracts)."},{"step":"Assign owners and deadlines","action":"Populate the checklist with named owners for each task. Ensure owners have the authority and resources to complete their tasks. Use tools like RACI matrices or responsibility assignment charts to clarify roles.","tip":"For complex tasks (e.g., data migration), break them into subtasks (e.g., 'Validate data integrity' under 'Set up data migration environment')."},{"step":"Validate and iterate","action":"Review the checklist with cross-functional teams (e.g., IT, Legal, Customer Success) to identify gaps or conflicts. Update deadlines based on feedback and run a dry test of the plan if possible.","tip":"Use the example output as a template but replace fictional data (e.g., 'Acme CRM Suite') with your actual product/service details."},{"step":"Monitor progress","action":"Track completion of tasks in real-time using a dashboard (e.g., Power BI, Trello). Hold weekly standups to address blockers and reassign tasks if owners are unavailable.","tip":"Automate reminders for deadlines using tools like Slack or Microsoft Teams to keep the team on track."}]