Build a product roadmap proposal for [PRODUCT AND AUDIENCE] for [ROADMAP HORIZON]. The business goal is [BUSINESS GOAL]. Here is the evidence: [USER AND MARKET EVIDENCE]. Current product context, technical constraints, and commitments are [CONTEXT AND CONSTRAINTS]. Do not invent user research, revenue impact, engineering capacity, competitor facts, dates, or stakeholder commitments. Separate evidence from assumptions. If the evidence is weak or contradictory, identify the research or measurement needed before committing to a solution. Produce these sections: 1. Product thesis: the target user, job or problem, desired behavior change, and business rationale in 120 words or fewer.
2. A prioritized roadmap table with no more than 6 initiatives. For each include: outcome, target user/problem, hypothesis, smallest valuable scope, non-goals, leading and lagging metrics, evidence strength, dependencies, risks, and decision owner. 3. Sequencing by Now, Next, Later. Use dates only when I supplied capacity and timing evidence; otherwise use decision gates. 4. For each Now initiative, write 3–5 testable requirements in “Given/When/Then” form and acceptance checks that a team can verify. 5. A validation plan naming the method, participant or data source, success threshold, and decision that the result will inform. 6. An assumptions and open-questions register. Before answering, check that every initiative connects to a stated user need and metric, and that no metric is presented as a forecasted result. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT AND AUDIENCE] | Describe the product and the specific user segment. | B2B invoice-approval web app for finance managers at 50–500 employee companies |
| [ROADMAP HORIZON] | Enter the period the roadmap should cover. | January through June |
| [BUSINESS GOAL] | State the business objective and any approved success measure. | Increase activated accounts from 42% to 55%, measured as first approval workflow completed within 14 days |
| [USER AND MARKET EVIDENCE] | Paste research findings, support themes, usage data, and market evidence with sources. | 18 interview notes: managers struggle to import approvers; funnel data shows 31% abandon on workflow setup; support tags cite CSV errors |
| [CONTEXT AND CONSTRAINTS] | List existing capabilities, team constraints, dependencies, commitments, and technical limits. | Two product squads; identity platform migration in March; enterprise SSO already committed; no mobile app work |
How to use
- Paste evidence with its source and date, then distinguish research findings from stakeholder requests.
- Replace the bracketed fields and ask the model to surface assumptions before it ranks ideas.
- Check that each Now item has an owner, a measurable decision gate, and acceptance criteria your team can actually test.
- Follow up with: “Create a one-page stakeholder readout that explains the trade-offs behind these three Now initiatives.”
Variations
Opportunity solution tree
Use this when you need to map possible solutions before committing to a roadmap.
Create an opportunity solution tree for [PRODUCT] focused on [OUTCOME]. Use this evidence: [EVIDENCE]. Return one outcome, 4–7 distinct opportunities stated as user problems, possible solutions beneath each, and assumptions or experiments for the most promising paths. Tag each branch by evidence strength and controllability. Do not treat feature requests as validated opportunities or invent research findings. End with the three highest-value questions to answer next. Ask up to 3 questions only if essential context is missing.
Release plan
Use this after an initiative has been chosen and needs a release sequence.
Create a release plan for [INITIATIVE] serving [USER SEGMENT]. Constraints and dependencies: [CONSTRAINTS]. Evidence and success measure: [EVIDENCE AND METRIC]. Produce a thin-slice launch scope, non-goals, dependencies, rollout stages, telemetry events, support and documentation needs, rollback triggers, and acceptance criteria. Separate confirmed commitments from assumptions. Do not state a launch date unless it is provided. Ask up to 3 questions only if a required input is absent.
Roadmap critique
Use this to assess an existing roadmap for weak evidence or false certainty.
Critique this roadmap: [ROADMAP]. Evaluate each item for user problem clarity, evidence quality, outcome linkage, metric definition, dependency visibility, scope discipline, and sequencing logic using this context: [CONTEXT]. Return a table of strengths, risks, missing evidence, and a concrete revision for each item. Flag feature lists disguised as strategy and dates unsupported by capacity data. Do not invent organization facts. Ask up to 3 questions only if necessary.
Tips
- Keep initiatives at the problem-and-outcome level until evidence justifies a solution; feature names often hide unresolved user needs.
- Use leading measures that can move during the roadmap period, such as setup completion, alongside business outcomes that may lag.
- Write non-goals for every near-term initiative to protect the smallest valuable scope from adjacent requests.
- Do not use dates as a substitute for sequencing; dependencies and learning gates are clearer when capacity is uncertain.
FAQ
Can AI prioritize my product roadmap?
It can organize trade-offs, but the priority decision still depends on evidence, strategy, capacity, and accountable owners. Give it your scoring rules rather than accepting a generic ranking.
How much research should I paste in?
Include the specific findings, source, sample, and date that support the decision. A short evidence table is often more useful than raw transcripts.
Should roadmap items be features?
A roadmap can include scoped work, but each item should begin with a user problem and desired outcome. That makes it possible to change the solution as you learn.