What is a product requirements document (PRD)?

A product requirements document (PRD) is a document that describes everything a product or feature must do, for whom and why. It usually avoids saying how the product will do it, so designers and engineers can choose the best solution. The PRD gives everyone on the project one shared reference for scope, priorities and what counts as done.

Who writes a PRD?

The PRD is usually owned by whoever is responsible for the product, often a product manager. It is written mostly from the user's point of view, with input from design, engineering, marketing, sales and support.

A PRD can also come from outside the build team. A client or a marketing department may write one and hand it over. When marketing writes it, it is sometimes called a marketing requirements document (MRD). The team that builds the product then expands it into a functional specification, sometimes called a technical requirements document, which describes how the requirements will be met.

What should a PRD contain?

A PRD starts with a short, high-level overview and then gets more detailed. Typical sections are:

• Title, author and status: who owns it, when it was last updated and whether it is a draft or approved
• Purpose and scope: the problem you are solving, the goal and what is out of scope
• Stakeholders: who needs to be involved or informed
• Market and users: the target audience, their needs and the business opportunity
• Product overview and use cases: what the product does and the main situations in which people use it
• Requirements: functional requirements, plus usability, technical, support and other requirements
• Assumptions, constraints and dependencies: what you are taking for granted, the limits you work within and what you rely on from other teams
• Workflow, timeline and milestones: the high-level user flow and the key dates
• Evaluation plan and metrics: how you will measure success, such as adoption, activation or retention

How do you write good requirements?

Requirements are the core of the PRD. A few practices make them clearer:

• Write them as user stories. A common format is: "As a [role], I can [capability], so that [benefit]." For example: "As a sales manager, I can see every open deal by stage, so that I can spot stalled deals in our weekly review."
• Add acceptance criteria that describe when a requirement is met, so testing has a clear target.
• Prioritise. The MoSCoW method sorts requirements into must have, should have, could have and won't have.
• Describe the problem, not the solution. "Users need to export reports for their finance team" leaves room for better solutions than "add a CSV button".
• Keep it short. Link to designs, research and technical notes rather than copying them in.

How does a PRD fit the product development stages?

Development projects vary in length and complexity, but most pass through four stages. The PRD should support each one.

Planning stage

The PRD is created here. It sets the timeline, the people involved and the scope. This is when the team agrees on the problem, the target users and the success metrics. A first release is often scoped as a minimum viable product.

Development stage

During development, the PRD is the reference for which features will be built, what value each one gives customers and in what order. Owners for each part of the work are named. When something changes, update the PRD so it stays the single source of truth.

Testing stage

The requirements and acceptance criteria in the PRD tell testers what to check. Plan the testing in advance: who tests, which scenarios, and what must pass before release.

Going live

When testing is complete, the product is released. The PRD helps sales, marketing and support understand what is launching, for whom and what customers can expect, so launch messages match what was built.

How do agile teams use a PRD?

In a waterfall process, all requirements are defined up front before development starts. In agile development, requirements start at a higher level so they can be prioritised, and the detail is added at the start of each cycle. Agile teams therefore tend to keep a shorter, living PRD that explains the goal, users and scope, and then manage the detailed requirements as user stories in their backlog.

A simple PRD template

You do not need special software to write a PRD. A shared document or wiki page works. Use this outline as a starting point:

1. Overview: product or feature name, owner, status, last updated
2. Problem: what problem we are solving, for whom and how we know
3. Goals and success metrics: what success looks like and how we measure it
4. Users and use cases: who uses it and in which situations
5. Requirements: user stories with acceptance criteria and MoSCoW priority
6. Out of scope: what this release will not include
7. Design and user flow: links to wireframes or prototypes
8. Assumptions, constraints and dependencies
9. Timeline and milestones: planning, development, testing, launch
10. Open questions: decisions still to be made, with an owner for each

Keep the PRD up to date as decisions change. An outdated PRD causes more confusion than no PRD at all. For tools to manage the work, browse our project management tools.