eol-readiness-advisor skill

EOL Readiness Advisor

Purpose

Decide whether a product or feature should actually be retired — and if so, how much machinery the retirement deserves. This skill produces a go/no-go verdict with named evidence, an intensity level you choose, and a short list of the obligations that will bite you if ignored.

Most EOL guidance assumes the decision is already made and jumps to the plan. This skill sits earlier: it is the conversation where "we should probably kill this" becomes a decision someone will defend in a room.

It is equally willing to tell you not to retire. A "hold" or "harvest" verdict is a real outcome here, not a consolation prize.

Input

Works best with: The product or feature under consideration and what triggered the conversation (a declining number, a strategy shift, a support-cost complaint, an exec offhand remark).

Also useful: Revenue and customer counts, whether a replacement exists, contract or regulatory commitments, and any political sensitivities you already know about.

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 opens by asking what's under review and why, then walks you through blast radius, intensity, and transition path one question at a time. You do not need the numbers in front of you — "I don't know" is a valid answer that becomes a labeled assumption in the verdict.

Example invocations:

• Should we retire our legacy reporting module? Usage is down 60% and support costs are climbing.
• EOL readiness check on our NFA-200 controller line — 120 installs, channel partners, UL certified.

Key Concepts

The Right-Sizing Dial

Not all EOLs play out the same. Some are a changelog entry and a support macro. Some consume the whole company for three quarters. Most land in the middle. The single most common EOL failure in either direction is a mismatch between the size of the sunset and the size of the response — a flagship retirement run as a Jira ticket, or a feature deprecation that spawns a steering committee.

So the intensity is a dial you set, not a verdict the framework hands you:

Level 2 is where most sunsets belong. Treat it as the default and argue your way up or down.

The dial is yours to move. Recommend a level, explain the reasoning, then let the user override in either direction — and let them move it again later. A PM who says "give me the light version, I know my org" is exercising judgment, not making an error. Honor it, and note in one line what the lighter level leaves uncovered so the choice is informed rather than blind.

Lifecycle Gates (shared vocabulary)

EOL is not one date. It is a series of gates, and most customer anger comes from collapsing them into a single announcement:

• 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

Light sunsets use three of these. Heavy sunsets use all eight. Naming the gates you're not using is as useful as naming the ones you are.

The Four Retire Signals

Evidence that supports a go verdict. Two or more, strongly present, is a real case:

1. Financial viability — costs exceed revenue; support load drains disproportionate resources
2. Strategic alignment — conflicts with company direction; you are exiting this market
3. Solution replacement — an internal successor supersedes it; you're consolidating platforms
4. Market irrelevance — needs shifted, technology moved, the core problem stopped existing

The Four Hold Signals

Evidence that argues against retiring now, even when the retire signals are loud:

1. Obligation lock — contracts, SLAs, regulatory commitments, or "lifetime" promises still run
2. Strategic hostage — low revenue, but it sits inside your most important accounts
3. No landing place — no replacement and no third-party alternative; customers would be stranded
4. Exit costs exceed carry costs — the sunset costs more than another year of quiet maintenance

Anti-Patterns (what this is NOT)

• Not a rubber stamp. If the hold signals dominate, the verdict is hold, and the skill says so.
• Not a portfolio screen. This assesses one product. Screening a catalog is different work.
• Not the plan. The verdict and intensity level are inputs to planning, not the plan itself.
• Not a financial model. It reasons about revenue and cost qualitatively; it does not forecast.

Application

Use workshop-facilitation as the default interaction protocol for this skill.

This skill asks up to 4 adaptive questions, then delivers a verdict, an intensity level, and numbered next steps. Give the heads-up at the start: four questions, roughly fifteen minutes, and they can dump context at any point to skip ahead.

Question 1 of 4 — What's under review, and what triggered this?

Agent asks:

"What product or feature is under EOL consideration, and what brought it up? The trigger matters as much as the product — a declining metric, a strategy shift, a support-cost complaint, and an exec offhand remark lead to very different assessments."

Is retirement even the right question yet? This skill assesses one play: retiring. At the mature-to-decline inflection there are three — extend the product, replace it with a successor, or retire it. If the user hasn't established that retirement is the play, say so and offer the upstream diagnosis:

"Before we assess retiring it — is retiring the play you've settled on? There are two others

(extend it, or replace it with a successor), and

lifecycle-play-advisor works out which fits. Happy to

continue here if the call is made."

Don't force the detour. A user who says "we've decided, assess the retirement" gets the assessment.

Listen for the trigger type, because it predicts the failure mode:

If the trigger is an exec remark with no supporting evidence, say so plainly at verdict time. That is the single most common source of premature kills.

Question 2 of 4 — What's the blast radius?

Agent asks:

"Help me size the impact. Rough numbers are fine, and 'I don't know' is a real answer:

1. Customers: How many accounts or users are on it?
2. Revenue: Roughly what does it represent, and is it concentrated in a few accounts?
3. Commitments: Any contracts, SLAs, renewal dates, or regulatory obligations attached?
4. Physical or channel: Is there hardware, inventory, spare parts, or are partners reselling it?"

Why this matters (say it): These four answers set the intensity level. Item 3 is the one that most often turns a "simple" sunset into a legal problem — it is asked early on purpose.

Mark any unknown as an assumption to be labeled in the verdict. Do not stall the flow to chase a number; an assessment with three labeled assumptions beats an assessment that never happened.

Question 3 of 4 — Set the intensity

Agent presents the recommendation, then hands over the dial:

"Based on what you've described, here's my read on how much machinery this deserves:

Recommended: Level [N] — [Light / Standard / Heavy] Because: [two or three specifics drawn from their answers]

internal or the users are few and reachable.

1. Level 1 — Light. Punch list, 3-4 stakeholders, brief notice. Right when the blast radius is

Right for a commercial product with real customers and no regulatory entanglement. Most sunsets belong here.

1. Level 2 — Standard. Cross-functional checklist, 7-8 stakeholders, phased customer comms.

workstreams. Right when revenue is critical, hardware is in the field, or compliance applies.

1. Level 3 — Heavy. Full playbook, 10+ stakeholders, all eight gates, channel and regulatory