Product requirements document
pee-are-DEE
A document that defines what a product or feature should do, who it serves, and how success will be measured.
A PRD defines what you are building and why. It covers the problem, the target user, the requirements, success metrics, and constraints. It does not specify how to build it. That is the engineering team's job.
Good PRDs are concise. A one-pager that clearly defines the problem and success criteria is better than a 20-page document that specifies every UI element. The PRD sets the destination; the team figures out the route. User stories within the PRD describe the specific behaviors.
The PRD is a communication tool, not a contract. It aligns product, engineering, and design on what needs to be true when the feature ships. It feeds directly into the roadmap. If the team discovers a better approach during development, the PRD should evolve.
Examples
A PM writes a PRD for a new feature.
The PRD has five sections: Problem (users spend 20 minutes configuring alerts), Goal (reduce alert setup to under 2 minutes), User stories (3 scenarios), Success metrics (setup completion rate, time to first alert), and Non-goals (we are not rebuilding the alert engine).
An engineering lead reviews a PRD.
The engineer reads the requirements and identifies a technical constraint the PM was not aware of. They discuss it. The PRD is updated to reflect the constraint. This is the PRD working as intended: a living document that improves through collaboration.
A PRD prevents scope creep.
During development, a designer suggests adding three more features. The PM points to the PRD's 'Non-goals' section, which explicitly lists those features as out of scope for this iteration. The team stays focused.
In practice
Read more on the blog
Frequently asked questions
Who writes the PRD?
The product manager, with input from engineering, design, and stakeholders. The PM owns the document, but the best PRDs are collaborative: engineering reviews for feasibility, design reviews for user experience, and stakeholders review for business alignment.
Is a PRD the same as a spec?
A PRD defines what and why. A spec (technical specification) defines how. The PRD comes first and informs the spec. Some teams combine them; most keep them separate because they serve different audiences.
Related terms
A strategic plan that outlines upcoming product features, priorities, and timelines to align the team and communicate direction.
A short, plain-language description of a feature from the perspective of the user who wants it.
A large body of work that can be broken into smaller user stories, representing a significant feature or initiative.
A meeting where the team selects which work to complete in the upcoming sprint and plans how to accomplish it.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.