eol-process — End-of-Life (EOL) Product Retirement Process Orchestration Skill

Skill Overview

eol-process is a product retirement (EOL) process orchestration skill that organizes the entire journey—from the retirement decision through closure and retrospective—into six stages, helping product managers smoothly sunset a product or feature without losing customers.

Applicable Scenarios

1. Launching a complete product retirement from scratch: You have already decided to retire a product or product line and are responsible for driving the effort end to end. You need guidance through all stages—decision-making, alignment, planning, enablement, announcement, and closure—with clarity on what to do first at each stage and where the potential blockers are.
2. A problem occurs midway through the retirement: For example, support tickets surge after the announcement, customers report that they never received the notification, or Sales claims that customers were previously promised long-term support. Use the built-in “symptom → skipped stage” diagnostic table to locate the gap and identify immediate remediation actions.
3. Small-scale feature deprecation or internal tool shutdown: When the impact is limited and a full process is unnecessary, you only need a short stakeholder list, an execution checklist, and a customer support FAQ. The alignment-through-enablement steps can be completed in a single afternoon.

Core Features

1. Six-stage process orchestration and decision gates: Proceed in the order of “decision → alignment → planning → enablement → announcement → closure.” Each stage has defined deliverables and decision points. Key gates actively block the process when necessary—for example, if contract barriers or customer commitments are discovered during alignment, the decision is sent back for reassessment, preventing a flawed plan from progressing to a public announcement. The skill orchestrates the sequence of decisions and deliverables; it does not replace the project plan itself.
2. Three intensity levels based on impact scope (Level 1/2/3): The lightweight tier (features and internal tools, ranging from several days to several weeks), standard tier (commercial products, 6–12 months), and intensive tier (revenue-critical, hardware, or regulated products, 12–24 months) each have corresponding stakeholder requirements, stage gates, and enablement deliverables. This avoids imposing bureaucratic processes on small retirements while preventing critical gaps in major ones.
3. Midstream entry and failure diagnosis: You do not have to start from Stage 1. Use the “symptom comparison table” to jump directly to the problematic area—for example, high support pressure indicates missing internal enablement, customers not hearing about the change indicates an announcement failure, and Legal discovering contract issues means returning to the decision stage for reassessment.

Frequently Asked Questions

What stages does eol-process include? Must they all be completed?

It includes six stages: retirement decision, stakeholder alignment, execution planning, internal enablement, customer announcement, and closure and retrospective. Not all stages are mandatory: the stages are independent and can be combined according to the intensity level. For lightweight retirements, the alignment, planning, and enablement steps can usually be condensed into a single meeting. However, two steps should never be skipped: internal enablement before the announcement (otherwise Support will have to improvise on the spot), and the final closure and retrospective (skipping it means repeating the same mistakes in the next retirement).

When can we publicly announce that the product will be discontinued?

Three conditions must be met simultaneously: the alignment stage is complete, with no new discovery that overturns the decision (such as contract, regulatory, or customer-commitment issues); every item in the execution plan has a clear owner and a defensible date—when a date is uncertain, mark it as “TBD” rather than making an external commitment; and internal enablement for Support and Sales is complete. Spot-check whether one support representative can answer the most difficult question and whether one salesperson can handle the strongest objection. If either person cannot, it is not yet time to announce. Another mandatory pre-announcement check: Legal has reviewed the draft, the content does not conflict with past commitments made by Sales, and Support receives the announcement before customers do.

The product has already been announced as EOL, but things are out of control. Can this skill still help?

Yes. It specifically supports midstream entry. Identify the skipped stage based on the symptoms and take corrective action: a sharp increase in support pressure indicates missing internal enablement—immediately provide the Support FAQ and the four-level escalation path; customers saying they never received notice indicates an announcement reach failure—issue a new announcement with clear dates; if Sales reports that customers are presenting “permanently available” commitments, first inventory the historical commitments made by frontline teams before continuing any communication; if Legal discovers contract barriers, return to the decision stage and reassess the timeline and potentially the decision itself. If the retirement is already complete but no retrospective was conducted, it is still advisable to hold one as soon as possible—while the details are fresh.

---

Skill note: eol-process orchestrates the decision sequence and key deliverables in the retirement process. The specific project plan, task schedule, and detailed documentation for each stage are produced separately by the companion skills.