/eol-stakeholder-sequence

name: eol-stakeholder-sequence
argument-hint: "[product being sunset, and who already knows]"
description: "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."
intent: >-
  Plan the order and content of stakeholder conversations for an EOL decision. Encodes the
  hard-won lesson that EOL engagement has a specific sequence — legal exposure first, financial
  impact second, then revenue-facing teams, then customer-facing teams — and that getting the order
  wrong means discovering landmines after the announcement instead of before.
type: component
theme: eol-transition
best_for:
  - "Sequencing EOL conversations so each one informs the next"
  - "Knowing what to ask for and what to commit to at every stop"
  - "Finding the objection that would have blown up six months after the announcement"
scenarios:
  - "We're retiring a product and I don't know who to talk to first or what to bring them"
  - "Last sunset blew up because Sales had promised things we didn't know about — sequence this one properly"
estimated_time: "20-35 min"

EOL Stakeholder Sequence

Purpose

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.

Input

**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?`

---

Key Concepts

The Sequencing Principle

**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.

Right-Size the Sequence

**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.

The Canonical Order

Filtered by level, but the relative order holds:

**Level 1+** 1. **Engineering** — what depends on this technically 2. **Support** — what changes for support operations 3. **Affected users or internal teams** — who feels it first

**Level 2+ (inserted ahead of the above)** 1. **Legal** — contractual and regulatory exposure 2. **Finance** — revenue impact and forecast changes 3. **Sales** — pipeline, bundles, and *promises made in the field that never found their way into a contract or a ticket* 4. **Marketing** — you do not want to discover they just bought a quarter's worth of demand gen for the thing you killed 5. **Customer Success** — they will bear the brunt of this; work with them, not around them 6. **Your most difficult customers** — they will find the three things you forgot that would have blown up six months later

**Level 3+**

• **Executive leadership** — strategic approval
• **Channel partners** — inventory, commitments, and their own customer relationships
• **Regulatory bodies** — filings and compliance
• **Key accounts** — individual transition conversations

Why Your Most Difficult Customers Belong in the Sequence

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 lat