Product

PRD Prompt — Consistent Product Requirement Documents

Problem, Goals, Non-Goals, numbered Requirements, Risks, Timeline — PRDs identical in structure across every author and feature.

Overview

PRD review breaks down when every author invents their own structure: requirements hide in prose, non-goals go missing, risks live in someone's head. This setup pins the six-section PRD skeleton under Strict consistency — every section present, exact order, no merging — with PRD-specific rules: requirements numbered (R1, R2…) so reviews can reference them, and every requirement testable ("no 'should be fast' without a number"). Required Tables keeps requirement matrices as actual tables.

Workflow

One prompt, every PRD
Generate once; each feature's details go below the prompt and come back in the same six sections.
Reference requirements by number
R1, R2… numbering is in the contract — review comments and test plans can finally point at something stable.
Defend the Non-Goals section
Strict mode means it can't be omitted or merged — scope creep's cheapest insurance.

Why This Works

Identical structure makes ten PRDs comparable in one sitting
The testability rule converts wishes into requirements
Strict consistency stops section drift between authors

Best for

Product teams with multiple PRD authors
Reviews that reference requirements by ID
Organizations templating their product process

Not for

Summarizing an existing PRD for execs — that's the Structured Summary Prompt
Tracking PRD revisions — that's the Prompt Version Diff for prompts, your VCS for docs

Use cases

Making every PRD reviewable in the same way
Forcing requirements to be numbered and testable
Keeping Non-Goals from silently disappearing

Customize This Resource

Opens this setup in Markdown Output Builder. Generate to get the full markdown prompt — then adjust the sections, table rules, and consistency level.

Open in Markdown Output Builder

Prompt Template

TASK
Create consistent product requirement documents for the product team.
Produce a new markdown document — there is no source text to summarize.

DOCUMENT
The document is a product requirements document (PRD).
- Number the requirements (R1, R2, …) so reviews can reference them.
- Every requirement must be testable — no "should be fast" without a number.

DOCUMENT STRUCTURE
Start with one "# " title line, then use exactly these sections, in this order:
## Problem
The user problem and the evidence it exists.
## Goals
What success looks like, measurable.
## Non-Goals
What is explicitly out of scope.
## Requirements
Functional requirements, numbered.
## Risks
Risks and their mitigations.
## Timeline
Phases and milestones.

MARKDOWN RULES
- One "# " title at the top; every section below it is a "## " heading.
- Use markdown lists for enumerations — no walls of prose.
- No HTML tags — pure markdown.

TABLE RULES
- Where content compares items, options, or features, you MUST use a markdown table.
- Every table needs a header row, a separator row, and one row per item — never collapse a table into prose.
- Keep the same columns for every row; use "—" for cells with no value.

CODE RULES
- Do not include code blocks.

CONSISTENCY RULES
- Use every section defined above.
- Keep the section order exactly as given.
- Do not omit headings, even when a section is short.
- Do not merge sections.
- Use the exact heading text as defined — no rewording.

OUTPUT RULES
- Return only the markdown document — no preamble, no closing commentary.
- Start directly with the "# " title line.
- Do not wrap the document in code fences.

Related Resources

Explore more resources that work well with this one.