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 prompts force capacity-aware, dependency-aware planning, and they spit out a public version you can defend.
Best for
- Quarterly OKR planning
- Annual / 6-month roadmap
- Public roadmap for users
- Cross-team alignment doc
- Investor / board updates
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 Q 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 push-through is the wrong call.
Plan:
{paste}6. Roadmap for an investor update
Summarize 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-Q 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" — what changed and why), (c) what our estimation bias was (we 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 × 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}Common mistakes
- Roadmap as a wishlist with no capacity check or slack budget
- No anti-roadmap and no kill criteria — every item is theoretically “yes”
- Promising dates publicly that you wouldn’t bet $1k on
- Ignoring oncall, interviews, support rotation as real capacity drains
- Skipping the retro and shipping the same estimation bias next quarter
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