Product Requirements Document Template (+ a Full Worked Example You Can Copy)

Product Requirements Document Template (+ a Full Worked Example You Can Copy)

Last updated: 28 July 2026.

Most product requirements document template pages hand you an empty form. Atlassian's is four sections of instructions wrapped around a blank success-metrics table. Product School's carries "(with Example)" in the title and contains no example. The 12-section markdown block below is the whole template, ungated, copy-pasteable. Section 4 then fills every one of those 12 sections in for a complete worked build: a client invoice portal that reads PDFs with an LLM and routes the doubtful ones to a human. Copy the blank one. Read the filled one. Write yours.

Key Takeaways

• A PRD answers what to build and why; the technical design doc answers how.
• The 12 sections fit any project size. A one-pager is the same template with fewer rows.
• Non-goals must be written down. An AI coding agent cannot infer scope from omission.
• Acceptance criteria must be machine-checkable: "p95 under 400ms", never "fast".

Which PRD Shape Should You Use?

Pick the shape by who reads the document, not by how big the product feels. A single feature going to your own engineers needs a one-pager. A build handed to an outside team needs the full 12-section PRD, because the acceptance criteria double as sign-off gates. A spec going to an AI coding agent needs the same twelve sections sliced into phases.

The one page product requirements document template everyone asks for isn't a separate artifact. Lenny Rachitsky's widely-copied 1-pager, published with real examples in his newsletter, is the same skeleton with the ceremony stripped out. A one-pager isn't a different document. It's the same twelve sections with the empty rows deleted.

Agile teams ask this question a lot too, usually phrased as whether a PRD survives contact with a backlog. It does, as a one-pager: the PRD holds the why and the boundaries, the tickets hold the work.

The PRD Template (Copy-Paste Markdown)

Here's the whole thing as markdown, ungated, no email wall. Paste it into Notion, Confluence, Google Docs, Linear, Word, or commit it to GitHub as PRD.md and let it version alongside the code. People ask for this template in nine different formats; markdown is the one that survives a paste into all of them, and it's the only one an AI coding agent reads cleanly.

# PRD: [Product or feature name]

## 1. Header
- Owner (product):
- Engineering lead:
- Design lead:
- Status: Draft | In review | Approved | Shipped
- Last updated:
- Change history: date / author / what changed

## 2. Problem statement
One paragraph. Who hurts, how often, what it costs today. No solution language.

## 3. Goals & success metrics
| Goal | Metric | Baseline | Target | Measured by | Date |
|---|---|---|---|---|---|

## 4. Non-goals
Stated positively: "This phase does not include X."

## 5. Users & personas
Who uses it, what they already know, which device, how often.

## 6. User stories & acceptance criteria
As a [persona], I want [action], so that [outcome].
- Given [context], when [event], then [observable result].

## 7. Functional requirements
Numbered. One requirement per line. Testable. No sentence containing "and".

## 8. Non-functional requirements
Performance / security & tenancy / data residency & retention / accessibility / availability.

## 9. Dependencies & integrations
External systems, APIs, credentials, who owns access, lead time.

## 10. Milestones & phasing
| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|

## 11. Open questions & risks
| Question or risk | Owner | Needed by | Impact if unanswered |
|---|---|---|---|

## 12. Appendix & links
Designs, research, competitor notes, prior tickets, contracts.

The twelve sections, in order: header, problem statement, goals and success metrics, non-goals, users and personas, user stories with acceptance criteria, functional requirements, non-functional requirements, dependencies and integrations, milestones and phasing, open questions and risks, appendix.

What Should a PRD Include? The 12 Sections, and the Weak Version of Each

A product requirements document should include a problem statement, measurable goals, explicit non-goals, personas, user stories with acceptance criteria, functional and non-functional requirements, dependencies, milestones, open questions with owners, and a change history. Everything else is appendix. The test for each line is the one ISO/IEC/IEEE 29148:2018 applies to requirements generally: verifiable, unambiguous, singular.

