The task
A new quarter starts. You have 10-15 feature ideas, a team with finite capacity, and a strategic goal. You want a roadmap that’s 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 roadmap that survives week 2 is one planned to ~80% capacity, not 100%.
When AI helps — and when it does not
AI is excellent at structure: monthly columns, dependency mapping, capacity arithmetic. It is poor at estimating engineering effort; that requires people who have touched the codebase. AI’s estimates are placeholders until engineering anchors them; do not commit to a date based on AI sizing alone.
What to feed the AI
- 10-15 feature ideas with one-line descriptions
- Team capacity in person-weeks (engineers, designers, separately)
- Strategic goal for the quarter
- Strategic must-ships (regardless of score) and the reason
- Past similar quarters: what shipped, what slipped
- Off-limits: tech debt areas frozen, regulatory work, team holidays
Copy-ready prompt
Plan a 3-month roadmap.
Strategic goal: <line>
Strategic must-ships (with reason): <list>
Capacity: <eng weeks / design 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 3-column monthly roadmap with features assigned by month
2. Feature sizing (in person-weeks, with confidence)
3. Dependency map — what blocks what
4. Slack capacity (~20%) reserved for reactive work, with rule for using it
5. A "NOT on this roadmap" section — 3 things explicitly deferred, with the reason
6. The "if Q goes sideways" cut order — what gets dropped first to second to third
7. Confidence rating per feature (1-5) based on AI's sizing certainty
Plan to 80% capacity. Reserve 20% for surprises. Do not assign features to month N+2 with low confidence.For platform / infra-heavy quarters: “Add a separate ‘maintenance & infra’ track with a fixed % of capacity — typically 20-30%.”
Recommended output structure
Three monthly columns, dependency arrows or notes, slack capacity row, “NOT on this roadmap” callout, cut order, and confidence ratings. Avoid Gantt presentation at the planning stage; too much detail too early.
How to check the output is usable
- The total person-weeks come out to 80%, not 100%
- Strategic must-ships are in the plan even if they would lose on RICE
- The “NOT on roadmap” section is specific and not empty
- Dependencies are named, so features that block other features are sequenced
- The “if Q goes sideways” cut order is specific (first, second, third)
Common mistakes
- Planning to 100% capacity: one surprise blows up the quarter
- No “not doing” list, so stakeholders smuggle scope in mid-quarter
- Skipping dependency check: features stall waiting for prerequisites
- Letting AI estimate without engineering: sizes drift from reality
- Treating roadmap as a contract. It’s a hypothesis; re-plan monthly
- Hiding the strategic must-ships in regular slots: make them visible
Practical depth notes
For How to Use AI for Roadmap Planning: Ambitious but Ship-able Quarterly Plan, the difference between a usable AI result and a generic one is the input packet. Give the model the audience, the current draft or raw material, the desired format, the decision you need to make, and two examples of what good and bad output look like. Ask it to preserve facts first, then improve structure or wording second.
After the first response, do a separate review pass. Look for missing constraints, invented details, weak calls to action, and language that sounds plausible but does not match the real situation. The best final output should be easy to use immediately: clear owner, clear next step, and no hidden assumption that someone else has to untangle. A stronger version of this workflow also defines the handoff. Decide who will use the output, what they should do next, and what information would make them reject it. If the deliverable is copy, test whether it has a single clear action. If it is analysis, test whether it separates observation from recommendation. If it is planning, test whether dates, owners, and tradeoffs are explicit enough for someone else to execute. One final check: compare the finished result against the original goal in a single sentence. If that sentence is hard to write, the output is probably polished but unfocused. Tighten the goal, remove decorative language, and rerun only the weak section instead of regenerating the entire piece.
FAQ
- Quarterly vs monthly planning? Quarterly skeleton, monthly re-plan. Weekly is too noisy.
- Should I share the roadmap externally? With caveats. External roadmaps anchor expectations harder than internal.
- Public OKRs and the roadmap? Roadmap should serve OKRs, not the other way.
Related
- Roadmap planning prompts: alternative prompt variants
- Feature prioritisation prompts: score features before planning
- Feature prioritisation: RICE-style prioritisation
- Project plan draft: once roadmap is set, plan delivery
- PRD draft: PRDs for each roadmap item
- User feedback clustering AI: roadmap input from user signal
- Roadmap summary AI: external-facing roadmap summary