lifecycle-play-advisor
Diagnose where a product sits in its lifecycle and which play fits — extend, replace, or retire. Use when a product is fading and you need the call, not just the worry.
git clone --depth 1 https://github.com/deanpeters/Product-Manager-Skills /tmp/lifecycle-play-advisor && cp -r /tmp/lifecycle-play-advisor/skills/lifecycle-play-advisor ~/.claude/skills/lifecycle-play-advisorSKILL.md
# Lifecycle Play Advisor ## Purpose Work out what to do with a product that has stopped growing. Three plays are available — **extend**, **replace**, **retire** — and this skill gets you to the right one through diagnosis rather than debate, then hands you to whichever skill executes it. Most teams argue the play before establishing the stage. The argument is unwinnable that way, because nobody has agreed on what's actually happening to the product. Four questions fixes that. This skill is deliberately willing to say **"nothing yet."** A mature product throwing off margin with manageable support cost doesn't need a play; it needs to be left alone and watched. ## Input **Works best with:** The product, and what makes you think something needs to change. **Also useful:** Revenue trend and over how long, support load, what customers say, whether an internal driver (cost, capacity, strategy) is really behind the question, and what investment appetite exists. 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 diagnosis runs on questions a PM can answer from what they already know — no report-pulling required. "I don't know" is a valid answer and becomes a labeled assumption in the recommendation. **Example invocations:** - `Our reporting module has been flat six quarters and people want to rebuild it. Extend, replace, or retire?` - `Leadership wants to kill our parts module. Walk me through whether that's right.` --- ## Key Concepts ### The Three Plays - **Extend** — add a variant or capability to the existing line. The product keeps running; you add alongside. Cheapest, lowest risk, most often skipped because it isn't exciting. - **Replace** — ship a successor and phase the old one out. **GTM and EOL run simultaneously**, for two products that compete with each other. The expensive play. - **Retire** — phase out with no successor of your own. Customers land elsewhere, possibly with a competitor. The goal becomes losing the product without losing the customer. And the fourth answer that isn't a play: **harvest** — stop investing, keep running, set a review date. ### Diagnosis Before Play The seven transition questions establish stage; the pressure source discriminates the plays. Run both before recommending anything, and show your work — a recommendation the user can audit is one they can defend to someone else. ### The Extension Bias **Default toward the cheapest play that addresses the actual pressure.** Extension is under-considered in almost every room, because replacement is more interesting to build and retirement is more decisive to announce. Test extension explicitly, and record why it failed when it does. ### Anti-Patterns (what this is NOT) - **Not a growth strategy tool.** Where the next tranche of growth comes from is a different question — see `ansoff-matrix` and `organic-growth-advisor`. - **Not a kill switch.** "Nothing yet" and "harvest" are real outcomes. - **Not the execution.** It routes to the skill that runs the chosen play. ### Facilitation Source of Truth Use [`workshop-facilitation`](../workshop-facilitation/SKILL.md) as the interaction protocol. Give the heads-up at the start — four questions, about fifteen minutes — and let the user dump context to skip ahead. --- ## Application This skill asks **up to 4 adaptive questions**, then recommends a play with its reasoning, its hazards, and a route out. --- ### Question 1 of 4 — What product, and what makes you think something's wrong? **Agent asks:** "Which product are we looking at, and what prompted the question? The prompt matters as much as the product — flat revenue, rising support costs, a competitor move, and an exec remark lead to very different diagnoses." **Listen for whether the trigger is internal or external.** An internal trigger — manufacturing wants the line, engineering wants to rewrite, finance wants the cost out — is legitimate, but it means the customer-facing case for change is weak and the transition has to be carried entirely by you. Name that early; it changes what the play costs. --- ### Question 2 of 4 — Where is it actually in the lifecycle? **Agent asks:** "Let's establish the stage. Seven quick reads — yes or no, gut answers are fine: 1. Is defending market share still profitable? 2. Are loyalty efforts no longer retaining users? 3. Are legacy support costs becoming unsustainable? 4. Should we be running migration campaigns instead of loyalty ones? 5. Are we losing money on certain distribution channels? 6. Are our value-add bundles losing effectiveness? 7. Is our data shifting from predictive to transitional?" **Score it:** | Yes count | Stage | Implication | |---|---|---| | 0-1 | Mature and healthy | No play needed. Invest or leave alone | | 2-3 | Mature and softening | Extension territory; watch quarterly | | 4-5 | Crossing into decline | Pick a play deliberately, now | | 6-7 | In decline | Replace or retire; extension likely just delays | **Say the count back and name the pattern**, not just the number. Yeses clustered on 5 and 6 (channel and price) point somewhere very different from yeses on 3 and 7 (support cost and data) — the first pattern is a distribution problem wearing a product costume. --- ### Question 3 of 4 — What's actually driving the pressure? **Agent asks:** "Three sources. Which is loudest? 1. **Demand-side** — customer needs shifted, segments moved, a competitor differentiated 2. **Supply/cost-side** — components, production cost, support load, or a strategy change 3. **Capability-side** — the technology is obsolete or the architecture has hit its limit Pick one as primary, even if two apply." **Why this discriminates:** | Pressure | Points toward | Because | |---|---|---| | Demand-side | **Extend** | The core
Run a structured discovery flow from problem framing through opportunity mapping and validation planning.
Guide PM to Director to VP/CPO transition planning with role-fit diagnostics and onboarding guidance.
Turn strategy and validated opportunities into a sequenced roadmap with clear tradeoffs.
Select what to work on next using the right prioritization method for your context.
Build product strategy from positioning through opportunity and roadmap decisions.
Create a decision-ready PRD by chaining problem framing, requirements definition, and story scaffolding.
Evaluate acquisition channels using unit economics, customer quality, and scalability. Use when deciding whether to scale, test, or kill a growth channel.
Assess whether your product work is AI-first or AI-shaped. Use when evaluating AI maturity and choosing the next team capability to build.