Purpose
Turn product goals, constraints, and team capacity into a structured roadmap — organized into strategic themes, broken into epics, and sequenced across time horizons with explicit rationale for why each item lands where it does. Solves the gap between a wish-list backlog and a defensible, capacity-realistic plan you can present to leadership and engineering.
When to Use
Invoke this skill when the user asks to:
- Build a quarterly or annual product roadmap
- Translate business or product goals into a prioritized set of initiatives
- Reorganize an existing roadmap around new OKRs, constraints, or leadership priorities
- Sequence epics and features against a fixed team capacity or deadline
- Create a themes-based roadmap to align stakeholders around outcomes rather than features
- Produce a roadmap deck-ready summary for a leadership or planning review
Inputs Required
Before starting, collect:
- Product goals / OKRs: The business or product outcomes this roadmap must drive (e.g., "increase activated users 30%", "launch payments in EU")
- Time horizon: Total planning window (e.g., next 2 quarters, H2, full year) and the phase granularity (quarterly, monthly, or Now/Next/Later)
- Team size and composition: Number of engineers, designers, and any specialist constraints (e.g., 6 engineers, 1 designer, 1 ML specialist)
- Known constraints: Hard deadlines, compliance requirements, platform dependencies, hiring gaps, or fixed commitments already made
- Current product state: What exists today, major known problems, and any tech-debt or reliability work that must be accounted for
- Priority signal: What matters most right now — growth, retention, revenue, reliability, or a specific strategic bet
- Non-goals (optional): Explicitly out of scope for this horizon
If team velocity is unknown, assume a standard sprint model (~2 epics in-flight per 4 engineers per quarter) and note the assumption. If phase granularity is unspecified, default to quarterly.
Instructions
Step 1: Derive Strategic Themes from Goals
Group the goals into 3–5 strategic themes. A theme is an outcome-oriented bucket, not a feature.
- Each theme maps to at least one stated goal/OKR — name the linkage explicitly
- Name themes by the outcome they produce ("Reduce onboarding friction"), not the mechanism ("Redesign signup")
- If a stated goal has no theme, either create one or flag it as deferred with a reason
- Reserve one theme (or a fixed capacity slice) for reliability/tech-debt if the current product state warrants it — sustained feature velocity requires it
Step 2: Break Each Theme into Epics
Under each theme, define 2–4 epics. For each epic capture:
- Epic name: Concrete deliverable ("Guided first-transaction flow")
- Outcome: The measurable change it targets, tied to the theme's goal
- Rough size: T-shirt sizing (S / M / L / XL) with S ≈ 1–2 sprints, M ≈ 1 quarter for a small pod, L ≈ most of a quarter, XL ≈ multi-quarter (should be split)
- Dependencies: What must land first (technical, legal/compliance, another team, or data availability)
- Confidence: High / Medium / Low — how well-understood the scope is
Split any XL epic into sequenced sub-epics before proceeding.
Step 3: Sequence Across the Time Horizon
Assign each epic to a phase using this priority logic in order:
- Hard constraints first: Compliance deadlines and fixed commitments anchor their phase — build around them
- Dependency order: An epic cannot precede its prerequisites; unblock foundational work early
- Value-to-effort: Within the remaining freedom, front-load high-value / lower-effort epics for early momentum and learning
- Risk sequencing: Place Low-confidence, high-impact bets early enough to fail cheaply and re-plan
For each epic placement, write one sentence of sequencing rationale explaining why it lands in that phase (constraint, dependency, value, or risk).
Step 4: Capacity Check Against Team Size
Validate that each phase is achievable, not aspirational:
- Estimate concurrent capacity: roughly 1 M-epic in-flight per 3–4 engineers per phase, adjusted for the actual team composition
- Flag any phase that is over-committed and name what gets cut or pushed
- Call out specialist bottlenecks (single designer, one ML engineer) that serialize otherwise-parallel work
- If a hard deadline exceeds capacity, state the trade-off explicitly — scope cut, hire needed, or deadline risk
Step 5: Identify Risks and Open Questions
List the top 3–5 risks to the plan: dependency risk, capacity risk, low-confidence scope, or external unknowns. For each, note a mitigation or the decision needed to resolve it.
Step 6: Produce the Stakeholder Summary
Write a 4–6 sentence executive summary: what the roadmap achieves against the goals, the through-line of the sequencing, the biggest trade-off made, and the top risk to watch.
Output Format
- Structure: Executive summary first, then a themes → epics breakdown, then a phased roadmap table, then capacity notes, risks, and open questions
- Length: 1,000–1,400 words
- Format: Prose summary + structured lists for themes/epics + a roadmap table (rows = epics, columns = phase, theme, size, dependencies, rationale)
- Sections: Executive Summary → Strategic Themes → Epics by Theme → Phased Roadmap Table → Capacity Check → Risks & Open Questions
- Tone: Product-manager-to-leadership — decisive, trade-off-aware, no hype; every placement is justified, not asserted
Quality Checklist
Before delivering output, verify:
- [ ] Every stated goal/OKR maps to at least one theme, or is explicitly listed as deferred with a reason
- [ ] There are 3–5 themes and each has 2–4 epics
- [ ] Every epic has a size, dependencies noted, and a one-sentence sequencing rationale
- [ ] No epic is sequenced before its listed dependency
- [ ] Each phase has an explicit capacity verdict (achievable / over-committed with a named cut)
- [ ] Any hard deadline that exceeds capacity states the specific trade-off
- [ ] The roadmap table is complete — no epic is missing a phase assignment
Notes
- Themes-based roadmaps age better than feature-list roadmaps because outcomes stay stable while features change — resist the urge to list dated features in Later phases
- The most common failure is a plausible-looking roadmap that ignores the single-designer or single-specialist bottleneck; the capacity check exists specifically to catch serialization
- Later-horizon phases (Later / Q3+) should stay intentionally coarse — commit to themes and directional epics, not to precise scope you can't yet estimate
- If goals conflict (growth vs. reliability with fixed capacity), surface the conflict rather than silently optimizing one — the trade-off is the PM's decision to make, and the roadmap should expose it
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