Recap

This module gives you the working layer of a PRD: the requirements and the acceptance criteria that translate a well-defined problem into a buildable specification.

Hold these close before moving forward.

Functional requirements describe what the product must do. They define specific behaviours, name the users involved, and are testable against a clear pass or fail condition. Organise them by user journey and prioritise them explicitly so the team knows what trade-offs are acceptable under pressure.

Non-functional requirements describe how well the product must perform. Performance, reliability, security, accessibility, compliance, and scalability are not optional additions. They are the conditions under which the feature must work in the real world. Define them before development or pay the cost mid-build.

A well-written requirement is clear, specific, testable, independent, and realistic. Avoid bundling behaviours, writing solutions disguised as requirements, using passive voice that obscures ownership, and using vague descriptors that each reader will interpret differently.

Acceptance criteria define done. They state precisely what must be true for a requirement to be considered complete. Use Given-When-Then to structure them. Cover the happy path, the edge cases, and the error states. Write them before development begins.

Requirements and acceptance criteria together are the most practical tools in a product manager's writing kit. They are what engineers build from, what designers constrain to, what QA tests against, and what the team returns to when disagreement arises about whether something is finished.

Get them right, and development moves with clarity and confidence. Get them wrong, and every hour of engineering time becomes a negotiation about what was actually meant.