Draft a product requirements document for [PRODUCT OR FEATURE]. The user problem is [USER PROBLEM], affecting [TARGET USERS] in this context: [USER EVIDENCE]. The desired business or user outcome is [SUCCESS OUTCOME]. These are the constraints, dependencies, and non-goals: [CONSTRAINTS]. The product surface and team context are [PRODUCT CONTEXT]. Ask up to 3 clarifying questions only if a required input is missing. Then produce a PRD with these sections: 1. Problem statement, target users, job to be done, and evidence. Separate observed evidence from assumptions. 2. Goals and non-goals, including what is explicitly out of scope for this release. 3. User stories and end-to-end acceptance criteria written as observable behavior. Include permissions, empty states, loading and error states, validation, accessibility considerations, and mobile or responsive behavior where relevant.
4. Functional requirements prioritized as must, should, could, and won't for this release. State dependencies, data inputs, and ownership questions. 5. User flow in numbered steps, plus key edge cases and abuse or failure scenarios appropriate to the feature. 6. Success metrics: a primary outcome metric, guardrail metrics, baseline if supplied, measurement method, and decision threshold. Do not make up baselines. 7. Open questions, risks, and a lightweight rollout and learning plan. Avoid solution-first language until the user problem and evidence are clear. Do not turn internal implementation details into requirements unless they change user behavior, risk, or acceptance. Do not invent research, technical limits, legal requirements, analytics data, or stakeholder approvals. Requirements must be testable: replace “easy,” “fast,” and “intuitive” with conditions a reviewer can observe or measure. Before answering, check that each must-have requirement traces to the stated problem or a necessary constraint, and flag requirements that lack acceptance criteria or evidence. Check that non-goals prevent plausible scope creep.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT OR FEATURE] | Name the product area or feature being specified. | Saved reply templates in customer support inbox |
| [USER PROBLEM] | Describe the user pain, current behavior, and why it matters. | Support agents repeatedly type the same account-access steps and cannot keep approved wording consistent |
| [TARGET USERS] | Define the user segment, role, and relevant permissions. | Support agents and team leads; only leads can create shared templates |
| [USER EVIDENCE] | Paste research findings, support tickets, analytics, or validated observations. | 18 of 25 reviewed tickets used one of five repeated responses; agents asked for copy-and-paste snippets in two weekly feedback sessions; no time-saved baseline is available. |
| [SUCCESS OUTCOME] | State the intended user or business outcome. | Agents can insert approved replies quickly while leads can maintain shared language |
| [CONSTRAINTS] | List deadlines, technical limits, dependencies, policy needs, and non-goals. | Desktop web only in v1; no AI generation; templates must retain audit history; launch before the November support peak |
| [PRODUCT CONTEXT] | Describe the product surface, platforms, team, and existing workflow. | Existing React inbox with role-based access and a rich-text composer |
How to use
- Start with observed behavior and evidence, then state the decision or outcome the feature should change.
- List explicit non-goals before drafting requirements to keep the first release bounded.
- Test each acceptance criterion with a realistic user flow, including a denied permission and an error state.
- Send this follow-up: “Create a QA test matrix from the acceptance criteria, grouped by role, happy path, edge case, and regression risk.”
Variations
Discovery brief
Use this before committing to a solution.
Create a product discovery brief for [OPPORTUNITY] affecting [TARGET USERS]. Here is the current evidence: [EVIDENCE]. The decision we need to make is [DECISION]. Produce a problem framing, jobs to be done, assumptions, competing hypotheses, existing alternatives, research gaps, and a ranked plan for [TIMEFRAME]. Separate evidence from interpretation. Do not propose a feature as settled or invent user needs. Include interview questions and behavioral signals that could invalidate the leading hypothesis.
PRD critique
Use this to find gaps in an existing requirements document.
Critique this PRD: [PRD TEXT]. The feature serves [TARGET USERS] and its intended outcome is [OUTCOME]. Return a structured review of unclear problem framing, unsupported assumptions, missing non-goals, untestable requirements, incomplete permissions, missing states, metric problems, dependencies, and rollout risks. For each issue, explain why it matters and suggest a specific question or rewrite. Do not invent requirements. Finish with the five highest-risk ambiguities for the product, design, and engineering leads to resolve.
Experiment spec
Use this for a reversible product test.
Write an experiment specification for [EXPERIMENT IDEA] for [TARGET USERS]. The hypothesis is [HYPOTHESIS], based on [EVIDENCE]. Constraints are [CONSTRAINTS]. Produce the user experience, eligibility, control and treatment definition, primary metric, guardrails, instrumentation events, sample or duration assumptions, stop conditions, and interpretation rules. Separate known baselines from unknowns. Do not claim statistical significance requirements without the needed traffic and baseline data.
Tips
- A PRD earns its detail from uncertainty: specify the user behavior, rules, and exceptions that a team could otherwise interpret differently.
- Write non-goals as concrete exclusions, such as “no bulk editing in v1,” so they can prevent scope creep during implementation.
- Acceptance criteria should expose the thing a tester can see, including who can act, what happens on invalid input, and what the system records.
- Pair a primary success metric with guardrails so a feature cannot look successful while worsening a related experience or operational cost.
FAQ
What is the difference between a PRD and a user story?
A user story is one statement of user value; a PRD connects the problem, scope, requirements, risks, metrics, and decisions across the work.
Can AI write technical specifications too?
It can organize technical input, but architecture, security, privacy, and performance decisions need review by the responsible technical owners.
How detailed should a PRD be?
Detailed enough that design, engineering, QA, and stakeholders can agree on expected behavior and success. Do not use it to prescribe implementation that is not necessary for that agreement.