Roadmaps fail when they are wishlists pretending to be plans: every feature in, no slack, no kill criteria. By week three the team is behind and the doc is a lie. These 12 prompts force capacity-aware, dependency-aware planning, and they produce a public version you can defend.
TL;DR
- Paste your priority list plus real team capacity (engineers, designers, weeks net of holidays and oncall) into prompt 1; reserve 20% slack so the plan survives a mid-quarter scope change.
- The non-obvious wins are the anti-roadmap (prompt 7) and replanning triggers (prompt 5): they make “no” and “stop” explicit before pressure hits.
- For a plan a customer or board will read, draft with Claude Opus 4.7 (best long-form reasoning and writing). For ingesting a long vision doc or quarter of feedback, Gemini 3.1 Pro is cheaper on input and built for retrieval over its 1M-token window (all figures as of June 2026).
- These prompts are tool-agnostic. Run the output straight into Jira Product Discovery, Productboard, or a plain Now/Next/Later table.
Best for
- Quarterly OKR planning
- Annual or 6-month roadmap
- Public roadmap for users
- Cross-team alignment doc
- Investor or board updates
Which model to use (June 2026)
All three frontier models handle a full quarter of context comfortably; the difference is what you optimize for.
| Model | Context (June 2026) | Best roadmap job | Where it falls short |
|---|---|---|---|
| Claude Opus 4.7 | 1M tokens | Investor updates, anti-roadmap wording, retros (careful reasoning + writing) | Higher input cost ($5/1M in) |
| Gemini 3.1 Pro | 1M tokens | Decomposing a long vision doc or a quarter of feedback (cheapest input, $2/1M) | Less polished long-form prose |
| GPT-5.5 | ~320 pages in-app on Plus | Fast first-draft tables and sprint splits | Full 1M context only on the $200 Pro tier |
Practical rule: if the prompt mostly reads (vision doc, dependency dump, feedback), lean Gemini 3.1 Pro; if the output is a document people read (board update, public roadmap), lean Claude Opus 4.7. Paste the model the actual numbers, not adjectives, and it will respect the slack budget.
1. Quarterly roadmap from a priority dump
Below are priority features with rough size estimates (S/M/L). Team capacity this quarter: [N engineers, M designers, K weeks net of holidays/oncall]. Build a 3-month roadmap with monthly columns. Rules: (a) leave 20% slack, (b) flag overcommitment with red, (c) list cross-team dependencies, (d) name what slips first if the quarter goes sideways.
Features:
[paste]2. Public roadmap (Now / Next / Later)
Turn the internal plan into a user-facing roadmap with 3 columns: Now (shipping in 4 weeks), Next (this quarter), Later (next quarter+). Rules: only items with >80% confidence go in Now; strip internal codenames; no dates we might break; each item has a 1-line user benefit, not the feature name.
Internal plan:
[paste]3. Roadmap from a 2-year vision doc
Below is a 2-year vision doc. Decompose into a 6-month roadmap with 3 phases: Phase 1 (M1-2 foundation), Phase 2 (M3-4 differentiation), Phase 3 (M5-6 expansion). For each phase: 3-5 concrete shippable deliverables, one north-star metric to move, one explicit non-goal. End with a 1-paragraph "what we are explicitly de-prioritizing".
Vision:
[paste]4. Cross-team dependency map
My team's roadmap depends on [other team] for some items. For each dependent item list: (a) what we need from them (artifact, API, decision), (b) by when, (c) what unblocks us if they slip: a workaround, a delay, or a swap. Output as a table; flag any item where the workaround is "wait".
Roadmap + dependencies:
[paste]5. Replanning triggers
For this quarter's plan, define 3 replanning triggers. Each must be: (a) a specific event or numeric threshold (e.g., "DAU drops below X for 7 days", "Q1 NPS <30", "lead engineer leaves"), (b) the action it triggers (pause / re-scope / kill), (c) who decides. Triggers should fire only when pushing through is the wrong call.
Plan:
[paste]6. Roadmap for an investor update
Summarize the roadmap for a 1-page investor / board update. Sections: (a) shipped last quarter (with metric moved), (b) shipping this quarter (with success criteria), (c) the 2 big bets we are making, (d) the 2 things that could go wrong and our mitigation. Plain language, no buzzwords, no hockey-stick adjectives.
Roadmap + last-quarter results:
[paste]7. Anti-roadmap (what we will not do)
Based on the roadmap below, write an anti-roadmap: 5-7 things we are explicitly NOT doing this quarter. For each: (a) what it is, (b) who asked for it, (c) the real reason we are saying no (capacity / strategy / it's a bad idea), (d) when we will revisit. This doc gets shared with stakeholders, so word it firmly but not condescendingly.
Roadmap:
[paste]8. Last-quarter retro vs plan
Below is last quarter's plan vs actual. Run a retro: (a) what shipped on time, (b) what slipped and the real root cause (not "scope grew" but what changed and why), (c) what our estimation bias was (under by X% on engineering work? over on design?), (d) 3 specific changes for next quarter's planning process.
Plan + actuals:
[paste]9. Roadmap risk pre-mortem
Imagine it is the end of next quarter and the roadmap completely failed. Write the pre-mortem: 8 plausible failure modes ranked by likelihood times impact. For each: leading indicator we would see in week 2-3, the prevention action to take now, and the recovery move if it happens anyway.
Roadmap:
[paste]10. Bottoms-up capacity check
Before committing the roadmap, audit capacity bottoms-up. For each engineer / designer, list: (a) deterministic time (oncall, support rotation, interviews, planned PTO) for the quarter, (b) remaining net capacity in person-weeks, (c) which roadmap items they are blocking or carrying. Flag anyone above 90% utilization: they are the slip risk.
Team + roadmap:
[paste]11. Roadmap stakeholder comms plan
For each roadmap item, draft a 1-line update for 3 audiences: (a) eng team (technical, what we are building this week), (b) GTM/sales (what they can promise customers and when), (c) execs (status, risk, ask). Output as a table: same row, three columns. Update cadence: bi-weekly.
Roadmap:
[paste]12. Roadmap-to-sprints decomposition
Take the first 6 weeks of this roadmap and decompose into 3 two-week sprints. For each sprint: sprint goal in one sentence, the 4-6 items in scope sized in story points, the 2 items explicitly out of scope but tempting, and the demo we will show at sprint end. The first sprint must be conservative: we always underestimate sprint 1.
Roadmap:
[paste]Where to run the output
These prompts are tool-agnostic, but the output lands cleanest in a few places:
- Jira Product Discovery (Free for up to 3 creators; Standard $10/user/mo, $7.90 annual, as of June 2026): paste the prioritized list and dependency table as ideas. Atlassian Intelligence is fine for summarizing and rephrasing, not prioritizing, so let the prompt do the ranking.
- Productboard: better when the roadmap is customer-facing, since it has a public feedback portal that Jira Product Discovery lacks.
- A plain Now/Next/Later table (Notion, a Google Doc, or your wiki): for prompt 2, this beats any tool. Public roadmaps live or die on restraint, not features.
For the strategy and narrative side, see How to Use AI for Roadmap Planning. For external grounding on roadmap structure, Atlassian’s product roadmap guide and Marty Cagan’s outcome-vs-output framing are the usual references.
Common mistakes
- Roadmap as a wishlist with no capacity check or slack budget.
- No anti-roadmap and no kill criteria, so every item is theoretically “yes”.
- Promising dates publicly that you would not bet $1k on.
- Ignoring oncall, interviews, and support rotation as real capacity drains.
- Skipping the retro and shipping the same estimation bias next quarter.
- Treating the AI’s first plan as final: it does not know your politics, your tech debt, or which dependency team is already underwater. Use it to draft, then cut.
FAQ
Which AI model is best for roadmap planning in June 2026? For documents people read (board updates, public roadmaps), use Claude Opus 4.7 for its long-form reasoning and writing. For digesting a long vision doc or a quarter of raw feedback, Gemini 3.1 Pro is cheaper on input ($2 vs $5 per 1M tokens) and built for retrieval across its 1M-token window. GPT-5.5 is a fast drafter but the full 1M context is gated to the $200 Pro tier.
How much context can I paste at once? A full quarter of features, a 2-year vision doc, and your capacity numbers fit easily inside the 1M-token windows of Opus 4.7, Sonnet 4.6, and Gemini 3.1 Pro. On ChatGPT Plus the in-app window is roughly 320 pages, which still covers most single-team roadmaps.
Should the roadmap have dates? Internally, yes (prompt 1 uses monthly columns). Publicly, no: prompt 2 deliberately strips dates from Now/Next/Later because a missed public date costs more trust than a vague one. Only commit a date you would bet $1k on.
Why an anti-roadmap and replanning triggers? Most roadmaps quietly fail because nothing was ever a clear “no” and there was no agreed signal to stop. Prompt 7 makes the “no” list explicit so stakeholders stop relitigating it, and prompt 5 defines the numeric thresholds that justify re-scoping before the team burns a quarter pushing a dead plan.
Can I trust the AI’s capacity math? Treat it as a draft, not an oracle. The model does not know your real oncall load, interview burden, or which engineer is half-allocated to another team. Prompt 10 forces a bottoms-up check, but you still verify the person-week totals by hand before committing.
Related
- Feature prioritization prompts
- Project planning prompts
- PRD draft prompts
- How to Use AI for Roadmap Planning: Ambitious but Ship-able Quarterly Plan
- Summarize Your Product Roadmap With AI
- AI Sprint Planning: Sequence the Next 2 Weeks Without a Day of Whiteboard
Tags: #Prompt #Product startup #Roadmap