How to Write a Product Requirements Document (PRD), With a Full Example

A product requirements document (PRD) describes what a product or feature should do, who it is for, why it is worth building and how the team will know it worked. It is written by the product manager, read by design, engineering, QA and stakeholders, and it deliberately leaves the “how” (the design and the technical approach) to the people who will build it.

This guide covers what goes into a PRD, how it differs from an MRD, a BRD and a technical spec, how to write one step by step, and a complete example PRD you can copy the structure from. It also covers the mistakes that make a PRD useless, such as requirements nobody can test and goals with no number attached.

What Is a Product Requirements Document (PRD)?

A PRD is the single place where a team agrees on the problem and the expected outcome before work starts. A good one answers five questions:

1. What problem are we solving? Stated from the user’s side, with evidence (support tickets, research, usage data).
2. Who has the problem? The target users or personas, and who is explicitly not the target.
3. Why now? The business reason: revenue, retention, a contract, a regulation, a competitor.
4. What must the product do? The requirements, each one prioritised and testable.
5. How will we know it worked? Success metrics with a baseline and a target.

Everything else (designs, architecture, tickets) is linked from the PRD rather than written inside it. That keeps the document short enough that people actually read it.

Who writes a PRD and who uses it

PRD vs MRD vs BRD vs Technical Spec

These documents are often confused because they all contain “requirements”. The difference is the question each one answers:

In practice the MRD comes first and justifies the investment; the PRD turns that opportunity into a specific product scope. If you need the earlier document, see how to write a market requirements document. Smaller teams often merge the MRD and PRD into one document, which is fine as long as the market evidence and the product requirements are in separate sections.

Do Agile Teams Still Need a PRD?

Yes, but not the 40-page version. Long, up-front PRDs fell out of favour because teams wrote them once, handed them over and never opened them again, while the product changed in every sprint. Product leaders such as Marty Cagan have long argued that prototypes and discovery should carry much of what a written spec used to.

What survives in agile teams is a shorter, living PRD:

• It fits in a few pages (often a one-pager for a single feature).
• It states the problem and the outcome firmly but keeps the solution open.
• It links to designs, prototypes and the epic in Jira, Linear or a similar tool instead of copying them.
• It changes as the team learns, with a change log so people can see what moved and why.

Keeping documentation in step with sprints is a skill of its own; maintaining documentation in an agile team covers the habits that help.

What to Include in a PRD

These are the sections most PRD templates share. Keep the order; reviewers learn where to look.

Prioritising requirements

Give every requirement a priority so the team knows what to drop if time runs short. MoSCoW (must have, should have, could have, won’t have this time) is the simplest scheme and maps neatly onto a release: the “must” items define the minimum release, and the “won’t” items become your non-goals. Scoring methods such as RICE (reach, impact, confidence, effort) help when you are choosing between many candidate features rather than ordering one feature’s requirements.

Writing requirements people can test

The fastest way to improve a PRD is to rewrite each requirement until someone in QA could write a test for it.

For acceptance criteria, the Given/When/Then format keeps each condition concrete: Given a starting state, when the user does something, then a specific result follows. It also translates directly into automated tests.

How to Write a PRD, Step by Step

1. Start with the problem and its evidence. Collect support tickets, interview notes, analytics and sales feedback. Write a short problem statement before you think about features.
2. Set measurable goals. Pick one primary metric and a few guardrail metrics (things that must not get worse). Record today’s baseline so the target means something.
3. Write the non-goals. Listing what you won’t build is the cheapest scope control there is.
4. Describe users and user stories. Use the form “As a [user], I want [action] so that [outcome]”, and keep the stories about needs, not screens.
5. List functional and non-functional requirements. Give each an ID (R1, R2…) and a priority. IDs let designs, tickets and test cases refer back to the PRD.
6. Add acceptance criteria. At least one per “must” requirement, ideally in Given/When/Then form.
7. Record assumptions, constraints, dependencies and open questions. An open question with an owner and a due date is far better than a silent guess.
8. Review with engineering and design early. Share a draft before it feels finished. Engineers spot infeasible requirements and missing edge cases; designers spot stories that don’t match real behaviour.
9. Get sign-off, then keep it alive. Mark the status as approved, link the epic, and log every later change with a date and a reason.

Writing a PRD is technical writing: the same rules about audience, structure and plain language apply. If you are new to that discipline, what technical writing is is a good primer, and version control for documentation shows how to keep a reviewable history of changes.

Product Requirements Document Example

Below is a complete, short PRD for a single feature on a fictional job board called “JobNest”. The product and numbers are made up for illustration, but every section is one you would use in a real PRD.

Header

1. Problem statement

Job seekers repeat the same searches every few days to check for new listings. In the last quarter, 38% of returning candidates ran an identical search more than three times, and “notify me about new jobs” was the most requested feature in support tickets. Candidates who miss new listings apply later, when roles have more applicants, which hurts their chances and our employers’ time-to-hire.

2. Goals and success metrics

3. Non-goals

• Push notifications in the mobile app (planned for a later release).
• Recommended jobs based on a candidate’s profile.
• Alerts for signed-out users.

4. Users and user stories

• As an active job seeker, I want to save a search so that I don’t have to rebuild my filters every time.
• As an active job seeker, I want an email when new matching jobs are posted so that I can apply early.
• As a passive candidate, I want a weekly summary instead of daily emails so that alerts don’t fill my inbox.

5. Functional requirements

6. Non-functional requirements

• Performance: saving a search completes in under 500 ms at the 95th percentile.
• Delivery: daily alerts are sent between 7:00 and 9:00 in the user’s time zone.
• Accessibility: the save and manage flows meet WCAG 2.2 AA.
• Privacy: alert emails include only job data, no personal data beyond the user’s first name.

7. Acceptance criteria (examples)

• R1: Given a signed-in user on a results page, when they click “Save search”, then the search appears in “My saved searches” with the same filters.
• R2: Given a user with 10 saved searches, when they try to save another, then they see a message asking them to delete one first, and nothing is saved.
• R6: Given a daily saved search with no jobs posted since the last alert, when the daily run happens, then no email is sent to that user for that search.

8. Assumptions, constraints and dependencies

• Assumption: most candidates prefer email to push notifications (to be checked in the beta).
• Constraint: the email provider’s sending limit is 500,000 messages a day.
• Dependency: the search team must expose a “posted since” filter in the search API.

9. Release plan

• Beta to 5% of signed-in candidates behind a feature flag for two weeks.
• Check guardrail metrics, then 50%, then 100%.
• Roll back by switching off the flag; saved searches are kept.

10. Open questions

• Should alerts include salary when the employer hasn’t published one? Owner: PM, due before design review.
• Do we need a separate consent step in the EU? Owner: legal, due before beta.

Notice how short each section is. The example is complete enough to design, build and test against, yet it never says which database to use or what the button looks like; those belong in the tech spec and the design file.

Common PRD Mistakes

• Writing the solution as the problem. “We need a saved-search button” hides the real problem (candidates miss new jobs), which might have a better solution.
• Goals with no numbers. If you can’t measure it, you can’t tell whether the release worked or should be rolled back.
• No non-goals. Every unlisted idea becomes a scope debate in the middle of a sprint.
• Too much “how”. Specifying UI layouts or database tables takes decisions away from the people best placed to make them.
• Untestable requirements. Words like “fast”, “easy”, “intuitive” and “secure” need a number or a standard next to them.
• A document nobody owns. A PRD without an owner and a change log is out of date within weeks.
• Skipping engineering review. Requirements that are cheap to write can be very expensive to build.

Using AI to Draft a PRD

AI assistants are good at turning rough notes into a first draft with the right sections, rewriting vague requirements into testable ones and suggesting edge cases you missed. They can’t supply your evidence. Baselines, research findings and constraints must come from your own data, and every requirement still needs a human owner to confirm it. Treat the AI draft as a starting point for the review step, not a replacement for it.

Conclusion

A product requirements document is the team’s agreement on what to build and why: the problem, the users, measurable goals, prioritised and testable requirements, and what is out of scope. Keep it short, leave the “how” to design and engineering, give every requirement an ID, a priority and acceptance criteria, and keep it alive with a status and a change log. Use the example above as a pattern, and if you are earlier in the process, start with the market requirements document.

FAQs