How to write a PRD (with a free template and a worked example)

To write a PRD, start with the problem and the evidence for it, then set a measurable goal, define who it is for and what is out of scope, and only then describe the solution as user stories with acceptance criteria. A good product requirements document fits on a few pages, names its open questions honestly and gets reviewed with engineering and design before anyone writes code. Below is a copyable PRD template, a fully worked example and the mistakes that make PRDs go unread.

Key takeaways

• A PRD (product requirements document) explains what you are building, for whom and why, and how you will know it worked. It is not a technical design.
• The most valuable sections are the problem statement, success metrics, non-goals and open questions. Most weak PRDs skip at least two of them.
• Match the length to the risk: a one-pager for small, reversible changes, a full PRD for anything that touches money, compliance or several teams.
• Write acceptance criteria that a tester (or an AI coding agent) could check without asking you what you meant.
• A PRD is a living document. Date your changes and keep a decision log so people can see why things changed.

What is a PRD?

A PRD is a short written document that defines the problem a product or feature solves, who it is for, what success looks like and what the release must do, so that design, engineering, QA and business teams can build and ship it without constant clarification.

Your product roadmap says what you are betting on this quarter; the PRD turns one bet into something a team can build; the engineering design doc then answers how.

A PRD is not a list of screens (those live in Figma, linked from the PRD), not a technical spec and not a contract. It should change as you learn, with the changes recorded.

Do you still need a PRD in 2026?

Yes, but probably a shorter one than you were taught to write. Long requirement documents go stale; the fix is to write less, and write the right things.

A PRD earns its keep when more than one team is involved, when the change touches money, personal data or regulation, when people will ask "why did we build it this way?" six months later, and when you build with AI coding tools that do exactly what you specify. For a two-person team changing button copy, a ticket is enough.

The sections of a good PRD

These are the sections that consistently pull their weight. The order matters: problem before solution, always.

Success metrics need one primary metric, two or three early input metrics and at least one guardrail that must not get worse, each with a baseline and a target. If the feature serves your north star metric, say how. Non-goals are the cheapest scope control there is, and they show reviewers you parked their pet idea on purpose.

How to write a PRD, step by step

1. Collect the evidence first. Pull the data, read support tickets and run a short round of customer interviews. It will usually change your problem statement.
2. Write the problem statement in one paragraph. Who has the problem, what they are trying to do, what gets in the way, and what it costs them or the business.
3. Define success before the solution. Write the primary metric, baseline and target. If you cannot name a metric, you probably do not understand the problem yet.
4. List non-goals. Aim for three to five.
5. Sketch the solution in plain language. One or two paragraphs and a link to low-fidelity designs. Resist detail until the approach is agreed.
6. Break it into user stories with acceptance criteria. Prioritise each one (P0 must ship, P1 should ship, P2 nice to have). If the list is long, run it through a prioritisation framework rather than gut feel.
7. Walk the failure states. No network, payment timeout, duplicate tap, user on an old app version, a second language.
8. Review with your tech lead and designer first. They find the expensive gaps. Then circulate it with a comment deadline.
9. Keep it alive. Record each decision with a date, and update the PRD when reality diverges.

A free PRD template you can copy

Copy this into Notion, Google Docs, Confluence or a Markdown file in your repo. Delete any section that does not apply, but delete it consciously.

# [Feature name] — PRD

Owner: [PM name]          Status: Draft / In review / Approved / Shipped
Tech lead: [name]         Designer: [name]
Reviewers: [names, teams]
Links: [designs] [eng design doc] [analytics dashboard] [tickets]
Last updated: [YYYY-MM-DD]

## 1. Problem
[Who] is trying to [job to be done] but [obstacle].
This costs them [time / money / trust] and costs us [metric impact].

## 2. Evidence
- Data: [metric, baseline, source, date range]
- Research: [number of interviews, key quotes, link to notes]
- Support / sales: [ticket volume, top complaints]

## 3. Goals and success metrics
Primary metric: [metric] from [baseline] to [target] by [date]
Input metrics: [leading indicator 1], [leading indicator 2]
Guardrails (must not get worse): [metric], [metric]

## 4. Non-goals
- We will not [x] in this release because [reason]
- ...

## 5. Users and use cases
Primary segment: [who, how many, context]
Key scenarios:
1. [scenario]
2. [scenario]

## 6. Solution overview
[Two paragraphs in plain language. Link to designs.]

## 7. Requirements
| ID | Priority | User story | Acceptance criteria |
|----|----------|------------|---------------------|
| R1 | P0 | As a [user], I want [action] so that [outcome] | Given [context], when [action], then [result] |
| R2 | P1 | ... | ... |

## 8. Edge cases and failure states
- [What happens when ...]

## 9. Analytics
Events: [event name, properties, trigger]
Dashboard owner: [name]

## 10. Rollout
Phase 1: [% of users / city / cohort], feature flag [name]
Experiment: [control vs variant, sample size, duration]
Kill criteria: [roll back if ...]

## 11. Risks and dependencies
| Risk | Likelihood | Impact | Mitigation | Owner |

## 12. Open questions
| Question | Owner | Decide by | Decision |

## 13. Decision log
- [YYYY-MM-DD] [decision] — [who] — [why]

Worked PRD example: UPI payment at the doorstep

Here is a condensed PRD for a realistic Indian feature. The company is fictional (a grocery delivery app operating in Bengaluru and Pune) and the numbers are illustrative, but the shape is what a real reviewer would expect to see.

1. Problem

Cash-on-delivery customers often lack exact change, riders lose time at the door, and finance spends hours each week reconciling cash. Many of these customers already use UPI; they choose cash because they do not want to pay before they see the order.

