Product

PRD Prompt — Consistent Product Requirement Documents

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

Open in Markdown Output Builder

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.

How to use this resource

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

FAQ

How does the PRD prompt keep requirements referenceable in review comments?

It bakes numbering into the DOCUMENT section: functional requirements are listed as R1, R2, … so a review comment or test plan can point at a stable ID instead of quoting prose. The testability rule pairs with it — no "should be fast" without a number. markdown-output-builder formats this into copyable markdown; you paste feature details below the prompt and run it in your assistant.

What's the difference between this PRD prompt and the Structured Summary Prompt?

This one generates a fresh PRD from scratch — the TASK line says "there is no source text to summarize" — pinning six sections in fixed order (Problem, Goals, Non-Goals, Requirements, Risks, Timeline) with numbered requirements. Its notFor sends "summarizing an existing PRD for execs" to the Structured Summary Prompt instead. Use this to author; use Summary to compress a document you already have.

Will this prompt guarantee my requirements are actually testable and complete?

It enforces the wording, not the truth. The CONSISTENCY RULES guarantee all six headings appear in exact order with none merged or omitted, and the testability rule bans vague phrasing like "should be fast" without a number — but markdown-output-builder only formats the text. It can't confirm a requirement is genuinely measurable or that your Non-Goals are right. Run it in your assistant and review the output yourself.

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

Copy it as-is, or use Open in Markdown Output Builder to load it pre-filled and customize it with your own context.

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.

More resources from Markdown Output Builder

Resource

Markdown Output Prompt — Lock the Document Structure

The contract that stops AI documents from restructuring themselves: a pinned section skeleton, forced tables, and strict consistency rules.

Prompt Engineering

Resource

README Prompt Template

Overview, Installation, Usage, Examples, Configuration — the README skeleton with required, runnable code examples.

Engineering

Resource

API Documentation Prompt

Overview, Authentication, Endpoints, Error Handling, Rate Limits — endpoint docs in an identical structure, with parameter tables and runnable examples forced.

Engineering

Resources that pair well

Resource

Executive Summary Prompt

Summary, Why It Matters, What Happens Next — the executive summary contract for readers who will never open the source.

Operations

Resource

Force JSON Output from AI

Stop getting 'Sure, here is the JSON…' — the output-contract pattern that forces models to return only parseable JSON: schema, example, and a strict rule block.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Markdown Output Builder

Build prompts that produce documents in a fixed structure — headings, sections, and tables.

Structured Output

Workflows that use this resource

Workflow

AI Product Requirements Workflow

Turn a fuzzy business need into requirements a team can build from — interrogate the need into concrete requirements, shape them as user stories, and write the PRD.

3 steps 30–60 minutes

Guides for this resource

Guide

How to Write a Product Requirements Document (PRD) With AI

A PRD earns its keep by separating the feature somebody asked for from the problem they actually have — then fixing scope, numbering the requirements, and handing the open questions to the people who own them.

Prompt Engineering

Tip: Save time by exploring related resources and tools that integrate with this resource.