Most PRDs fail that test in the same three places.

Two sections deserve more than they usually get.

Non-functional requirements are where scope quietly doubles. Performance, tenancy, data residency, retention, accessibility, availability: each of those is an engineering decision with a cost, and none of them appears in a user story. Put the security line here rather than in a hand-wave, and write it the way you'd want it checked, using something like our pre-launch security checklist as the source list. If the build has an AI component, the production-readiness requirements belong here too, not in a later "hardening" phase that never gets scheduled: our PoC-to-production checklist is the version we use.

Open questions need three columns, not one. Question, owner, needed-by date. A question with no owner is a decision nobody is making, and it will surface as a change request in week six. Worth saying: a PRD is what you write after you've decided to build rather than buy. If the problem statement still reads like a shopping list of features, the buy-versus-build call hasn't actually happened yet.

The Worked Example: An Invoice Portal PRD, Filled In

Here's a complete worked example, all 12 sections populated. The build: a client invoice portal for a mid-size logistics operator. Customers upload PDF invoices, an LLM extracts the line items, the system flags mismatches against the order record, and anything it isn't sure about goes to a human review queue. Stack: Next.js, Supabase/Postgres, one LLM extraction step. Copy it, print it, export it to PDF, whatever you need.

# PRD: Client Invoice Portal, Phase 1

## 1. Header
- Owner (product): Ops director, client side
- Engineering lead: Delivery lead, Techsy
- Design lead: Product designer, Techsy
- Status: Approved for build
- Last updated: 2026-07-28
- Change history:
  - 2026-07-14 / product / first draft
  - 2026-07-21 / engineering / added confidence-threshold rule to 6.2
  - 2026-07-28 / product / moved ERP write-back to non-goals

## 2. Problem statement
Ops staff receive customer invoices as emailed PDFs and re-key them into the
order system by hand. Volume runs past 300 invoices a week, average handling
time is about 6 minutes each, and roughly 4% carry a keying error caught only
at month-end reconciliation. Every correction costs a second pass and a call.

## 3. Goals & success metrics
| Goal | Metric | Baseline | Target | Measured by | Date |
|---|---|---|---|---|---|
| Cut manual handling | Avg. handling time | 6 min | under 90 sec | Ops dashboard, weekly median | 2026-11-01 |
| Cut keying errors | Invoices corrected at reconciliation | 4% | under 1% | Finance month-end report | 2026-12-01 |
| Contain review load | Share routed to human review | n/a | under 25% | Portal queue metrics | 2026-11-01 |

## 4. Non-goals
This phase does not support multi-currency invoices, ERP write-back, customer
self-service credit notes, or a mobile app. Extraction covers PDF only.
Photographs of paper invoices and scans below 200 DPI are rejected at upload
with a message explaining why.

## 5. Users & personas
- Ops clerk (primary, 6 people): works the exception queue all day, deep
  domain knowledge, desktop only.
- Customer AP contact (external, ~140 accounts): uploads invoices, low
  tolerance for account-setup friction.
- Finance manager (secondary): pulls the month-end report, needs a per-invoice
  audit trail.

## 6. User stories & acceptance criteria
6.1 As a customer AP contact, I want to upload an invoice PDF, so that I don't
have to email it and wait.
- Given a PDF under 20 MB at 200 DPI or better, when I upload it, then the
  portal returns a reference number within 5 seconds and shows "Processing".

6.2 As an ops clerk, I want low-confidence extractions held back, so that
nothing wrong is auto-approved.
- Given a parsed invoice, when extraction confidence for any line item is
  below 0.85, then the invoice routes to the review queue and is never
  auto-approved.

6.3 As an ops clerk, I want to see the mismatch in one place, so that I can
resolve it without opening the order system.
- Given an invoice matched to an order, when any line quantity or unit price
  differs from the order record, then the portal shows both values side by
  side and flags the delta.