2. Evidence

• Cash on delivery is 28% of orders; average doorstep handover for cash orders is 2 min 40 s versus 45 s for prepaid (illustrative internal data, last 90 days).
• "No change" appears in the top five rider complaints.
• In 12 customer interviews with cash-on-delivery users, 9 had paid a local shop by UPI in the past week; the most common reason they gave for choosing cash was "I want to see the items before paying".

3. Goals and success metrics

4. Non-goals

• We will not remove cash as an option in this release.
• We will not add card-on-delivery machines.
• We will not change the checkout flow for prepaid orders.

5. Users and use cases

Primary users are customers who select cash on delivery, and riders. Key scenarios: the customer pays the full amount by scanning a dynamic QR on the rider's phone; the customer pays partly in cash and partly by UPI; the payment is pending when the rider needs to leave.

6. Solution overview

At checkout, "Cash on delivery" becomes "Pay on delivery (UPI or cash)". At the door, the rider app shows a dynamic UPI QR with the exact order amount. The rider app and customer app both confirm payment in real time. If confirmation does not arrive within 60 seconds, the rider can mark the order as "payment pending" and leave; the customer gets a payment link.

7. Requirements

8. Edge cases

Duplicate payment (auto-refund the second one and show its status); rider phone offline (QR renders from a cached payload, confirmation syncs later); item missing at the door (rider edits the bill, QR regenerates).

9. Rollout and kill criteria

Feature flag at 10% of riders in one city for two weeks, then the whole city, then all cities. Roll back if completion rate drops more than 0.3 points or disputes rise for two consecutive weeks.

10. Open questions

Notice what this example does: the problem is about people, not a missing feature, every requirement is testable, the non-goals stop scope creep and each open question has an owner and a date.

One-pager vs full PRD: which do you need?

A good habit: start every idea as a one-pager. Promote it to a full PRD only when it is approved and the risk warrants it.

Common PRD mistakes

1. Solution first. "Build a referral programme" is not a problem. "New users from referrals retain better but only a small share of users ever share the app" is.
2. No baseline. "Increase conversion" means nothing without today's number and a target.
3. No non-goals. Scope then expands to fill the time available.
4. Untestable requirements. "The page should load fast" fails review; "the order summary renders in under 1.5 s on a mid-range Android phone on 4G" does not.
5. Happy path only. In India that often means ignoring low-end devices, patchy networks, regional languages and payment failures, which is where most real bugs live.
6. Writing it alone. A PRD that engineering sees for the first time in a review meeting will be torn apart, and fairly.
7. Treating it as finished or padding it. If the PRD and the build disagree, or a section changes nobody's decision, people stop reading.

Writing PRDs with AI tools

AI assistants are good at the parts of PRD writing that are tedious and bad at the parts that matter most.

Use them to:

• Turn rough notes or an interview synthesis into a first draft in your template.
• Generate edge cases and failure states you missed. Ask: "List 20 ways this flow can fail for a user on a low-end Android phone with an unstable connection."
• Rewrite vague requirements as Given/When/Then acceptance criteria.
• Act as a hostile reviewer: "You are the tech lead. What is unclear or risky in this PRD?"
• Summarise long comment threads into the decision log.

Do not use them to invent evidence (one made-up statistic destroys your credibility the moment someone checks it), to decide the trade-offs (that judgement is the job) or to pad the document. AI drafts are often twice as long as they need to be, so edit hard.

There is also a newer reason to write clear PRDs: more teams now hand specs directly to AI coding agents. An agent will build exactly what the acceptance criteria say. Precise requirements, explicit non-goals and listed edge cases are no longer just good manners for your engineers; they are the prompt. Many teams now keep PRDs as Markdown files in the repository, next to the code, for exactly this reason.

How to get better at writing PRDs

Ask senior PMs to show you one PRD they are proud of and one that went badly, and rewrite an old PRD of yours with the template above. A small, well-scoped PRD is also one of the fastest ways to earn trust in your first 90 days as a PM. And when you take apart a product in a product teardown, try writing the one-pager you think its team worked from.

Frequently asked questions

What is the difference between a PRD and an MRD?

A market requirements document (MRD) describes the market opportunity: segment, size of the need and competition. A PRD specifies what the product must do to address it. Most startups fold the useful parts of an MRD into the PRD's problem and evidence sections.

Who writes the PRD?

The product manager owns the PRD and is responsible for keeping it accurate. The best PRDs are written with the tech lead and designer, who contribute edge cases, constraints and design links. Ownership means accountability, not writing every line alone.

How long should a PRD be?

As short as it can be while still answering the problem, success metric, scope and requirements. A one-pager works for small or reversible changes; a full PRD for a cross-team launch is usually three to eight pages plus linked designs. If reviewers are skimming, it is too long.

What is the difference between a PRD and user stories?

User stories are one part of a PRD. The PRD adds the context stories lack: why the work matters, how success is measured, what is out of scope, and what the risks are. Stories without that context tend to be built correctly but for the wrong reasons.

Should I use AI to write my PRD?

Use AI to draft, restructure and stress-test a PRD, and to turn vague requirements into testable acceptance criteria. Do not let it supply evidence or make the trade-off decisions. Every number and claim in the final document should be one you can defend.

Learn from people who write PRDs every week

The fastest way to write better PRDs is to see how experienced PMs reason about trade-offs, then practise on real products. Product Circle, a community of 250+ product managers and founders in India, runs a weekly AMA with experienced PMs and founders and a product teardown every two weeks. If that sounds useful, here is how to join.

• PRD
• Product specs
• Templates