Act as a senior product manager helping me make a specific product decision. Do not assume that a loud customer request, a competitor feature, or an executive idea is automatically the right solution. Context Product and user: [PRODUCT AND USER] Decision or opportunity: [DECISION] Evidence available: [EVIDENCE] Business and delivery constraints: [CONSTRAINTS] Current goal and success metric: [GOAL AND METRIC] Stakeholders and known disagreements: [STAKEHOLDERS]
Work in this order: 1. Restate the decision as a falsifiable problem statement. Separate the user problem, business problem, proposed solution, and assumptions; do not merge them. 2. Assess the evidence by source, sample, recency, and likely bias. Distinguish observed behavior from stated preference. Identify what would change the decision. 3. Define the target segment and job to be done. State who is deliberately out of scope. 4. Offer two or three credible options, including doing nothing or running a smaller test where appropriate. Compare expected user value, strategic fit, effort, dependencies, risks, and metric impact. 5. Recommend one option with a narrow first release. Write acceptance criteria, non-goals, instrumentation events, and a decision rule for expanding, revising, or stopping it. 6. List the next five actions, each with an owner role and the question it resolves. Produce a 700-1,000 word product decision brief with sections: Decision, Evidence assessment, Options, Recommendation, First-release scope, Measurement plan, Risks, and Open questions. Use a compact comparison table for the options. Ask up to three clarifying questions only if a required input is missing; otherwise make conditional assumptions explicit. Before answering, check that every recommendation traces to supplied evidence or a clearly labeled assumption. Also flag any metric that could improve while harming the intended user outcome.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT AND USER] | Describe the product, target user, and relevant point in their workflow. | A scheduling tool for independent dental practices; office managers booking hygiene appointments. |
| [DECISION] | State the product decision, opportunity, or proposed initiative to evaluate. | Decide whether to add an online waitlist that fills cancelled appointments automatically. |
| [EVIDENCE] | Paste research notes, support themes, usage data, experiment results, or competitor observations. | 18 of 25 interviews mention cancellation gaps; 31% of practices manually text patients; 8% of users asked for a public waitlist. |
| [CONSTRAINTS] | List timeline, team capacity, technical, legal, budget, or platform constraints. | Two engineers for six weeks; must use existing SMS provider; no patient data may be exposed to other patients. |
| [GOAL AND METRIC] | Name the business goal and the primary metric, baseline, and desired movement if known. | Increase completed appointment slots; baseline 84% filled capacity; target 88% within 90 days. |
| [STAKEHOLDERS] | Name the stakeholder roles and any known priorities or disagreements. | Head of sales wants a visible feature; support worries about opt-out handling; engineering prefers internal-only automation first. |
How to use
- Paste the decision, evidence, metric baseline, and real constraints; do not summarize away conflicting research.
- Check that the recommended first release has explicit non-goals and measurable instrumentation before sharing it.
- Ask: “Turn the first-release scope into a PRD with user stories, edge cases, and acceptance criteria.”
- Ask: “Create a one-page stakeholder pre-read that explains the tradeoff without overselling certainty.”
Variations
PRD draft
Use this when the decision is made and the team needs build-ready scope.
Write a product requirements document for [FEATURE] in [PRODUCT] for [TARGET USER]. Base it only on [RESEARCH AND DECISION]. Include the user problem, job to be done, user flow, user stories, acceptance criteria, non-goals, edge cases, dependencies, analytics events, and launch criteria. Separate requirements from implementation suggestions. Produce 800 words maximum. Ask up to three questions only if an essential detail is absent. Check that each requirement supports the stated user problem and flag unsupported requirements.
Experiment design
Use this when a team needs to test an assumption before committing engineering time.
Design a product experiment for [ASSUMPTION] affecting [USER SEGMENT] in [PRODUCT]. Available evidence is [EVIDENCE], and the constraint is [CONSTRAINT]. Specify the hypothesis, primary metric, guardrail metrics, population, comparison condition, minimum useful duration, qualitative follow-up, and decision thresholds. Include likely confounders such as seasonality, novelty, selection bias, and instrumentation gaps. Produce a one-page experiment plan. Do not invent baseline data; identify missing inputs and ask up to three questions.
Roadmap tradeoffs
Use this when several initiatives compete for the same quarter.
Help prioritize [INITIATIVES] for [TIME PERIOD] in [PRODUCT]. Our strategy is [STRATEGY], capacity is [CAPACITY], and evidence is [EVIDENCE]. Score each item for customer problem severity, reach, confidence, strategic fit, effort, dependency risk, and reversibility, explaining each score. Do not use a single numeric score as the final decision. Produce a ranked table, a recommended portfolio, items to defer, and the evidence needed to revisit them. Flag initiatives that are solutions without a validated problem.
Tips
- Keep raw quotes and behavioral data in the evidence input; a count of interview mentions is weaker than the context behind the mention.
- Define a guardrail metric before committing to a growth metric, such as support contacts or successful completion rate alongside conversion.
- A first release should test the core uncertainty, not reproduce the full competitor feature set.
- Use non-goals to prevent a PRD from quietly becoming a stakeholder wish list.
FAQ
Can AI prioritize my roadmap for me?
It can structure tradeoffs and expose missing evidence, but it cannot validate customer demand or choose your company strategy. Keep the decision owner and the source evidence visible.
What evidence should I include?
Use interview excerpts, observed usage behavior, support tickets, funnel data, prior experiments, and technical constraints. Label anecdotes and assumptions clearly.
Should I paste confidential customer research?
Remove names, contact details, and sensitive account information first. Preserve the relevant behavior, segment, and timing.