Product requirements document (PRD) template

Published 19 October 2026

A product requirements document (PRD) says what a product or feature is for — the problem, the users, what is in and out of scope, and how success will be measured — so that everyone who builds it, including an AI coding agent, builds the same thing. Below is a free template, a filled-in example, a shorter prd.md for Claude Code, Cursor or Copilot, and how a PRD differs from a BRD and a spec.

The sections that actually get read by engineers in my experience: problem statement, user stories with acceptance criteria, and a “what we’re NOT building” section. Everything else is for stakeholder alignment and can be as minimal as you want.

— r/ProductManagement, March 2026

What is a PRD?

One commenter’s case for keeping one: “The PRD is your source of truth for your feature. Why it needs to exist, what value it creates, why it’s important, who will use it” (r/ProductManagement, June 2026). How long it should be depends on the team; one commenter writes “a very simple one pager PRD. A paragraph max for each section” (r/ProductManagement), another “about 2-3 pages” (r/ProductManagement).

What a PRD includes

1. Problem: what is wrong today, for whom, and why now.
2. Users: who it is for, and who it is not for.
3. Goals and success metrics: what changes, measured how, by when.
4. Scope: what is in, and what you are not building.
5. Requirements: user stories, each with acceptance criteria.
6. User experience: the main flows, with links to the designs.
7. Non-functional requirements: performance, privacy, accessibility.
8. Dependencies and risks.
9. Release plan: phases, flags, who gets it first.
10. Open questions, each with an owner.
11. Changes and decisions, dated.

PRD template

Copy it into Google Docs, Notion, Confluence or Word. Everything in square brackets is yours to fill in.

PRODUCT REQUIREMENTS DOCUMENT

Feature:   [name]
Version:   [x.y]
Status:    [draft / in review / approved /
           building]
Owner:     [product manager]
Team:      [design, engineering, QA leads]

1. PROBLEM
   [what is wrong today, for whom, how we
   know, and why now]

2. USERS
   For:      [segment or persona]
   Not for:  [who this does not serve]

3. GOALS AND SUCCESS METRICS
   [metric]:  from [today] to [target] by
              [date]

4. SCOPE
   In:       [what this release does]
   Not building:  [what someone might
                  expect, but this release
                  leaves out]

5. REQUIREMENTS
   US-[n]:  As a [user], I want [action],
            so that [outcome].
            Acceptance criteria:
            - Given [context], when
              [action], then [result].

6. USER EXPERIENCE
   [main flows; links to designs]

7. NON-FUNCTIONAL REQUIREMENTS
   [performance, privacy, accessibility]

8. DEPENDENCIES AND RISKS
   [   ]

9. RELEASE PLAN
   [phases, feature flags, first users]

10. OPEN QUESTIONS
   [question]:  [owner], by [date]

11. CHANGES AND DECISIONS
   [x.y], [date]:  [what changed, and why]

PRD example

Part of a PRD for a feature in an invoicing product:

Feature:   Automatic payment reminders
Version:   1.1
Owner:     Product manager, billing

1. PROBLEM
   Small-business customers chase late
   invoices by hand. Support tickets about
   late payment doubled this year; 3 of
   the last 10 churn interviews named it.

2. USERS
   For:      account owners who send
             invoices
   Not for:  their customers (who receive
             them)

3. GOALS AND SUCCESS METRICS
   Average days to payment, customers with
   reminders on:  from 38 to 30 by end
                  of Q2
   Reminders turned on:  40% of active
   accounts within 60 days

4. SCOPE
   In:            email reminders before
                  and after the due date;
                  one schedule per account
   Not building:  SMS reminders; late
                  fees; a schedule per
                  customer

5. REQUIREMENTS
   US-1:  As an account owner, I want
          reminders sent automatically, so
          that I stop chasing invoices by
          hand.
          - Given reminders are on and an
            invoice is 3 days overdue,
            when the daily run starts,
            then the customer gets one
            reminder email.
          - Given the invoice is paid,
            then no further reminders are
            sent.

A PRD for Claude Code and other AI coding agents

