Roadmap Planning skill for Claude Code
Now, Next, Later roadmaps built on outcomes. Claude rewrites a feature list into outcomes with target metrics, groups them under three to five strategy themes with a capacity split, and places them in Now, Next and Later with evidence labels. Now is checked against real capacity with a reserve for surprises, dates appear only on committed work, and leadership, sales and engineering get filtered views of one source plan.
- name
roadmap-planning - size157 lines · ≈1,850 tokens
- files1
- licenseMIT
- updated
What Claude sees before loading it
This description is the only part of the skill that sits in context all the time. Claude reads it to decide when to load the full playbook below.
description: Builds outcome-based product roadmaps — strategy-linked themes, Now/Next/Later horizons with confidence that drops as the horizon lengthens, problems and target metrics instead of feature lists, capacity checks, dependencies, and audience-specific versions for executives, sales, and engineering. Use when creating or revising a product roadmap, converting a feature-list or Gantt roadmap into outcomes, presenting a roadmap to leadership or customers, handling date requests from sales, or rebalancing a roadmap after priorities change.Try asking
- Turn this Gantt-style feature list into an outcome-based Now/Next/Later roadmap
- Sales keeps asking for dates on Later items; draft how we communicate the roadmap to them
- Rebalance our roadmap now that enterprise security deals are the top priority
Use it when
- Creating or revising a product roadmap
- A roadmap is a dated feature list that keeps slipping
- Presenting the plan to executives, sales or customers
- Priorities shifted and the plan needs rebalancing
Skip it when
- You need to rank a list of features against each other, use feature-prioritization instead
- You need a single delivery date for one project, use work-estimation instead
How to check the result
Every Now and Next item has an outcome metric and evidence label, Now fits capacity minus a reserve, and no Next or Later item carries a date in any view.
The common mistake it prevents
Putting months on Later items, which turns directional ideas into promises that sales repeats to customers.
A roadmap is done well when it explains what the team will change for customers and the business, in what order, and why that order, while being honest that later items are less certain. It is a communication of strategy and sequencing, not a release schedule. If a roadmap cannot survive one item slipping, it was a Gantt chart.
Ground rules
- Every roadmap item is a problem or outcome with a target metric, and features appear as current best bets under it.
- Horizons, not dates, beyond the current quarter. Use Now (this quarter, committed), Next (next 1–2 quarters, planned), Later (directional).
- Confidence decreases with distance and the roadmap says so: Now items have scope and owners; Later items have only a problem and a rationale.
- 3–5 themes, tied to the strategy or company OKRs. An item that fits no theme needs an explicit reason or comes off.
- Capacity is real: Now fills at most ~70–80% of team capacity; the rest absorbs bugs, support, tech debt, and surprises.
- One source roadmap, several views. Executive, sales, and engineering versions are filters of the same data, never separate plans.
Workflow
- [ ] 1. Gather inputs: strategy/OKRs, metrics, discovery findings, customer and sales asks, tech debt, commitments
- [ ] 2. Define 3–5 themes from strategy
- [ ] 3. Rewrite candidate items as problems/outcomes with a metric
- [ ] 4. Prioritize within themes (see feature-prioritization); place into Now/Next/Later
- [ ] 5. Check Now against capacity and dependencies
- [ ] 6. Assign confidence and evidence to each item
- [ ] 7. Produce audience views; review with eng, design, sales, leadership
- [ ] 8. Set the update cadence and change logThemes
A theme is a strategic bet in plain words with a metric. Bad: “Platform”, “UX improvements”. Good:
| Theme | Strategy link | Metric |
|---|---|---|
| Win mid-market teams | Company OKR: grow 50–500 seat ARR | Mid-market win rate, seat expansion |
| First week to value | Company OKR: retention | Week-1 activation, day-30 retention |
| Trust and compliance | Enterprise deals blocked on security | Security-review pass rate, deals unblocked |
| Run faster, break less | Eng health | Deploy frequency, incident count |
Reserve capacity per theme as a percentage (e.g. 40 / 30 / 15 / 15) so the mix matches the strategy, then fill each slice by priority.
Feature list to outcome roadmap
| Feature-list item | Outcome item | Metric | Current bets |
|---|---|---|---|
| “Dashboard v2” | Team leads see at-risk projects without a status meeting | % of leads viewing weekly; status-meeting time (survey) | Risk flags, weekly digest |
| “SSO + SCIM” | Enterprise security reviews no longer block deals | Deals blocked on security: 7 → 1 per quarter | SAML SSO, SCIM provisioning, audit log |
| “New onboarding” | New teams reach value in their first week | Week-1 activation 22% → 35% | Checklist, templates, lifecycle email |
| “Refactor billing” | Pricing changes ship in days, not months | Lead time for pricing change: 8 weeks → 1 week | Billing service extraction |
The outcome phrasing lets the team swap bets when discovery says the first idea will not work, without “changing the roadmap”.
Horizons and confidence
| Horizon | Window | What it contains | Confidence | Changes allowed |
|---|---|---|---|---|
| Now | Current quarter / next 6–12 weeks | Scoped outcomes, owners, bets in progress | High (~80%+) | Only with a stated trade-off |
| Next | 1–2 quarters out | Problems validated by discovery, rough size (S/M/L) | Medium (~50%) | Expected at quarterly planning |
| Later | 2+ quarters | Problems worth solving, no solution committed | Low | Freely, with a note |
Label each item with evidence: validated (data or tests), signals (interviews,
tickets), hunch. Hunch items stay in Later until discovery upgrades them.
Capacity and dependencies
- Compute Now capacity: engineers x weeks x focus factor (0.6–0.7). Subtract commitments and a 20–30% reserve for unplanned work.
- Size Now items as ranges (see work-estimation); if the P80 sum exceeds capacity, move items to Next instead of squeezing.
- Mark cross-team dependencies with the owning team and a confirmed date. Unconfirmed dependencies keep the item in Next.
- Sequence for learning: put the riskiest assumption early so Later items can be revised with real information.
Handling date requests
| Request | Response |
|---|---|
| “When will X ship?” for a Now item | Give a range at P80 with the main risk |
| Same, for Next or Later | “It’s in Next; we’ll have a date when it enters Now at the <month> planning. Here’s what would move it up.” |
| A deal depends on it | Evaluate as cost of delay with the deal value; if it wins, it displaces a named Now item, and that trade-off is stated |
| Customer-facing roadmap | Themes and problems only, no dates beyond Now, with a “subject to change” line |
Never put a Later item on a slide with a month next to it. That month becomes a promise.
Audience views
| Audience | Show | Hide |
|---|---|---|
| Leadership | Themes, capacity split, outcome metrics, top risks, what was cut | Story-level detail |
| Sales / CS | Problems being solved per segment, Now with ranges, how to talk about Next | Internal confidence debates, tech debt |
| Engineering / design | Bets, dependencies, sizing, discovery status, tech debt items | Deal names unless relevant |
| Customers | Themes and problems, Now items in plain language | Dates beyond Now, internal metrics |
Updating the roadmap
- Review monthly; re-plan quarterly. Move items between horizons with a one-line reason in a change log.
- When something new enters Now, something named leaves. Write both in the change log.
- Report outcome progress next to items (metric now vs. target), not percent complete.
Gotchas
- Dates on everything. Teams then defend dates instead of outcomes. Dates belong only to committed Now items with known scope.
- 100% capacity planned. The first incident or enterprise escalation breaks the plan.
- Roadmap as wishlist. If Later holds 40 items, it is a backlog. Keep Later to the ~5–10 problems worth explaining.
- Separate roadmaps per audience drift within a month. Filter one source.
- No tech debt or platform work visible. It happens anyway and makes the roadmap look late. Give it a theme and a capacity slice.
- Outcome items without metrics (“Better reporting”) are features with nicer names.
Verification
- Every Now and Next item has an outcome, a metric, and an evidence label.
- Now P80 effort fits within capacity minus reserve; dependencies are confirmed.
- Theme capacity split matches the stated strategy within ~10 points.
- No month or date appears on Next or Later items in any view.
- Change log records what moved, what replaced it, and why.
Output contract
# Roadmap: <product/team> — updated <YYYY-MM-DD>
Strategy link: <company OKRs/strategy> Capacity split: <theme %s>
## Now (committed, <quarter>)
| Outcome | Theme | Metric (now → target) | Bets | Owner | Size (P80) | Evidence |
## Next (planned, 1–2 quarters)
| Problem | Theme | Why next | Rough size | Evidence | Open questions |
## Later (directional)
| Problem | Theme | Why it matters |
## Not on the roadmap (and why)
## Dependencies and risks
## Change log
- <date>: <moved X to Next because Y; Z entered Now>About this skill
Written and maintained by the Claude Skills editors to the same editorial standard as every skill in the directory: a selective trigger, a real workflow, known pitfalls and a verification step. First published , last updated . MIT licensed.