A product requirements document (PRD) says what a feature has to do, who it is for, and how you will know it worked. You write it before the work starts so design and engineering are solving the same problem. It covers the problem and the outcome, not how to build it.
What a PRD is for
A PRD exists to get the disagreement out early, while it is still cheap. Skip it and the disagreement still happens - it just happens in code review, or in a demo, or in front of the client. Its whole value is that several people read the same page and find out they had been assuming different things.
What to include
The exact template matters far less than covering these areas. A PRD that fits on two pages and covers them is more useful than a fifteen-page one that does not.
- Problem
- What is wrong today, for whom, and what evidence says so. If this section is thin the rest of the document is guesswork.
- Outcome
- What is true after this ships. Written as a change in the world, not as a list of features.
- Measures of success
- How you will know. A number and a timeframe, agreed before launch rather than chosen afterwards to suit the result.
- Users and use cases
- Who this is for and the specific situations they are in when they need it.
- Scope
- What is included. Just as importantly, what is explicitly excluded - see scope creep.
- Constraints and dependencies
- Technical, legal, commercial or timing limits, and anything this work waits on.
- Open questions
- What is still undecided. A PRD with no open questions early on is usually hiding them rather than lacking them.
PRD versus BRD versus technical specification
A business requirements document states what the business needs and why, in commercial terms. A PRD translates that into what the product must do. A technical specification describes how it will be built. They answer why, what and how respectively, and collapsing them into one document usually means the why gets lost first.
Why PRDs go stale, and what to do about it
A PRD is accurate at the moment it is signed off and starts drifting immediately, because the decisions that change it are made verbally - in a call, in a thread, in a corridor. The practical fix is versioning rather than discipline: keep the document revisable, tag a version at each agreed point so there is always something specific to cite, and generate downstream work from the tagged version rather than from memory of it.
Frequently asked questions
How long should a PRD be?
Long enough that a developer and a designer reading it independently would build the same thing. For most features that is one to three pages; the length is a symptom, not a target.
Who writes the PRD?
Usually the product manager, but the useful test is who is accountable for the outcome rather than who holds the title.
Do agile teams still write PRDs?
Many do, in a shorter form. What people object to is a 40-page document written up front that nobody is allowed to change. A short, versioned statement of the problem and the outcome works fine alongside iterative delivery.
How Spectr helps
Keep a requirements doc that is still true next month
Versioned BRDs and PRDs that stay current, and can generate a spec sheet directly
Related terms
Spend less of the week on documents
Spectr drafts the spec, the requirement document and the stories from your meetings. You review and approve.
Free plan available. 30-day free trial on Starter.