How to Write PRDs for Product Managers
Writing Good Requirements
The Properties of a Well-Written Requirement
There is a meaningful difference between a requirement that exists and a requirement that works. A requirement that exists gives the team something to point to. A requirement that works gives the team something to build from.
A well-written requirement has five properties.
It is clear. One reader should not be able to interpret it differently from another. Ambiguous language, words like appropriate, reasonable, user-friendly, fast, and easy, invites each person on the team to fill the gap with their own assumption. Replace vague descriptors with specific ones. Not the page should load quickly but the page must load within two seconds.
It is specific. It names the exact behaviour, the exact user, and the exact condition under which the behaviour must occur. Generalised requirements produce generalised features. Users must be able to filter results weaker than users must be able to filter search results by date range, category, and status simultaneously.
It is testable. If you cannot write a test that determines whether the requirement was met, the requirement is not yet specific enough. Every requirement should have a clear pass or fail condition. This property is what connects requirements to acceptance criteria.
It is independent. Each requirement should stand on its own without depending on the reader having read another requirement first. Requirements that rely on implicit context from other sections cause confusion when they are referenced in isolation, which happens constantly during development.
It is realistic. A requirement that cannot be met given the team's technology, timeline, and resources is not a requirement. It is a wish. Unrealistic requirements are not just useless: they erode trust in the PRD as a whole.
Common Writing Mistakes to Avoid
Bundling multiple requirements into one. Each requirement should describe one behaviour. The system must allow users to create, edit, and delete their profile contains three requirements. Write them separately so each can be independently tracked, tested, and prioritised.
Writing from the system's perspective without the user's context. The system shall display a modal tells engineering what to build but not why, not for whom, and not under what conditions. Ground requirements in the user context that makes them necessary.
Using passive voice that obscures ownership. Data must be validated leaves open who validates it, when, and under what conditions. The system must validate the email address format before allowing form submission is precise.
Writing requirements as solutions. The system must use a dropdown menu for category selection is a design decision masquerading as a requirement. The requirement is users must be able to select one or more categories before submitting the form. How that selection is implemented is for the designer and engineer to determine.
Remember this: A requirement is not finished when it is written. It is finished when someone else reads it and understands exactly what the product must do, for whom, under what conditions, without needing to ask a single clarifying question.