OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add deanpeters/product-manager-skills --skill eol-stakeholder-sequence
Plan who to talk to about a sunset, in what order, and what each conversation must cover. Use when an EOL decision is made and you want the landmines found before the announcement.
npx skills add deanpeters/product-manager-skills --skill eol-stakeholder-sequence
Plan the order of EOL conversations, and what each one must cover. The output is a sequenced list of stops — each with what you need from them, what you owe to them, the red flags to listen for, and what the conversation must produce.
EOL is not a broadcast. It is a series of conversations where each one informs the next, and each one surfaces something the last one missed. Sequenced well, the awkward discoveries happen in a conference room. Sequenced badly, they happen in public, after the announcement, in front of customers.
Works best with: The product being sunset and who already knows about it.
Also useful: Scale (customers, revenue, contracts), whether channel partners or regulators are involved, and any political sensitivities, strained relationships, or past surprises worth planning around.
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 who knows, how big the blast radius is, and whether there's history to plan around — then builds the sequence. Political sensitivities are optional; the sequence works without them and sharpens with them.
Example invocations:
Sequence the stakeholder conversations for retiring our legacy reporting module.Who do I talk to, in what order, about sunsetting a hardware line with 8 resellers?Talk to the people who can kill the plan before you talk to the people who have to execute it.
Each conversation should inform the next. Legal exposure first, because a contract term can end the discussion. Financial impact second, because it sizes everything downstream. Then revenue-facing teams, then customer-facing teams, then the technical teams who will carry it out.
Get this backwards — brief Support first, Legal last — and you will have told forty people about a plan that a single contract clause invalidates.
Not all EOLs play out the same. Most land in the middle:
| Level 1 — Light | Level 2 — Standard | Level 3 — Heavy | |
|---|---|---|---|
| Typical scope | Feature, internal tool, API | Commercial product, active customers | Revenue-critical, hardware, regulated |
| Stops | 3-4 | 7-8 | 10+ |
| Includes | Engineering, Support, affected users | + Legal, Finance, Sales, Marketing, CS, difficult customers | + Executives, Channel, Regulatory, key accounts |
| Skip unless there's a reason | Legal, Finance, Sales, Channel | Channel, Regulatory | — |
Level 2 is the default. Recommend a level, say why, then let the user move it. Never default to the heaviest sequence — a ten-stop tour for a feature deprecation burns credibility you'll want for the sunset that actually needs it.
If someone dials down, name the stop they're dropping and what it typically catches. Dropping Legal on a product with contracts is the one worth pushing back on once — then honoring their call.
Filtered by level, but the relative order holds:
Level 1+
Level 2+ (inserted ahead of the above)
Level 3+
Counterintuitive, and the stop teams skip most often. The customer who files the most tickets and pushes hardest in QBRs has, by construction, the deepest and weirdest usage of your product. They will find the integration you forgot, the contract term nobody read, and the workflow that has no equivalent in the replacement.
You can learn that from them in a scheduled call now, or from them on a public forum later.
Every stop has two directions. Skipping the second turns stakeholders into an audience:
A conversation that is all extraction gets you compliance. A conversation that runs both ways gets you the thing they weren't asked about.
Every bullet is 4 to 8 words. Sequences get read in hallways, before meetings, on phones.
Recommend from blast radius, present all three, let the user choose. If unclear, ask:
"How complex is this sunset?
Most are Standard. Which sounds like yours?"
Apply the canonical order, filtered by level. Two adjustments worth making:
For every stop, fill five fields:
Then state the output: the decision, approval, or artifact the conversation must produce. A stop with no output is a status update, not a stop.
Say which stops must be strictly sequential and why, and which can safely run in parallel. Being explicit here is what lets a team compress a ten-stop sequence into three weeks without breaking the dependency that mattered.
Close with what you assumed — who you think knows, what you think the contracts say, which relationships you think are intact.
"Where next?
eol-messageReply with a number, a combination ('1 & 3'), or your own path."
examples/sample.md — Fieldlight Classic Dispatch (SaaS, Level 2, eight stops)examples/sample-industrial.md — NFA-200 controller line (industrial, Level 3, eleven stops)Symptom: The sequence starts with a company-wide email.
Consequence: Every subsequent conversation is a negotiation with someone who found out the wrong way and is now defending their turf instead of helping you.
Fix: The announcement is the end of the internal sequence, not the beginning.
Symptom: Legal gets looped in once the plan is built, "to review."
Consequence: A contract term or regulatory obligation invalidates a plan forty people have already committed to. Now you're relitigating instead of executing.
Fix: Legal is the first Level 2+ stop. A five-minute "are there commitments here?" beats a five-week replan.
Symptom: Sales is informed of the EOL date rather than asked what they've promised.
Consequence: Field commitments that never made it into a contract surface after the announcement, from the customer's side, as accusations of bad faith.
Fix: Ask Sales explicitly: what has anyone promised about this product's future? Ask before you tell.
Symptom: The sequence covers internal functions and stops.
Consequence: Your edge cases are discovered by the people least inclined to be quiet about them.
Fix: Two or three of your hardest customers, under NDA if needed, before the public announcement. Budget for what they'll find.
Symptom: Every stop is a list of things you need. Nothing is offered.
Consequence: Stakeholders answer the questions asked and volunteer nothing. The thing that sinks you was the thing nobody thought to ask about.
Fix: Fill "what you owe them" for every stop before you hold it.
These stand on their own — none is a prerequisite for this skill, and this skill isn't a prerequisite for them. If you already chose a level elsewhere, say "Level 2" and this skill builds to it.
eol-checklist — the phase-gated operational planeol-internal-enablement — what customer-facing teams get
after these conversationseol-readiness-advisor — if the decision still needs a caseeol-message — the customer-facing announcementstakeholder-map — general power/interest mapping for non-EOL workprompts/eol-stakeholder-sequence.md in the
https://github.com/deanpeters/product-manager-prompts repo.