Jump to

Skill · Roadmap planning

Roadmap planning.

A roadmap without strategy is just a queue.

A method for turning a pile of ideas, requests, and ongoing work into a defensible plan for what to ship, when, and why. Themes tied to strategy, initiatives that ladder up to them, dependency-aware sequencing, capacity math that survives contact with reality, and the trade-off communication that lets the plan hold up under stakeholder pressure.

The output is a roadmap document plus the prioritization work that made it credible: a strategy summary, the plan itself, initiative briefs, a capacity model, and a 'Not now' list. A living document revisited monthly and replanned each quarter, not a contract.

Audience: product managers, engineering leads, and founders planning a quarter or a year; anyone who has to say no to a request with a reason that holds.

View the skill on GitHubBrowse the full catalog

The keystone distinction

A plan, not a backlog with months attached.

Roadmaps fail at five different layers, but the first failure is the one that decides the rest: planning without a strategy to plan against.

Failure mode

A list of features

Themes are missing, so the roadmap is a backlog with months attached. Without strategy to ladder up to, it stops being a plan and becomes a queue. The fix is to start over from strategy.

Failure mode

Date-driven

The planning question becomes 'what can we ship by end of Q2?' instead of 'what is the most important thing to do in Q2?' Dates are constraints, not goals; date-first planning optimizes for calendar fit, not impact.

The discipline

Strategy-anchored

Themes tied to strategy, initiatives that ladder up to them, sequencing built after prioritization, capacity math that leaves room for real work, and a 'Not now' list that makes the plan defensible.

Anchor the plan in strategy before anything else. Without a strategy underneath, the other four layers have nothing to optimize against.

The framework

Five layers, each a place roadmaps fail.

A roadmap is only as good as its weakest layer. Each one answers a different question.

  1. 01Themes (the why): top-level groupings tied to strategy. Outcome-shaped, limited to 3 to 5, defensible in one sentence, measurable.
  2. 02Initiatives (the what): multi-week efforts that ladder to a theme. Commit to outcomes and rough sizes, not dates.
  3. 03Sequencing (the when): order constrained by dependencies, capacity, calendar reality, and strategic windows. Built after prioritization, not before.
  4. 04Capacity reality (the how much): real utilization is 60 to 70% for engineers, 50 to 60% for designers, 40 to 50% for PMs. If the plan needs 100%, cut.
  5. 05Trade-off communication (the why not): the 'Not now' list, as important as the 'Doing' list, with a reason and a trigger for each cut item.

How the skill runs

Eight steps from strategy to a communicated plan.

The skill walks the work in order. Prioritization comes before sequencing; validation with the team comes before sharing with leadership.

  1. 01

    Anchor the strategy

    Write 3 to 5 themes before touching the backlog. If the strategy is missing or vague, stop and surface the gap; a roadmap against unclear strategy is worse than none.

  2. 02

    Catalog the backlog

    Every candidate gets a name, the theme it ladders to, a source, a rough size, an owner, and a status. Items with no theme are warning flags.

  3. 03

    Prioritize within each theme

    Rank initiatives with one framework used consistently: RICE, MoSCoW, Kano, cost of delay, or strategic alignment. Document the math.

  4. 04

    Build the dependency map

    For every 'Doing' initiative, list what must finish first: other initiatives, hiring, external delivery, research, infrastructure readiness.

  5. 05

    Lay out the sequence

    Place initiatives in time using the dependency map and capacity math. Month-by-month for a quarter, quarter-by-quarter beyond.

  6. 06

    Validate with the team

    Check size estimates, dependencies, capacity assumptions, and overcommitment. If the team says the plan is impossible, it is.

  7. 07

    Write the 'Not now' list

    Name what got cut to make room, the reason for each cut, and the trigger that would move it back to 'Doing' later.

  8. 08

    Communicate

    One roadmap, four views: detailed sequence for the team, themes and timing for partners, outcomes and trade-offs for leadership, themes-only for customers.

