Glossary · Product and planning
What is a PRD?
A PRD, or product requirements document, describes what a product or feature must do and why, written before it is built. It states the problem, the users, the goals and how success is measured, then lists the requirements with priorities and acceptance criteria, and what is out of scope. It is the shared reference for what was agreed.
Also called: Product requirements document, PRD, requirements document
PRD (product requirements document), explained
A PRD exists so that the people building, selling and paying for something agree on what it is. It is not a design document and not a task list. It says what must be true when the work is done, and leaves how to the people doing it.
Most PRDs share a shape. A problem statement and the evidence for it. Who the users are and what they are trying to do. Goals, with the measures that will show success. The requirements themselves, each with a priority such as must, should or could, and acceptance criteria that say how you would know it works. Non-functional requirements, such as performance, security or accessibility. What is explicitly out of scope. And open questions with an owner.
The most common failure is vagueness. "Fast search" is not testable; "results in under 300 ms for the 95th percentile on a 10,000-record workspace" is. The second most common is a PRD that is written, approved and never read again, while the product drifts away from it. Giving each requirement a stable identifier, linking tasks to it, and freezing a baseline at sign-off keep the document useful after the meeting ends.
PRDs vary by team size. A startup's PRD might be one page; a regulated product's can run to dozens. Length matters less than whether every must-have requirement can be checked.
For example, a PRD for a client portal states the problem (clients email for status updates), the users (client project leads), the goal (cut status emails by half), and eight requirements such as "REQ-003: a client can see every milestone and its due date without signing in to the internal workspace", each with acceptance criteria.
How it works in Atrix
Atrix Develop mode writes a requirements document from a project's summary, pitch, target customer and documents, then an architecture document from it. Rewrites replace the text in place and keep the old version. Accepted requirements can be broken into backlog work linked back to each requirement, and frozen into a baseline for audit.
Read next
Related terms
- Requirements baselineA requirements baseline is a frozen, approved snapshot of a project's requirements at a point in time, usually when the team and stakeholders sign off on what will be built.
- Requirements audit (coverage and drift)A requirements audit compares the work actually done against the requirements that were agreed.
- Product roadmapA product roadmap is a plan that shows where the major pieces of work sit over the coming months or quarters, and the dates other people depend on.
- BacklogA backlog is the ordered list of work a team might do but has not yet committed to: features, fixes, improvements and ideas.