6.4 As a finance manager, I want to filter invoices, so that I can close the
month.
- Given the invoice list, when I filter by vendor, date range and status, then
  results return in under 400ms at p95 and the empty state offers "Clear
  filters".

## 7. Functional requirements
1. Upload accepts PDF only, 20 MB maximum, one file per submission.
2. Extraction returns vendor, invoice number, date, currency, and line items
   with quantity, unit price and total.
3. Each line item carries a confidence score between 0 and 1.
4. Matching compares the extracted invoice to the open order by PO number.
5. Exceptions enter a queue ordered oldest first, assignable to one clerk.
6. Every state change writes an audit entry with actor, timestamp, prior value.
7. Approved invoices export as a CSV batch for the finance system.

## 8. Non-functional requirements
- Performance: invoice list p95 under 400ms. Extraction completes within 90
  seconds of upload at p95.
- Security & tenancy: per-tenant isolation enforced at the database row level.
  A customer can never read another customer's invoice. Verified by an
  automated test on every release.
- Data residency & retention: documents stored in the EU. Originals retained 7
  years, extraction payloads 90 days.
- Accessibility: queue fully keyboard-operable, WCAG 2.2 AA contrast.
- Availability: 99.5% monthly, support during business hours.

## 9. Dependencies & integrations
- Order records: read-only Postgres replica. Access owned by client IT,
  credentials needed by 2026-08-15.
- LLM extraction provider: contract and data-processing agreement signed
  before build starts.
- Email notifications: existing transactional provider, sender domain verified
  by the client.

## 10. Milestones & phasing
| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|
| P1 | Upload, extraction, confidence routing | 50 real invoices end to end, under 25% queued | 2026-09-19 |
| P2 | Order matching and mismatch view | Mismatch flagged correctly on 20 seeded cases | 2026-10-10 |
| P3 | Audit trail, CSV export, reporting | Finance closes one month in the portal | 2026-11-01 |

## 11. Open questions & risks
| Question or risk | Owner | Needed by | Impact if unanswered |
|---|---|---|---|
| Which PO number is authoritative when an invoice shows two? | Client ops director | 2026-08-08 | Matching logic blocked |
| Do the 12 largest customers send scanned or native PDFs? | Delivery lead | 2026-08-08 | Confidence threshold may be wrong |
| Is 7-year retention confirmed with client counsel? | Client finance manager | 2026-08-22 | Storage design and cost change |
| Extraction cost per invoice at 300/week | Delivery lead | 2026-09-05 | Unit economics unknown |

## 12. Appendix & links
Anonymized sample invoice set (40 files), order-table schema, current
handling-time study, Figma flows for upload and queue, signed statement of work.

Four choices in there are worth calling out, because the lazy version of each costs real money.

Section 3, the baseline. "6 minutes" is not decoration. Without a baseline you cannot tell whether the thing worked, and six months later somebody argues about it in a meeting with no data. The lazy version, "improve efficiency", makes the project unfalsifiable.

Section 4, the non-goal. ERP write-back moved into non-goals on 2026-07-28, after being assumed into existence during a review call. Writing it down as a non-goal cost one line and saved a scope argument.

Section 6.2, the confidence threshold. This is the rule our own first drafts most often miss. Leave it out and the system auto-approves invoices a human should have seen, which is the exact failure that erases the time savings you promised in section 3.

Section 11, the owners. Every open question has a name and a date. That column is the difference between a document and a to-do list nobody owns.

The PRD tells you what. It doesn't tell you how long or how much, which is a separate exercise: see scoping the build for that half. And a non-goal you didn't write down is a feature someone will build.

How Do You Write a PRD an AI Coding Agent Can Actually Build From?

A PRD written for an AI coding agent trades brevity for explicitness. The agent has no hallway context, no shared history, and no instinct for what you obviously didn't mean. Four rules cover most of the difference, and they come from watching specs succeed and fail across our own agent-assisted builds.

