How to Write PRDs for Product Managers
Functional Requirements
What They Are
Functional requirements describe what a product must do. They define the specific behaviours, capabilities, and actions the system must be able to perform to serve the user and solve the problem.
Every functional requirement answers one question: what must this product do?
A functional requirement is not a design decision. It is not a technical specification. It is a statement of behaviour that the product must exhibit, written in terms clear enough that a designer can shape it and an engineer can implement it without needing to guess at your intent.
Examples of functional requirements:
- The system must allow users to reset their password using their registered email address
- The system must display an error message when a user attempts to submit a form with missing required fields
- The system must notify users via email when their order status changes
- The system must allow administrators to assign or remove user roles without engineering support
Notice what these statements share. Each one describes a specific behaviour. Each names who is involved. Each is testable: you can look at the product and determine whether it does or does not do the thing described.
How to Organise Them
Functional requirements written as an unstructured list become difficult to navigate as the feature grows in complexity. Organise requirements by user journey or feature area, grouping related behaviours together. This makes it easier for designers to map them to flows and for engineers to scope work.
A useful structure within each group is to distinguish between:
- Must have: requirements the feature cannot ship without. Core functionality.
- Should have: requirements that are important but could survive a first release if deprioritised under constraint.
- Nice to have: requirements that would improve the experience but are not essential to solving the core problem.
This is sometimes called MoSCoW prioritisation, and it gives the team explicit guidance about what trade-offs are acceptable when time or resource pressure arrives, which it always does.
Remember this: Functional requirements describe behaviour, not design or implementation. Each one should be specific enough to be testable and clear enough that the team does not need to ask you what you meant.