Product Requirements Documents: Turning Business Needs into Buildable Software
How to write a product requirements document: problem, users, outcomes, scope and non-goals, journeys, functional and non-functional requirements.
What should a product requirements document contain?
A good PRD states the problem and who has it, the outcomes and how you will measure them, what is in and out of scope, the key user journeys, functional requirements with acceptance criteria, non-functional requirements (performance, security, accessibility, data), dependencies and integrations, risks and assumptions, and open questions. It should be short enough to read, specific enough to build from, and kept up to date.
This guide is for founders, product managers and business owners commissioning software. For website projects, see website requirements documents; for the work that comes before, software product discovery.
Key takeaways
- Lead with the problem and outcomes, not features.
- Say what is out of scope.
- Write acceptance criteria people can test.
- Include non-functional requirements.
- List assumptions, risks and open questions.
- Keep it current as decisions change.
A PRD template
| Section | What to include |
|---|---|
| Problem and context | Who has the problem, evidence, why now |
| Users and roles | Primary users, other roles, permissions |
| Outcomes and metrics | What success looks like and how it is measured |
| Scope and non-goals | What is included in this release, and what is not |
| User journeys | Key flows from start to finish |
| Functional requirements | What the software must do, with acceptance criteria |
| Non-functional requirements | Performance, availability, security, privacy, accessibility (WCAG 2.2 AA), devices |
| Data and integrations | Data sources, migrations, external systems |
| Risks and assumptions | What could go wrong; what you are assuming |
| Open questions | Decisions still to be made, with owners |
Writing good requirements
- Describe behaviour, not implementation: 'a manager can approve or reject a request with a reason'.
- Make acceptance criteria testable: given, when, then.
- Use consistent terms; add a glossary for domain words.
- Prioritise: must, should, could, won't (this release).
- Link to designs, research and technical findings rather than copying them.
- Note legal or regulatory requirements to confirm with advisers.
Keeping it alive
A PRD is most useful when it reflects current decisions. Keep it in a shared place with history, record changes and their reasons, and update it when research or technical discovery changes the plan. Link it to the backlog so stories trace back to requirements. See technical discovery for the technical inputs.
Hypothetical example: a staff leave approvals feature
This example is hypothetical. A business wanted leave requests and approvals in its staff portal. The PRD described the problem (requests lost in email), users (staff, managers, payroll), outcomes (requests approved within two working days, fewer payroll corrections), scope (requests, approvals, balances from payroll; not rostering), journeys, acceptance criteria, accessibility and privacy requirements, the payroll integration as a dependency, and open questions about delegation when managers are away.
Common mistakes
- Feature lists with no problem or outcomes.
- No non-goals, so scope keeps growing.
- Vague requirements that cannot be tested.
- Forgetting non-functional requirements.
- A document written once and never updated.
Related guides
- User research methods for evidence behind requirements.
- SaaS roadmap prioritisation for choosing what goes in.
- Design handoff for connecting designs to build.
- MVP development for scoping a first release.
Conclusion
A useful PRD connects business needs to buildable, testable requirements: problem, outcomes, scope, journeys, functional and non-functional requirements, risks and open questions. Keep it concise, specific and current. To make requirements testable, see acceptance criteria and UAT.
Turning an idea into requirements?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on product discovery and design, web applications and mobile apps. If it would help to shape your requirements, we are happy to talk it through.
Common questions.
A PRD describes what a product or feature should achieve and do: the problem, users, desired outcomes, scope, user journeys, requirements and constraints. It aligns business, design and engineering before and during delivery. It is not a detailed technical design.