Requirements travel badly. What a stakeholder says, what a product manager hears, and what an engineer builds can be three different features unless someone writes the intended one down. The PRD exists so that everyone argues about the same document instead of three different memories.
In this glossary topic:
What is a product requirements document?
A product requirements document (PRD) is the written definition of what a product or feature must do: the problem it solves, who it serves, what is in and out of scope, and how success will be measured. It is authored by the product manager and read by everyone else, which is exactly the point.
A PRD describes the what and the why. It deliberately avoids prescribing the how, leaving design decisions to designers and technical decisions to engineers.
What does a PRD include?
The durable core is 6 parts: the problem statement, goals and success metrics, the target user, requirements grouped by priority, what is explicitly out of scope, and open questions. Length varies by team and by risk. The out-of-scope section earns its place more often than any other, because most scope creep enters through what a document failed to exclude.
How does a PRD differ from a product spec?
The PRD defines the problem and the requirements; a product spec defines the solution in enough detail to build it. They also serve different audiences: a PRD aligns stakeholders and leadership on intent, while specs guide the people implementing the work. Small teams often merge the two into one document, which works until the audiences diverge and stakeholders stop reading 12 pages of implementation detail to find the 3 that concern them.
Why do PRDs matter for development teams?
When requirements live in meetings and message threads, teams build features that miss expectations and only discover it at review time. A PRD makes the intended outcome inspectable before the expensive part starts. It also creates accountability in both directions: engineers can push back on requirements that conflict, and product managers can point to agreed scope when new requests arrive mid-build.
What does a PRD look like in practice?
A team planning a notifications feature writes one page: the problem (users miss time-sensitive updates), the goal (raise day-7 return rate), 5 prioritized requirements, and 2 lines of out-of-scope (no email digests, no per-channel settings in version 1). Design starts from the problem statement, engineering flags a conflict between 2 requirements the same day, and the debate happens before a line of code exists. The document took an hour to write and saved a sprint of rework. The Product Specs vs PRDs lesson walks through how the two documents split the work between audiences.
