TL;DR
A roadmap that survives week 2 is planned to 70-80% of capacity, not 100% — every credible capacity-planning source converges on that ceiling because software work always hides debugging, coordination, and rework. Use AI for the structure (monthly columns, dependency mapping, capacity arithmetic, RICE math) and let your engineers anchor the effort estimates. Feed the model 10-15 ideas, your real capacity in person-weeks, the quarter’s strategic goal, and what you will not do; ask back for a 3-column plan, a RICE table, a dependency map, a NOT-doing list, and a cut order. Then sanity-check that the committed person-weeks land near 80%, not 100%.
The task
A new quarter starts. You have 10-15 feature ideas, a team with finite capacity, and one strategic goal. You want a roadmap ambitious enough to motivate but realistic enough to actually ship, with a visible “NOT on this roadmap” section so stakeholders cannot smuggle scope in mid-quarter.
The single most expensive mistake is planning to 100% capacity. Capacity-planning practice has settled on a ceiling: most teams perform best at roughly 70-80% utilization, because above ~80% the queue tips and a single surprise blows up the whole quarter. The slack is not waste — it is the cushion that lets you actually deliver what you promised when reality intrudes.
Where AI helps — and where it does not
AI is strong at the mechanical layer of a roadmap and weak at the judgment layer.
| AI is good at | AI is bad at |
|---|---|
| Laying out monthly columns and dependency maps | Estimating engineering effort on your codebase |
| Computing RICE scores and capacity arithmetic | Knowing which “small” feature hides a migration |
| Drafting the NOT-doing list and cut order | Weighing strategic must-ships against the score |
| Spotting features that block other features | Reading the room on what stakeholders will accept |
Treat AI’s effort numbers as placeholders until an engineer who has touched the code anchors them. Never commit a ship date on AI sizing alone.
What to feed the AI
- 10-15 feature ideas, each with a one-line description
- Team capacity in person-weeks, engineers and designers counted separately
- The quarter’s strategic goal (one line)
- Strategic must-ships (regardless of score) and the reason each is non-negotiable
- Past similar quarters: what shipped, what slipped, by how much
- Off-limits: frozen tech-debt areas, regulatory work, team holidays
The richer the past-quarter data, the better the model calibrates. If your last quarter slipped 30%, say so — it should make the model more conservative, not less.
RICE: the math AI should show its work on
Most prioritization here runs on RICE: (Reach × Impact × Confidence) ÷ Effort. Reach is how many users an item touches in a fixed window, Impact is a multiplier (a common scale is 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal), Confidence is a percentage (100% / 80% / 50%), and Effort is person-months or person-weeks. The score is total impact per unit of work — higher is better.
Ask the AI to output the RICE table with each input visible, not just a ranked list. A buried 50% confidence on a “high-value” item is exactly the thing you want to see before you commit to it.
Copy-ready prompt
Plan a 3-month roadmap.
Strategic goal: [line]
Strategic must-ships (with reason): [list]
Capacity: [eng person-weeks / design person-weeks]
Past similar quarter — shipped vs slipped: [notes]
Off-limits / frozen: [list]
Features under consideration:
1. [feature] — [description] — eng estimate (if available): [S/M/L]
2. ...
Return:
1. A RICE table: Reach, Impact, Confidence (%), Effort (person-weeks), score — with every input visible
2. A 3-column monthly roadmap with features assigned by month
3. A dependency map — what blocks what, sequenced so blockers go first
4. Slack capacity (~20%) reserved for reactive work, with a rule for spending it
5. A "NOT on this roadmap" section — 3 things explicitly deferred, with the reason
6. The "if the quarter goes sideways" cut order — first, second, third to drop
7. A confidence rating per feature (1-5) based on sizing certainty
Plan to 80% of capacity. Reserve 20% for surprises. Do not place a low-confidence
feature in month 3.For platform- or infra-heavy quarters, add: Add a separate "maintenance & infra" track at a fixed 20-30% of capacity.
Which model for the planning pass (as of June 2026)
This is a reasoning-and-arithmetic task with a long input, so the picker setting and context window matter more than raw coding skill.
| Model / plan | Why it fits roadmap planning | Note |
|---|---|---|
| ChatGPT Plus ($20), GPT-5.5 “Thinking” | Strong structured reasoning; switch the picker off “Instant” so it shows RICE work | In-app context ~320 pages; full 1M only on $200 Pro |
| Claude Pro ($20), Sonnet 4.6 | 1M-token context fits a fat brief plus past-quarter notes in one shot | Opus 4.7 on Max if the brief is large |
| Google AI Pro ($19.99), Gemini 3.1 Pro | 1M context + Workspace; handy if your inputs live in Google Sheets/Docs | Formerly “Gemini Advanced,” renamed early 2026 |
Any of the three handles a one-quarter plan. The deciding factor is usually where your source material already lives, and whether you remembered to switch the model into its thinking/reasoning mode so the RICE arithmetic is shown rather than guessed.
Recommended output structure
Three monthly columns, dependency arrows or notes, a slack-capacity row, a “NOT on this roadmap” callout, the cut order, and per-feature confidence ratings. Skip Gantt charts at the planning stage — they imply a precision you do not have yet. If your team runs continuous delivery rather than versioned releases, a Now / Next / Later layout often beats fixed months: the “Now” column is committed, while “Next” and “Later” stay rearrangeable as you learn.
How to check the output is usable
- Committed person-weeks land near 80%, not 100%
- Strategic must-ships are in the plan even when they would lose on RICE
- The “NOT on roadmap” section is specific and not empty
- Dependencies are named, and blockers are sequenced ahead of what they block
- The cut order is concrete (first, second, third), not “we’ll see”
- Each RICE row shows its Reach / Impact / Confidence / Effort inputs
Common mistakes
- Planning to 100% capacity. One surprise blows up the quarter; cap at ~80%.
- No “not doing” list. Stakeholders smuggle scope in mid-quarter.
- Skipping the dependency check. Features stall waiting on prerequisites.
- Letting AI estimate without an engineer. Sizes drift from your real codebase.
- Treating the roadmap as a contract. It is a hypothesis — re-plan monthly.
- Hiding strategic must-ships in regular slots. Make them visible, with the reason.
FAQ
Quarterly or monthly planning? Quarterly skeleton, monthly re-plan. Weekly is too noisy to be a roadmap. Keep the quarter as the unit of commitment and adjust month to month as confidence firms up.
Should I share the roadmap externally? Yes, but with caveats and ideally in a Now / Next / Later form. External roadmaps anchor expectations harder than internal ones, so never publish dated month-3 items you only rate 2/5 on confidence.
How do OKRs and the roadmap relate? The roadmap serves the OKRs, not the other way around. Each roadmap item should map to one outcome metric; if you cannot name the metric, the item is probably output for its own sake.
Should the 2026 roadmap account for AI agents as users? Increasingly, yes. If your product exposes an API or MCP surface, treat agent-facing capabilities as a parallel stream alongside human-facing features rather than an afterthought.
Related
- Roadmap planning prompts: alternative prompt variants
- Feature prioritisation prompts: score features before planning
- Feature prioritisation: RICE-style prioritisation in depth
- Project plan draft: once the roadmap is set, plan delivery
- PRD draft: write a PRD for each roadmap item
- User feedback clustering AI: turn user signal into roadmap input
- Roadmap summary AI: build the external-facing summary