What Is a PRD? Product Requirements Document, Explained

A product requirements document (PRD) is a document that defines what you're building, who it's for, and why, before engineering starts. It lays out the problem, the users, the success metrics, the requirements, and what's explicitly out of scope, so a team can build the thing and a stakeholder can approve it without the author in the room.

That's the definition every guide gives, and it's right. It's also half the story. A PRD isn't finished when it's written. It's finished when it survives review, when someone trying to find the hole in it can't. Hold that thought. It's the part most definitions skip, and it's where the document either earns its keep or quietly fails.

What goes in a PRD

A PRD answers a fixed set of questions about the work. The exact section names vary by team, but the questions don't:

• The problem and who has it. What's broken, for which users, and how you know it's worth solving.
• Goals and success metrics. What changes if this ships, stated as numbers you could be wrong about.
• Users and their journey. Who this serves and the path they take through the product.
• Requirements. What the product must do (functional) and how well it has to do it (non-functional: performance, security, accessibility, error states).
• Scope. What's in this release, and the boundary of what's deliberately left out.
• Rollout and open questions. How it reaches users, how you'll measure it, and what you haven't resolved yet.

Length follows the work. A small feature fits on a page; a platform change runs longer. The trend across most teams is toward the leaner version, a one-pager that answers the same questions in less space rather than a thirty-page document nobody finishes reading.

What a PRD is for

A PRD has one real job: carry your thinking to people who weren't in the meetings. It's the single source of truth a cross-functional team aligns on, so engineering, design, and leadership are building toward the same target instead of four slightly different ones.

The version of this that goes wrong is the document written to look thorough rather than to be acted on. It reads well, everyone nods, and three weeks later the same questions resurface because the PRD never actually answered them. A good one ends the re-litigation. A bad one just postpones it to the worst possible moment, which is mid-build.

Who writes a PRD, and who reads it

The product manager usually owns the PRD. On a smaller team, a founder or a lead engineer writes it. The author pulls input from design, engineering, data, and whoever owns the parts the product touches, but one person holds the pen so the document has a coherent point of view.

The readers are the tell. An engineer reads it to estimate and build. A designer reads it to know the flows and states. A stakeholder reads it to decide yes or no on the spend. If any of them has to book a call to ask what you meant, the document hasn't done its job yet. The bar for "is this a real PRD" is exactly that: can the people who weren't there act on it without you?

PRD vs BRD vs MRD vs product spec

These overlap enough to get muddled, and plenty of teams use the words interchangeably. The honest distinctions:

| Document | Answers | Owner | |---|---|---| | BRD (business requirements) | What the business wants, and why, in business terms | Business / stakeholder | | MRD (market requirements) | What the market needs, and the opportunity | Product marketing | | PRD (product requirements) | What the product must do for users to meet that need | Product manager | | Product spec | Often a synonym for the PRD, sometimes the more technical slice | PM or eng lead |

In practice the lines blur, and modern teams increasingly collapse the BRD and PRD into one lean document rather than maintain three. Don't get precious about the acronym. Get precise about whether the document answers what it's supposed to.

The half the definition leaves out: the review

Here's the part the glossary entries skip.

Defining a PRD as "a document that captures requirements" makes it sound like the value is in the writing. It isn't. Any AI assistant can produce a complete-looking PRD from a one-line prompt now, and the bottleneck moved the moment that became true. The scarce skill isn't writing the spec. It's catching what the spec is missing before it costs a sprint.

That's the review, and almost nobody is taught to do it. We learn to write PRDs. We never learn to red-team one. So the first real review of a draft is usually someone else's, in a meeting, after the draft already feels done, which is the most expensive place to find a missing edge case. A PRD is "good" only relative to a review it can pass: no vague metric, no untestable requirement, no edge case left blank. The standing version of that review is the PRD review checklist, and the qualities that separate a draft that survives it from one that doesn't are in what makes a good PRD.

This is also why "review my PRD" is a different request than "write my PRD," and a harder one. A writing tool starts from a blank page and fills it. A review starts from your draft and attacks it, ranks what it finds by severity, and lands on a verdict. That's the job Thinkr's Critique is built for: eleven named passes that read the draft the way a senior reviewer would, before your team opens the doc.

So how do you write one?

If you're past the definition and want to actually write a PRD, the step-by-step version, with the review check built into each section, is how to write a PRD. If the blank page is the blocker, you can generate a structured first draft from your product context with PRD generation, then run the checklist on what it gives you. The common ways a PRD goes wrong, each tied to the check that catches it, are in common PRD mistakes.

Frequently asked questions

What does PRD stand for?

PRD stands for product requirements document. It's the spec a product manager writes to define what a product or feature should do, for whom, and why, before design and engineering start building. Some teams call it a product spec or a one-pager; the job is the same.

What goes in a PRD?

The problem and who has it, the goals and success metrics, the target users and their journey, the functional and non-functional requirements, what's in and out of scope, and a rollout plan. Lean teams compress this to a one-pager; the sections stay, the word count drops.

Who writes a PRD?

The product manager usually owns and writes it, with input from design, engineering, and stakeholders. On smaller teams a founder or lead engineer writes it. Whoever does, it has to be clear enough for everyone else to build and decide from without them in the room.

What is the difference between a PRD and a BRD?

A BRD states what the business wants and why, in business terms. A PRD translates that into what the product must do for users: features, flows, and requirements. The BRD sets the objective; the PRD defines the product that meets it. Plenty of teams now fold both into one lean document.

The shortest version

A PRD is how a decision gets made by people who weren't in the room where you made it. It's worth exactly as much as it holds up under their scrutiny, so write it to be attacked, not just to be read.