A coding agent reads a PRD literally. One post on r/vibecoding compared two ways of starting Claude Code: typing what you want straight away ended in “this loop where it builds something close but not quite”; writing down first who uses it, the problem, what is in and out of scope and “what does done mean” — then “claude code basically one-shots it” (r/vibecoding, May 2026).

The same post names why it gets skipped: “the model is fast enough that you feel productive immediately so you skip the part where you actually decide what you’re building.” Addy Osmani’s advice for agent specs makes the same point: “Writing it like a PRD ensures you include user-centric context (“the why behind each feature”) so the AI doesn’t optimize for the wrong thing” (addyosmani.com).

What changes when the reader is an agent:

• Shorter. Problem, users, scope, requirements, done. Leave the business case to the PRD the people read.
• “Not building” is a list. An agent fills every gap it finds.
• Every requirement has a test. “Fast” and “simple” mean nothing to it; a Given / When / Then does.
• Constraints it must respect: the stack, what it must not change, where things go.
• One file in the repository, for example docs/prd.md, that the agent reads before it plans — point to it from CLAUDE.md or AGENTS.md.

# PRD: [feature]

## Problem
[two or three sentences: who has it, and why now]

## Users
[who it is for; who it is not for]

## Scope
In:
- [   ]
Not building:
- [   ]

## Requirements
### R1: [name]
[one behaviour, in a sentence]
Done when:
- Given [context], when [action], then [result].

## Constraints
- Stack: [languages, frameworks, services to use]
- Must not change: [behaviour, APIs, data to keep]

## Open questions
- [question], ask [who] before building it

For a single change, a spec is the smaller unit: one change, its acceptance criteria and its boundaries. In spec-driven development the PRD comes first — GitHub’s Spec Kit describes an idea that, through dialogue with the AI, “becomes a comprehensive PRD” (Spec Kit). More in what is spec-driven development.

PRD vs BRD vs spec

A BRD fits a client project with a sponsor; a PRD fits a product team. Either way, the functional specification or the specs come next.

How to write a PRD

1. Start from the problem, with engineering in the room. One poster spent three weeks on a PRD for accounts-payable automation; at sprint planning the tech lead “pulled up three tools on his laptop in about four minutes that covered most of what we had specced out” (r/ProductManagement, March 2026). The top reply: “You’re allowed to involve engineering in discovery. Some might even say it’s a good idea” (r/ProductManagement).
2. Make success measurable — a number, a baseline and a date.
3. Write what you are not building. Otherwise an agent fills the gap, and so does everyone else.
4. Write requirements as user stories with acceptance criteria — see the user story template and the acceptance criteria template.
5. Keep it short; link to designs and research instead of copying them in.
6. Review it with design and engineering, then version it. Every change after that gets a date and a reason in section 11.

Is the PRD dead?

“PRD almost always is not needed” drew 420 points on r/ProductManagement in April 2026. In another thread: “Best PRD is no PRD. I’d say PRD required only in case of really big changes/new product launches” (r/ProductManagement). The other side:

The real change is that with AI-driven development you can go straight to building and internal testing before you need to drive as much alignment because it’s now economical to do so […] This is merely a change in product development sequencing not some fundamental change in the need to drive alignment

— r/ProductManagement, April 2026

And from an engineer in the same thread: “I need them to prove when scope creep is real” (r/ProductManagement). Building got cheaper; agreeing on what to build did not. A short PRD is what is left of the long one. What else changes for the product manager when an agent builds from a spec: spec-driven development for product managers.

Keeping a PRD current

One poster’s experience:

I used to spend hours writing full length product specs and documentation, just to realize that no one actually read them and would just refer to the Jira tickets for requirements anyway.

— r/ProductManagement, June 2026

Keep the PRD for what tickets cannot hold — the problem, the users, the scope and the decisions — and let each ticket point to the requirement it builds. When a decision changes the scope, change the PRD first and date it; otherwise the PRD, the tickets and the prd.md the agent reads become three different versions of the product. That gap has a name: spec drift.

Where Specroot fits

This is the problem Specroot works on: one versioned record of what was agreed, readable by the people who decide and by the coding agent — instead of a PRD, tickets and a prd.md that drift apart. Specroot for teams using AI coding agents.