What Is a PRD (Product Requirements Document)?

A product requirements document describes what a product or feature should do, for whom, and why — at a level of precision that lets engineering build it without inventing the missing parts. It is not a design document, not a project plan, and not a wish list.

What belongs in one

• The problem, stated in terms of the user, not the solution. If this section describes a feature, it is the wrong section.
• Who has it, specifically enough to exclude people.
• Success criteria — what changes if this works, expressed so that it could turn out false.
• Scope, and explicitly what is out of scope. The second half is where most of the value is.
• Requirements — the behaviours, including the unhappy paths.
• Constraints — regulatory, technical, timing.
• Open questions, with owners. A PRD with none is hiding them, not lacking them.

What does not belong

• Implementation choices. "Use Redis" is an architecture decision, and it belongs in an ADR where its reasoning survives.
• Visual design, beyond what constrains behaviour.
• Estimates. Those come after, from the people doing the work.
• Prose written to persuade a stakeholder. That is a different document with a different audience.

Precision, not length

A good PRD is short and unambiguous. The test is whether two competent engineers reading it independently would build materially the same thing. Length is not a proxy for that — long documents hide ambiguity in volume, and the sections nobody reads are exactly where the assumptions sit.

## Requirement: refund an order

Given an order in state DELIVERED or SHIPPED
When an agent requests a refund with an amount <= order total
Then the refund is issued to the original payment method
And the order moves to REFUNDED
And the customer receives a confirmation email

Not in scope: partial refunds by line item; refunds after 90 days;
refunds to a different payment method.

Why this got more important, not less

When implementation is fast and cheap, output quality is bounded by specification quality. A vague requirement no longer produces a clarifying conversation — it produces a plausible, confidently wrong implementation that then has to be reviewed, understood and unpicked. The ambiguity that used to surface as a question now surfaces as rework.