What is a PRD, and how to write one people actually use
A product requirements document is where business and engineering meet. This guide covers the sections a useful PRD needs, what to leave out, and how to keep it short enough to be read.
PRD stands for product requirements document: it states what will be built, for whom, and why. It doesn't need to be long or formal. It has one job — to give everyone on the project the same picture of the product.
What a PRD is not
- Not a technical design. No tables, services or languages. Those belong in the architecture document.
- Not a wish list. "Nice to have" has no place in it.
- Not carved in stone. It changes as the team learns; the change just has to be written down.
The sections of a useful PRD
1. Problem
One or two paragraphs: what the problem is, who has it, and how it is handled today. If you can't describe the problem without mentioning the solution, you don't understand it yet.
2. User and context
Who is the main user, and in what situation do they reach for the product? One realistic persona is enough. "Everyone" is nobody's audience.
3. Goal and success metric
The goal must be measurable. "A better experience" is not a goal; "a customer can place an order without a phone call" is. More in success metrics that drive decisions.
4. Scope of the first version
Two lists side by side: what is in v1 and what is not. The second list matters more, because it stops the project from growing silently. See real MVP scope.
5. Scenarios
The main user journeys, step by step. Not every case — only the ones that carry the product's value.
6. Constraints and risks
Legal, technical, time and budget limits: anything that will sink the project if ignored.
7. Open questions
What you don't know yet. Writing these down is not weakness; it is what makes the document honest.
A simple template
| Section | The question it answers |
|---|---|
| Problem | What are we solving? |
| User | For whom? |
| Success metric | How will we know it worked? |
| Scope | What is in and out of v1? |
| Scenarios | What path does the user take? |
| Constraints | What limits us? |
| Open questions | What don't we know yet? |
Common mistakes
- Writing the solution instead of the need. "A green button at the top" is not a requirement. "The user can confirm an order in one step" is.
- Fifty pages. A document nobody reads doesn't exist. A good PRD can be read in one sitting.
- No "out of scope" section. Whatever isn't explicitly excluded will find its way in.
- Writing alone. A PRD comes from conversations with stakeholders, not one person's guesses.
What happens after the PRD
The PRD feeds the architecture stage. Once the "what" is clear, the "how" follows: system architecture, the data model and API contracts. In my process, the PRD is the output of stage two, and architecture doesn't start until it is approved.
If you have an idea that isn't a document yet, product discovery and definition does exactly that.