Product Requirements Document

A Product Requirements Document (PRD) specifies what a feature or product should do and why, before anyone starts building it. It's the shared reference that product, design, and engineering align on before committing effort — narrower in scope than a Functional Specification (which covers broader technical scope, including how the system is built) and made up of individual User Story items describing specific user-facing requirements.

Key components

• The problem and who has it — a clear statement of what's broken or missing today, and for which specific user or segment, before any proposed solution appears. Without this, readers can't later judge whether the shipped solution actually solved anything.
• Success metrics, defined before building — the specific numbers that will indicate the feature worked, written down before development starts (see below for why order matters here).
• Scope: in and out — an explicit list of what this effort covers and, just as explicitly, what it does not — the second list is easy to skip and is where scope creep usually starts.
• Requirements — typically expressed as a set of User Story entries, each with its own acceptance criteria, rather than one long prose requirements list.
• Open questions and assumptions — anything still unresolved or assumed true, stated openly rather than quietly baked into the design as if it were settled fact.
• Non-functional requirements — performance, accessibility, privacy, and localization expectations, when relevant, so they don't surface as surprises during implementation or review.

Why success metrics come before building, not after

Defining success metrics after launch invites picking whichever number happened to look good — engagement went up, so call it a win; retention didn't move, so don't mention retention. Metrics chosen in advance, while nobody yet knows the outcome, force an honest commitment to what "success" actually means, and make the post-launch review a real evaluation instead of a retroactive victory lap.

Common pitfalls

• Metrics decided after launch — "success" gets redefined to match whatever happened to move, which makes the entire evaluation unfalsifiable and worthless as a decision input for next time.
• No explicit out-of-scope list — without one, scope creep isn't a violation of anything written down, since nothing was ever actually excluded in writing.
• Solution spec with no stated problem — a PRD that jumps straight to "build X" without saying what problem X solves leaves nobody able to later judge whether X actually helped.
• Assumptions treated as settled facts — an assumption not flagged as an assumption gets built on top of without anyone checking it, and the whole plan can be resting on something nobody verified.
• One giant requirement instead of discrete stories — a PRD written as one large paragraph of requirements is hard to estimate, build incrementally, or verify against; breaking it into User Story entries with their own acceptance criteria fixes this.

Learn more

• User Story for how individual requirements inside a PRD get written from the user's perspective, with their own acceptance criteria.
• Functional Specification for the broader technical scope document a PRD's requirements often feed into.
• Product Roadmap for how a PRD's feature fits into the larger, ongoing plan across the whole product.
• Feature Prioritization for deciding which candidate PRDs actually get built first.