1. State non-goals positively. Humans infer scope from omission. Agents don't. "Do not add authentication in this phase" has to be a sentence in the document, or auth gets built, tested, and handed back to you.

2. Phase-size the work. One 40-page monolith produces a confident, sprawling, half-correct pull request. Slice the PRD into passes an agent finishes in one bounded run, each with its own exit criteria.

3. Make acceptance criteria machine-checkable. "Fast" is not a requirement, it's a mood. "p95 under 400ms on the invoice list endpoint" is a test the agent can write before it writes the feature.

4. Put file paths and stack constraints in the document, not in chat. Chat context evaporates between sessions. The spec doesn't. This is also why Claude Code's plan mode matters: it reads your files and proposes a plan without editing anything until you approve, and that approval step is far more useful when the plan is being checked against a written spec instead of your memory of what you asked for.

Here's the invoice portal, sliced into one phase an agent can execute in a single pass.

# Build task: Invoice upload and extraction (Phase 1 of 3)

## Stack constraints (do not substitute)
Next.js 15 App Router, TypeScript, Supabase Postgres with row-level security,
Vercel deploy. No new dependencies without asking first.

## Files you may create or edit
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Do not touch
- lib/auth/*  (auth ships in Phase 2; do not add sign-in flows now)
- Anything under app/(marketing)/
- The existing orders schema. Read it. Never migrate it.

## Acceptance criteria (write these as tests first)
1. POST /api/invoices rejects non-PDF with 415 and files over 20 MB with 413.
2. A line item with confidence < 0.85 sets invoice.status = 'review',
   never 'approved'.
3. Every insert writes an audit row with actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= returns under 400ms on a
   10,000-row seed.

## Out of scope for this pass
Order matching, mismatch UI, CSV export, email notifications.

Three things changed versus the human version: file paths appeared, a do-not-touch list appeared, and the acceptance criteria became assertions instead of sentences. Which agent you hand it to matters less than people think, though the comparison of coding agents is worth a read before you commit. Keep requirements and project rules in separate files: Cursor rules and CLAUDE.md hold conventions and tooling, the PRD holds what to build. If you want AI help producing the scope in the first place rather than consuming it, that's a different workflow. And for the extraction step itself, the model choice and evaluation loop are their own AI integration work.

What Changes When the PRD Goes to an Outside Team

When the PRD goes to an agency or contractor, it stops being an alignment doc and starts being contract language. Ambiguity that an in-house team resolves with a two-minute conversation becomes a change request with a price. PMI's Pulse of the Profession found 47% of unsuccessful projects miss their goals because of inaccurate requirements management. That's the whole reason this document exists.

Three sections carry disproportionate weight in that setting. Acceptance criteria become sign-off gates, so they need to be observable by someone who isn't an engineer. Open questions need a named owner on the client side, because the vendor cannot answer them and will build around the gap. And change history stops being bureaucratic: it's the record of what was agreed when, which is the first thing anyone reaches for during a disagreement.

The line we've watched go wrong more than once is some version of "users can export their data". Nobody writes down which format. The expensive version of that, for us, shipped as a CSV export when the client had meant a formatted PDF invoice pack with their branding on it, and redoing it burned roughly a week of engineering nobody had scoped. The honest reading is that the fault sat in the document, not the delivery. An acceptance criterion would have caught it in five minutes: given an export request, when the file is generated, then it is a PDF matching the supplied layout. A non-goals line would have caught it too, from the other direction. So that's now a rule in our discovery: any requirement hanging on a noun like "export", "report" or "notification" gets a format, a trigger and a worked example attached before a statement of work is signed.

That's most of what how we run web application builds actually is: turning the vague half of a client's spec into testable lines before anyone writes code.

What r/ProductManagement Actually Says About PRD Templates

Search product requirements document template reddit and you'll find the same complaint on repeat in r/ProductManagement: template bloat. PRDs nobody reads. Sections filled in because the template had a heading, not because anyone needed the content. Documents that go stale the day after kickoff and get quietly replaced by a Slack thread. It's a fair criticism of most templates, including several in the top ten results for this query.

Our answer: delete sections rather than fill them with nothing. Personas go first when the users are obvious. Appendix goes second. Milestones can live in the tracker instead. The one we never delete is non-goals, because it's the only section that gets shorter the more work you do and the only one that reliably prevents the argument you'd otherwise have in week six.

Frequently Asked Questions

What is a product requirements document?

A product requirements document (PRD) states what a team is building and why: the problem, the goals and their metrics, the non-goals, who it's for, and the requirements that define done. It deliberately excludes implementation detail, which belongs in a technical design doc written afterwards by engineering.

How do you write a product requirements document?

Start with the problem statement and refuse to use solution language in it. Add measurable goals with a baseline and a target date, then write non-goals. Fill in personas, user stories with Given/When/Then acceptance criteria, functional and non-functional requirements, dependencies, milestones, and open questions with owners.

What should a PRD include?

Twelve sections: header with change history, problem statement, goals and success metrics, non-goals, users and personas, user stories with acceptance criteria, functional requirements, non-functional requirements, dependencies and integrations, milestones and phasing, open questions and risks, and an appendix. Anything that doesn't fit one of those is probably not a requirement.

How long should a PRD be?

One to two pages for a single feature, three to five for a product phase, five to eight when an outside team is building it and the acceptance criteria act as sign-off gates. Length follows the number of decisions being recorded, not the size of the product. Empty sections should be deleted, not padded.

Is a PRD the same as a BRD?

No. A business requirements document states the commercial outcome the organisation wants and the constraints around it, usually before a solution is chosen. A PRD describes the product that delivers it: users, behaviour, acceptance criteria, non-goals. In smaller companies the BRD is often just the problem statement section.

Do agile teams still write PRDs?

Yes, usually as a one-pager. The backlog holds the work, but tickets are terrible at holding the why, the non-goals, and the success metric. Teams that skip the PRD entirely tend to rediscover it as a Confluence page called "context" three sprints into the project.

Can you write a PRD in markdown?

Markdown is the best format for one. It pastes cleanly into Notion, Confluence, Google Docs and Linear, versions in Git next to the code as PRD.md, diffs properly in a pull request, and is the only format an AI coding agent reads without losing structure. The template above is markdown for exactly those reasons.

How do you write a PRD for an AI coding agent?

Be explicit where you'd normally be brief. State non-goals positively, because an agent cannot infer scope from omission. Slice the document into phases finishable in one pass. Write acceptance criteria as assertions with numbers. Name the files the agent may edit and the ones it may not touch.

What's the difference between a PRD and a technical design doc?

The PRD answers what and why: problem, users, behaviour, acceptance criteria, non-goals. The technical design doc answers how: architecture, data model, API contracts, trade-offs considered. Product usually owns the first, engineering the second, and the design doc should be readable as a response to the PRD.

Who owns the PRD, product, engineering, or the client?

Product owns the document and the decisions in it. Engineering owns the feasibility feedback and the non-functional requirements. On agency builds the client owns the problem statement, the goals, and every open question about their own business. Shared ownership of the whole document usually means nobody maintains it.

Wrapping Up

Three things to take away. The template is only useful once it's filled in, so copy the worked example's shape rather than the blank one. Non-goals are the highest-value section per word in the document and the first one people skip. And acceptance criteria written as testable assertions serve two readers equally well: an engineer signing off a delivery, and an agent writing the test.

If you're writing a PRD to hand to an outside team and want a second pair of eyes on it before it becomes a contract, we're happy to read it and mark the ambiguous lines. That's the same pass we run on our own web application builds.