Product Requirements Document

What a product requirements document is

A product requirements document (PRD) is the shared source of truth that describes what a product, release, or major area should do and why it is worth building. It captures the problem being solved, the people it is for, the goals and how success will be measured, the requirements that make up the solution, what is in and out of scope, and the conditions that have to be met before it can ship. Its job is to get everyone — product, design, engineering, and the stakeholders who fund the work — pointed at the same outcome before a line of code is written.

A PRD is broader than a single feature. Where a feature specification scopes one capability end to end, a PRD sits above several features and ties them to a business goal, a set of users, and a release. It is the planning artefact a product manager uses to align the team on the what and the why, leaving the detailed how of each feature to the specs and the technical design that follow.

PRD versus spec versus roadmap

These three documents are often confused because they all describe future product work, but they answer different questions and live at different altitudes.

• A roadmap answers when and in what order. It is a high-level, time-ordered view of the themes and initiatives a team plans to pursue. It deliberately stays light on detail; it sets direction and sequence, not requirements.
• A PRD answers what and why for one of those initiatives. It takes a single roadmap item and defines the problem, the users, the goals, the requirements, the scope, and the release criteria in enough depth that the team can plan and build it.
• A feature specification answers exactly how a single feature behaves. It zooms into one capability named by the PRD and pins down its precise behaviour, acceptance criteria, and edge cases.

A useful mental model: the roadmap promises an outcome, the PRD defines that outcome, and the feature specs realise it one feature at a time. On a small team a PRD and a spec sometimes merge; as scope grows it pays to keep the product-level intent in the PRD and the per-feature detail in its own spec.

What a PRD contains

A complete PRD covers a predictable set of parts, each carrying a distinct piece of the decision:

• Problem and goals. The user or business problem the product addresses, stated plainly, paired with the goals that define success. If a reader cannot see the problem, they cannot judge whether the solution fits.
• Target users and personas. Who the product is for, described as concrete personas with their context, jobs, and frustrations. Naming the user keeps every later decision anchored to a real person.
• Requirements and user stories. What the product must do, often expressed as role-framed user stories ("As a [role], I want [capability] so that [benefit]") backed by numbered functional requirements that can be referenced and traced.
• Success metrics. The measurable signals that will tell you the product worked — adoption, retention, conversion, time saved, error rate. Without metrics, "success" is an opinion.
• Scope and non-goals. What is included in this release, and an explicit list of what is deliberately left out. Non-goals prevent scope creep and settle the "but shouldn't it also..." debate up front.
• Dependencies and risks. The other teams, systems, data, or decisions this work relies on, and the things that could derail it, with how you plan to handle each.
• Release criteria. The conditions that must be true before the product can ship — quality bars, must-have requirements, and the metrics or sign-offs that gate the launch.

Open questions, UX considerations, and a rollout plan are common additions, but the seven parts above are the load-bearing core.

Writing good requirements

Requirements are where a PRD earns or loses the team's trust. The single most useful discipline is to write each requirement so that it is testable: a reader can imagine, unambiguously, how to confirm it has been met. "The dashboard should be fast" is not testable; "the dashboard renders the default view within two seconds for a typical account" is.

Strong requirements share a few traits. They are outcome-led — they describe what the user can do and why it matters, not which library to use. They are specific — they name real states, values, and behaviours rather than "works correctly." They are prioritised — must-haves are separated from nice-to-haves (a simple "must / should / could" labelling is enough) so that the team knows what cannot slip. And they are traceable — numbered or otherwise referenceable, so a requirement can be tied to a user story above it and to a test or feature spec below it. Pair the requirements with user stories to keep them anchored to user value, and pair them with success metrics so the team can tell whether meeting them actually moved the needle.

Common mistakes

Several recurring problems weaken PRDs:

• No measurable success metrics. A PRD that lists features but never says how it will know they worked cannot tell success from activity, and the team ships without learning anything.
• Missing non-goals. Without an explicit out-of-scope list, every reader quietly assumes a slightly larger product, and scope balloons during the build.
• Solution before problem. Jumping to a feature list before stating the problem leaves no way to judge whether those features are the right answer — or whether they are needed at all.
• No named user. A PRD written for "users" in the abstract produces a product that fits no one in particular. Concrete personas keep decisions honest.
• Drifting into design or implementation. A PRD describes what the product must do and why; pinning down exact screens or technologies too early limits the designers and engineers who know best and dates the document quickly.
• Treating it as write-once. Reality moves: questions get answered, constraints appear, priorities shift. A PRD that is never updated stops matching the product and stops being trusted as the source of truth.