Purpose
Turn a tangle of competing platform investments and customer commitments into an ordered, cycle-by-cycle sequence where every cycle delivers something a customer can feel — while still bending the roadmap toward the long-term vision. Solves the recurring PM trap of either shipping thin features forever or disappearing into a platform rebuild with nothing to show.
When to Use
Invoke this skill when the user asks to:
- Decide whether to go narrow (ship a slice) or broaden the scope of an initiative
- Sequence platform/foundational work against customer-facing feature delivery
- Restructure a roadmap so no cycle is pure infrastructure with no customer value
- Order a backlog of dependent work toward a long-term product vision
- Resolve tension between an eng team wanting to "do it right" and a customer needing it now
- Figure out what to ship this cycle vs. defer without stalling the bigger bet
Inputs Required
Before starting, collect:
- Long-term vision: The end-state the product is building toward (1–3 sentences)
- Initiatives on the table: The 3–8 chunks of work competing for the roadmap, platform and customer-facing mixed
- Customer commitments/pressure: Specific deals, deadlines, or accounts pushing for near-term delivery
- Cycle length and horizon: How long a cycle is (e.g., 2 weeks, 6 weeks, a quarter) and how many cycles you're planning across
- Team capacity: Rough size or throughput — one team, multiple teams, split platform/product
- Known dependencies: Anything where B genuinely can't ship before A
- Current pain: What's forcing the replan — a stalled rebuild, a slipping commitment, a scope fight
If cycle length or capacity is missing, assume one team on 2-week cycles across a 6-cycle horizon and state the assumption.
Instructions
Step 1: Establish the Vision Vector
Restate the long-term vision as a direction, then define what "on the path" means concretely. Name 2–4 capability milestones the product must reach to realize the vision (e.g., "multi-tenant data model," "self-serve onboarding," "usage-based billing"). Every initiative will later be scored on whether it moves the product along this vector or sideways.
Step 2: Classify Each Initiative
Tag each initiative on two axes:
- Value type: Customer-Visible (a user notices) / Platform-Enabling (unlocks future customer value) / Pure Debt (neither — only reduces risk or cost)
- Vision fit: On-Path (advances a milestone) / Adjacent (useful, off the main line) / Detour (customer-requested but pulls away from vision)
Flag any Platform-Enabling + On-Path initiative — these are the ones most at risk of becoming multi-cycle black holes and are the primary targets for slicing in Step 4.
Step 3: Map Hard Dependencies
Build a dependency chain distinguishing:
- Hard dependencies: B technically cannot ship before A
- Soft dependencies: B is easier or cleaner after A, but can ship independently (these are negotiable — most "we have to do the platform first" claims are soft)
- False dependencies: Assumed sequencing that doesn't actually hold under inspection
Explicitly challenge each soft dependency: what's the cost of doing B first with a temporary shim? This is where narrow-vs-broad gets decided.
Step 4: Apply the Narrow-vs-Broad Decision
For each large initiative, run the scope test and recommend narrow or broad:
Go narrow (ship a thin slice) when:
- A customer needs value before the full build lands
- The broad approach hides risky assumptions that a slice would validate cheaply
- The full scope spans more than 2 cycles with no customer-visible output in between
Go broad (invest in the fuller build) when:
- A thin slice would require rework that costs more than the deferral saves
- The platform capability is a hard dependency for 3+ downstream initiatives
- Slicing would ship something that damages trust (half-working core workflow)
For each initiative, name the recommendation, the slice boundary (what's in the first cut vs. deferred), and the temporary cost of going narrow (shim, manual step, limited scale).
Step 5: Sequence the Cycles
Order the work cycle by cycle under one governing rule: every cycle must ship at least one Customer-Visible outcome. For each cycle, specify:
- The customer-visible outcome shipping this cycle
- The platform-enabling work riding underneath it
- Which vision milestone this cycle advances
- What's explicitly deferred and why
Interleave platform work so it's funded by the customer value shipping alongside it — never schedule a "platform-only" cycle. If a hard dependency forces foundational work first, pair it with the smallest customer-visible win that the new foundation makes possible.
Step 6: Produce the Value-on-the-Path Scorecard
Summarize the sequence in a table: Cycle | Customer Value Shipped | Platform Progress | Vision Milestone Advanced | Deferred. Confirm no cycle has an empty "Customer Value Shipped" column, and confirm the vision milestones are reached by the end of the horizon.
Step 7: Name the Sequencing Risks
Call out the 2–3 biggest risks in the recommended sequence — a soft dependency that could turn hard, a slice that might expose an assumption late, a deferred item that a customer could escalate — and the early signal that would trigger a resequence.
Output Format
- Structure: Seven sections following the steps; the cycle sequence and scorecard rendered as tables
- Length: 900–1,300 words
- Format: Structured document with a dependency map (bulleted or simple chain), narrow-vs-broad recommendations per initiative, and two tables (cycle sequence + scorecard)
- Sections: Vision Vector → Initiative Classification → Dependency Map → Narrow-vs-Broad Decisions → Cycle Sequence → Value-on-the-Path Scorecard → Sequencing Risks
- Tone: Senior product leader — decisive, tradeoff-literate, willing to make the call rather than list options
Quality Checklist
Before delivering output, verify:
- [ ] Every cycle in the sequence has a non-empty Customer-Visible outcome — no platform-only cycles
- [ ] Each initiative is classified on both axes (value type and vision fit)
- [ ] Every large initiative gets an explicit narrow-or-broad recommendation with a named slice boundary
- [ ] Soft dependencies are distinguished from hard ones and at least one is challenged
- [ ] All vision milestones from Step 1 are reached by the end of the horizon (traceable in the scorecard)
- [ ] 2–3 sequencing risks are named with the early signal that would trigger a resequence
Notes
- Most "we have to build the platform first" arguments collapse into soft dependencies once the shim cost is quantified — pressure-test them hard
- The narrow slice that validates a risky assumption is almost always worth more than the broad build that assumes it away
- A roadmap where the customer feels nothing for three cycles is a stakeholder-trust liability regardless of how sound the platform work is — treat visible value as a scheduling constraint, not a nice-to-have
- If two initiatives both claim the same cycle's customer-visible slot, sequence by which one de-risks the most downstream work, not by which stakeholder is loudest
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills