A PRD is a product requirements document: a written description of what a product or feature has to do, who it is for, and how you will know it worked. Product managers usually write it, and design, engineering and QA build against it. In software, "PRD" almost always means this. This guide covers what goes in one, how it differs from the other requirements documents you will hear about, and a short example you can read in two minutes.
If you want to write one rather than understand one, skip to the free PRD templates. This post is the explanation that sits behind them.
What does PRD mean?
PRD stands for product requirements document. The word that does the work is "requirements": a PRD lists what the product must do, not how it will be built. The how belongs to engineering and design, who read the PRD and decide.
In other fields the same three letters stand for unrelated things, which is why searching for the meaning turns up results about real estate, healthcare and the Navy. Everything below is about software and product development.
What is a PRD used for?
A PRD does three jobs.
It aligns people before anyone builds. Product, design, engineering and stakeholders read the same page and argue about it while changing it is still cheap. A disagreement found in a PRD costs a conversation. The same disagreement found in a pull request costs a rewrite.
It defines "done." A good PRD says what the release delivers, what it deliberately leaves out, and what result would count as success. Without that, "done" is decided late and by whoever is most persistent.
It is the reference when something changes. When a stakeholder asks for a new feature mid-build, the PRD is how you answer "is that in scope, and what are we trading it for?"
There is a fourth job that is newer. When an AI coding agent builds from your description, the PRD is the context it works from. A vague PRD used to cost a five-minute conversation. Now it costs a confidently wrong implementation, because the agent fills each gap with a plausible guess and does not ask. That is the main reason PRDs have come back into fashion among people who build with AI tools.
What goes in a PRD?
There is no single standard, and the right amount depends on the team. The sections that earn their place in most PRDs are these.
| Section | What it answers |
|---|---|
| Context and problem | Who has the problem, what do they do today, and why is that not good enough? |
| Goals and non-goals | What will this release achieve, and what is explicitly out of scope? |
| Target users | Who is this for? Usually two or three named personas. |
| User stories | What does each user need to do? Written as "As a [user], I want [capability], so that [benefit]." |
| Acceptance criteria | For each story, what observable result means it works? |
| Non-functional requirements | Performance, security, accessibility, compliance, scale. |
| Success metrics | Which numbers will show the release worked, and by when? |
| Dependencies and open questions | What does this rely on, and what is still undecided? |
Two things are worth noticing. The sections are mostly about the user and the outcome, not the solution. And the list is short. A PRD with 20 sections is usually a sign that nobody decided which ones mattered.
PRD vs BRD, MRD, SRS and spec
The requirements documents get confused because they overlap and teams use the names loosely. The usual distinctions are these.
| Document | Stands for | Focus | Typical author |
|---|---|---|---|
| PRD | Product requirements document | What the product or feature must do for users | Product manager |
| BRD | Business requirements document | The business goal, stakeholders, cost and expected return | Business analyst or sponsor |
| MRD | Market requirements document | The market opportunity and customer needs behind a product | Product marketing or product management |
| SRS | Software requirements specification | Detailed, testable technical requirements for the whole system | Business analyst or systems engineer |
| Design spec | Software design specification | How the system will be built to meet the requirements | Engineering |
In short: the MRD and BRD say why the business should do this, the PRD says what to build, the SRS pins the what down in detail, and the design spec says how. Many teams skip some of these. A startup often has one document called a PRD that covers a little of each, and that is fine as long as the reasons, the requirements and the success measure are all written down somewhere.
Who writes a PRD, and how long should it be?
A product manager usually owns it. In a startup that is often the founder or a technical founder wearing the product hat. Writing it is collaborative: engineering checks that it is buildable, design checks that it is usable, and stakeholders check that it matches the business goal.
Length follows the size of the decision. A one-page PRD is enough for a small feature or a solo project. A new product with a team behind it may run four to ten pages. Past that, the document is usually carrying material that belongs elsewhere, such as the data model, the page inventory or the test plan, and it is better to split those out so each can change without republishing the whole thing.
Is a PRD still used in agile?
Yes, but it looks different. Waterfall PRDs were long, fixed and written once. Agile teams write shorter ones, revise them as they learn, and often keep the detail in user stories and acceptance criteria in their backlog tool, with the PRD acting as the framing document above them. The idea that survived is the useful one: agree what you are building and how you will know it works before you build it. What died is the 80-page document nobody read.
A short PRD example
Here is the shape of a lean PRD for one feature. It is deliberately small. For three full templates and a longer filled-in example, see the PRD template guide.
# PRD: Client share links
## Problem
Freelance designers collect client feedback across email, Slack and
Figma comments, and lose hours reconciling it. Clients will not create
an account just to leave a comment.
## Goals
- A client can read a project's feedback board and comment through a
link, with no signup.
- Designers see all comments in one place.
## Non-goals
- Client accounts, real-time chat, file uploads from clients.
## Target user
Maya, a freelance brand designer with six active clients who lives in
Figma and Gmail.
## User story
As Maya, I want to send a client a link to a project's feedback board,
so that they can comment without creating an account.
## Acceptance criteria
- Given a project with open comments, when Maya clicks "Copy share link",
then a link valid for 30 days is copied to her clipboard.
- Given a share link older than 30 days, when a client opens it, then
they see "This link has expired" and a "Request a new link" button.
## Success metric
60% of designers send at least one share link in their first week.
## Open questions
- Can Maya revoke a link before it expires?
Read it again with the sections in mind. The problem and the non-goals stop scope creep. The single story and its criteria are specific enough that someone could build and test them. The success metric says what "worked" means, with a number and a time frame. The open question is honest about what is not decided, which is more useful than a PRD that pretends everything is settled.
How to write a better PRD
A few habits separate PRDs people use from PRDs people file.
Write the problem before the solution. If the first thing a reader sees is a feature list, they will debate features. If it is a problem, they will debate whether you have the right one, which is the better argument.
State the non-goals. What you will not build in this release is as much part of the contract as what you will. It is the cheapest way to prevent scope creep.
Make criteria checkable. "Handle expired links gracefully" cannot be tested. "An expired link shows a message and a button to request a new one" can. Acceptance criteria examples shows the difference across eight common features.
Put a number on success. "Improve engagement" is not a metric. "15% more weekly active users within 60 days of launch" is.
Keep it alive. When you learn something that changes the plan, change the PRD. A PRD that disagrees with what was built is worse than none, because people trust it.
If you build with AI tools, one more: write the stories and criteria so a model could not misread them. Spec-driven development covers that approach end to end. VibeMap, which I build, generates a PRD as part of a linked spec (personas, features, user stories, acceptance criteria) and lets you download it as markdown on any plan, so it can double as the written brief for a coding agent.
FAQ
What does PRD stand for?
PRD stands for product requirements document. In software and product management it is the document that describes what a product or feature must do, who it is for and how success will be measured. The same letters mean unrelated things in other fields.
What are the key elements of a PRD?
Most PRDs include the problem and context, goals and non-goals, target users, user stories, acceptance criteria, non-functional requirements, success metrics, and open questions or dependencies. Short PRDs keep to the first four or five. Longer ones add the rest.
What is the difference between a PRD and a BRD?
A BRD (business requirements document) explains why the business should invest: the goals, stakeholders, costs and expected return. A PRD says what to build for users to meet those goals. A BRD is usually written first, by a business analyst or sponsor, and a PRD by a product manager.
Who writes a PRD?
Usually a product manager. In small companies it is often a founder. Engineering, design and stakeholders review and contribute, so it works best as a shared document rather than one person's handover.
How long should a PRD be?
As long as the decision needs. One page suits a small feature or solo project. A new product with a team behind it may take four to ten pages. If it grows much longer, split the data model, page inventory and test plan into their own documents.
Do agile teams use PRDs?
Yes, in a lighter form. Agile teams keep a short PRD as the framing document and put the detail into user stories and acceptance criteria in their backlog. They revise it as they learn instead of freezing it.
Related reading
- PRD template: three free copy-paste templates and a full example, for when you are ready to write one.
- How to write user stories with INVEST, for the stories section.
- Acceptance criteria examples, for the "how will we know it works" section.
- Business case template, for deciding whether the idea deserves a PRD at all.
- Spec-driven development, for turning a PRD into something an AI coding agent can build from.
Sources and further reading
- Marty Cagan, Inspired: How to Create Tech Products Customers Love (Wiley, 2nd edition, 2017): the argument for lighter product documentation and discovery before delivery.
- Mike Cohn, User Stories Applied: the story format used in the PRD's stories section.
- Cucumber, Gherkin Reference: Given/When/Then syntax for acceptance criteria.
- ISO/IEC/IEEE, 29148:2018 Systems and software engineering: Requirements engineering: the formal standard behind the SRS-style documents.
