Write a product requirements document (PRD)
A PRD with problem, goals, users, requirements, scope, and success metrics.
The prompt
Role: Act as a product manager writing a PRD for engineering and design review.
Context: Problem and evidence it matters: [PROBLEM_EVIDENCE]. Target users and jobs to be done: [USERS_JTBD]. Proposed solution direction: [SOLUTION_DIRECTION]. Success metrics and current baseline: [METRICS_BASELINE]. Known constraints (technical, legal, timeline): [CONSTRAINTS]. Explicitly out of scope: [OUT_OF_SCOPE]. Dependencies: [DEPENDENCIES].
Task: Draft the PRD: problem statement and evidence; goals and success metrics (with targets); user stories / requirements grouped and prioritised (must / should / could); UX and edge-case considerations at a high level; scope and explicit non-goals; risks and mitigations; dependencies; open questions for the review.
Format: A PRD with numbered sections and a requirements table (ID | requirement | priority | rationale | acceptance idea). ~700 words.
Verification: Check every requirement traces to the problem or a metric; flag requirements that are really solution preferences without a why. Mark assumptions.
Validation: Review as a tech lead and a designer: is the problem clear enough to solve freely, and are the constraints and non-goals unambiguous? Tighten what would cause churn in the review.
Highlighted [brackets] are blanks to replace with your own details.
Fill in the blanks and use this promptMore Product & UX Design prompts
What to fill in
- PROBLEM_EVIDENCE
- USERS_JTBD
- SOLUTION_DIRECTION
- METRICS_BASELINE
- CONSTRAINTS
- OUT_OF_SCOPE
- DEPENDENCIES
How this prompt is built
This prompt follows the RCTFVV structure (Role, Context, Task, Format, Verification, Validation). RCTFVV extends RCTF with two checking steps. Verification asks the model to review its own draft against your requirements; Validation asks it to flag assumptions and gaps you should confirm.
Related prompts
- Write user stories and acceptance criteriaTurns a feature into well-formed user stories with testable acceptance criteria.
- Run a post-launch review of a featureA blameless look at whether a shipped feature worked, what we learned, and whether to iterate, scale, or kill it.
- Stress-test my PRD before the review meetingA critical read of your PRD that finds weak reasoning, missing sections, and the questions reviewers will ask.
- Prioritize a product roadmap or backlogScores and orders features with a transparent model (RICE, value vs. effort) and builds a roadmap.