Reference files

The reference that goes alongside the SKILL.md.

  • references/prioritization-frameworks.md

    Detailed breakdown of RICE, MoSCoW, Kano, cost of delay, and strategic-alignment frameworks. When to use each, how to apply it, and the common mistakes, including using one framework for every initiative type.

Browse all reference files on GitHub

Bridges to other skills

Where roadmap planning hands off.

Roadmap planning sits above single-feature work and below strategy. These are the skills it points to when the work narrows.

  • Single-feature spec

    pm-spec-writing

    Translates a single roadmap initiative into a specific, actionable dev brief. Reach for it when an item moves from planned to ready-to-build and the team needs the implementation detail the roadmap deliberately leaves out.

  • Idea validation

    ux-research

    Validates whether an initiative is worth building before it consumes roadmap capacity. An unproven item belongs in research before it earns a slot in a quarter.

  • Single-initiative launch

    launch-runbook

    Handles the go-live for one scheduled initiative: pre-launch verification, DNS cutover, post-launch monitoring, and the rollback plan.

  • Looking back

    after-action-report

    After a quarter ships, it reviews what landed against what was promised. Those findings feed the next replanning cycle, closing the loop on a plan that was always meant to be revisited.

  • Goal setting

    okr-design

    Themes ladder up to top-level goals, so when the objectives themselves need work, this skill sets the stretch OKRs that produce real signal instead of sandbagged or fantasy targets.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.mdBrowse the full catalog

Frequently asked questions.

What does this skill produce?
A roadmap document plus the prioritization work that made it credible. The document includes a strategy summary, the visual plan (quarter-by-quarter or month-by-month, color-coded by theme), one brief per initiative (outcome, size, owner, dependencies, success metric), a capacity model with utilization math, the trade-offs and 'Not now' list, risks and assumptions, and an update cadence. It is a living document: revisit it monthly, replan it formally each quarter, and do not treat it as a contract.
What if the strategy is missing?
Stop. Producing a roadmap against an unclear strategy is worse than producing nothing. Write down 3 to 5 themes first, copying them from the team's OKRs or strategy doc if they exist, or drafting them and validating with the people who own strategy. Without a strategy underneath, a roadmap is just an ordered wishlist with months attached, not a plan. Surface the gap rather than papering over it with a feature list.
How much of the team's time should a roadmap assume?
Not 100%. Most roadmaps fail at the capacity layer because they assume every person spends all their time on roadmap work. Real utilization is lower: engineers 60 to 70%, designers 50 to 60%, PMs 40 to 50%. New hires run at 50% of full capacity in their first quarter, 75% in the second, 100% from the third on. Subtract on-call rotations, leave, and holidays before sizing. If the math says the plan needs 100% of the team, the plan is wrong; cut.
Which prioritization framework should I use?
Pick one and use it consistently. RICE suits feature-heavy roadmaps, MoSCoW suits fixed-deadline projects, Kano suits product-investment decisions, cost of delay suits cases where timing matters more than effort, and strategic alignment suits executive-facing roadmaps. The framework matters less than the consistency: apply it the same way for every initiative and document the math. Avoid using one framework for every level; RICE is great for features and weak for foundational platform or infrastructure work.
Why does every roadmap need a 'Not now' list?
Because it is what makes the plan defensible. For every item in 'Doing', name what got cut to make room, the reason it was cut, and the condition that would move it back: a metric, a date, or a finished prerequisite. Stakeholders pushing for a cut item then argue against the rejection criteria rather than the omission, which is a productive argument. It also stops cut requests from being rediscovered every two weeks: document the reason once, point to it forever.
How far out should the roadmap commit?
Specifics for near horizons, ranges or themes for far ones. Use month-by-month detail for one quarter and quarter-by-quarter beyond that; weekly is too granular and half-year buckets are too vague to commit to. Specific commitments six months out create promises the team cannot keep. Far horizons get themes and outcomes, not dated feature lists.