How to Write a PRD That Your Team Will Actually Ship From

Most PRDs get skimmed once and never opened again. The ones teams actually build from share a structure, and it is learnable. This is how to write a PRD that survives contact with engineering, design, and your own stakeholders.

TL;DR

• A PRD (product requirements document) answers four things: what are we building, for whom, why now, and how will we know it worked.
• The structure that ships: problem in the user's voice, who it is for, why now, success metrics, scope (in and out), risks, and open questions.
• Keep it decision-grade, not a novel. One page that ends the argument beats ten that start new ones.
• A template gets you 80% there. The last 20% is judgment: what to leave out, and what to flag as a real risk.
• Want the structure enforced for you? PRD-in-a-Pocket walks a rough idea into a shippable PRD in a few minutes.

A PRD only earns its keep if the team can build from it without a second meeting. Most cannot, because they read like a dump of requirements instead of a set of decisions. The fix is not more detail. It is the right structure, filled with judgment.

I have written, rewritten, and torn apart a lot of these over twelve years in product. The version below is the one that consistently ends the argument and lets engineering start. It is grounded in craft that is worth citing, not invented on the spot.

---

What is a PRD?

A PRD, or product requirements document, is a short shared document that answers what you are building, for whom, why now, and how you will measure success. Its job is to align the team on the problem and the bet before anyone writes code.

Just as important is what a PRD is not. It is not a technical spec that lists every field and endpoint, that is engineering's document. It is not a design file, and it is not a project plan. A PRD is the "why and what." The "how" belongs to the people who build it.

---

PRD vs BRD, and the docs people confuse it with

These get mixed up constantly, and the confusion causes the wrong person to write the wrong document. Here is the clean split.

Document	Answers	Owned by
PRD	What are we building for this product or feature, for whom, and why	Product
BRD	The business case and high-level business needs	Business / stakeholders
Tech spec / design doc	How it gets built	Engineering
One-pager / pitch	The sell, before the PRD exists	Product

If you only take one thing: a BRD is about the business, a PRD is about the product decision, and the spec is about the build. When in doubt, you are almost always writing a PRD.

---

How to write a PRD, step by step

Seven parts, in order. This structure borrows from the best-documented product craft: Lenny Rachitsky's widely shared PRD template, Marty Cagan's four product risks, Shreyas Doshi's writing on clarity, and Amazon's working-backwards PR/FAQ. You do not need all of them memorized. You need these seven fields, answered honestly.

1. Problem, in the user's voice. One paragraph. Not "users want a filter button," but the actual pain: what they are trying to do, where it breaks, and what it costs them. If you cannot state the problem without naming a solution, you do not understand it yet.

2. Who it is for. The specific user or segment. Narrow beats broad every time. "Readers arriving from a notification" is useful. "Our users" is not.

3. Why now. The trigger. A market shift, a new capability, or the mounting cost of doing nothing. This is the field most PRDs skip, and it is the one execs read first.

4. Success metrics. One primary metric that would move if this works, plus a guardrail or two so you do not win the metric and lose the product. State the number you expect, or say you do not know it yet.

5. Scope: in and out. What ships in v1, and explicitly what does not. The "out of scope" list is the single most powerful line in a PRD, it is where scope creep goes to die.

6. Risks. Use Cagan's four: value (will they use it), usability (can they figure it out), feasibility (can we build it in a reasonable time), and viability (does it work for the business, legal, and brand). Name the scariest one honestly.

7. Open questions. What you do not know yet. Listing your unknowns does not make you look unprepared, it makes the document trustworthy and tells the team where to dig.

That is the whole spine. Everything else, wireframes, edge cases, rollout plans, hangs off these seven.

---

A real PRD example

Structure is abstract until you see it filled in. Here is a compact, real-shaped example for a comment-thread redesign at a digital publisher.

Problem: Replies are hard to read and long threads hard to follow. Readers arriving from a notification do not land on the comment they came for, so they bounce.

Who: Readers of digital publishers and magazines following article comment threads.

Why now: Notification traffic is up 40% since launch, and it converts worse than any other source.

Success: Reply rate and thread read-depth up; bounce-from-notification down. Guardrail: no drop in page load.

In scope: Deep-link notifications to the exact reply with the thread collapsed around it.
Out of scope: New moderation tools, real-time chat, profile redesign.

Biggest risk: Value. If readers do not care about the specific reply, deep-linking does nothing.

Open question: Do we collapse the whole thread, or just siblings of the target comment?

Notice how short it is. Every line is a decision, not a description. That is the bar.

---

A copy-paste PRD template

Steal this. Paste it into your doc tool and fill each field in a sentence or two. If a field is empty, that is a signal you have thinking left to do, not a field to delete.

# PRD: [Feature name]

## Problem (in the user's voice)
[One paragraph. The pain, not the solution.]

## Who it is for
[The specific user or segment.]

## Why now
[The trigger: market, capability, or cost of inaction.]

## Success metrics
- Primary: [the one number that moves if this works]
- Guardrail: [what must not get worse]

## Scope
- In (v1): [what ships]
- Out: [what explicitly does not]

## Risks (value / usability / feasibility / viability)
[Name the scariest one and why.]

## Open questions
- [What you do not know yet]

---

Writing a PRD with AI

AI is genuinely good at the parts of a PRD that are structure and first draft: proposing the sections, drafting a problem statement from your rough notes, suggesting industry-specific examples, and catching the field you left blank. It is not good at the parts that are judgment: knowing your actual users, making the hard scope call, or deciding which risk is the one that kills you. Treat it as a fast co-author, not the author.

The workflow that works: hand the model your problem, your user, and a few rough notes, let it draft the seven-part structure, then spend your energy sharpening the parts only you can know. You go from blank page to a real draft in minutes, and put your time where it matters.

---

Common PRD mistakes

• Writing the "how" instead of the "what and why." The moment you are specifying components, you are in engineering's document.
• No "out of scope." Without it, every stakeholder quietly adds their pet feature.
• Vanity success metrics. If the metric can go up while the product gets worse, it is the wrong metric.
• A novel nobody reads. Length is not rigor. Cut until every line is a decision.
• False certainty. No open questions usually means you have not looked hard enough.

---

Make it a document your team ships from

The test for a finished PRD is simple: does it end the argument and let engineering and design start? If people are still debating what the problem is, the PRD is not done, no matter how long it is.

Get the seven fields right, keep it short, and be honest about what you do not know. If you want the structure handled for you, PRD-in-a-Pocket does it in a few minutes. And if your product needs more than a good document, senior direction without a full-time hire, that is fractional product leadership. Either way: write less, decide more.