How to Write PRDs for Product Managers
Acceptance Criteria
What Acceptance Criteria Are
Acceptance criteria are the specific conditions that must be true for a requirement to be considered complete. They are the bridge between the requirement and the test: they state precisely what the product must do and not do for the team to accept that the requirement has been met.
The relationship between requirements and acceptance criteria is this:
The requirement says what the product must do. The acceptance criteria say how you will know it did it.
A feature without acceptance criteria is a feature with an undefined definition of done. The engineer finishes what they believe the requirement meant. The designer approves what they believe the experience should be. The product manager reviews and sees something different from what they imagined. This is not a communication failure. It is a requirement failure. Acceptance criteria are what prevent it.
How to Write Them
The most widely used format for acceptance criteria is the Given-When-Then structure.
- Given describes the starting condition or context
- When describes the action the user takes or the event that occurs
- Then describes the outcome the product must produce
Example:
Requirement: Users must be able to reset their password using their registered email address.
Acceptance criteria:
- Given a user is on the login page and clicks the Forgot Password link, When they enter an email address registered to an account and submit the form, Then the system must send a password reset email to that address within 60 seconds
- Given a user enters an email address not associated with any account, When they submit the form, Then the system must display a message stating that if the email exists in the system, a reset link has been sent, without confirming whether the account exists
- Given a user clicks the password reset link in the email, When the link is more than 24 hours old, Then the system must display an expiry message and prompt the user to request a new link
Notice what these criteria do. They cover the primary success path, the edge cases, and the failure states. They are specific enough to be tested directly. They leave no room for reasonable people to disagree about whether the requirement was met.
Covering the Right Scenarios
Well-written acceptance criteria cover three categories of scenarios.
The happy path: the primary flow where everything goes as expected and the user accomplishes their goal without friction. This is the scenario most teams naturally think of, and most acceptance criteria only cover this one.
Edge cases: the boundary conditions and unusual inputs that occur less frequently but are entirely predictable. What happens when the user enters the maximum allowed number of characters? What happens when their session expires mid-flow? What happens when they submit the same form twice in rapid succession?
Error states: the conditions under which something goes wrong and the product must respond in a defined way. What does the user see when a network request fails? What happens when a required service is unavailable? What is displayed when validation fails?
If your acceptance criteria only cover the happy path, you have defined done for the best case and left the team without guidance for every other case.
Acceptance Criteria and QA
Acceptance criteria serve a dual purpose. They guide development and they define the scope of quality assurance testing.
A QA engineer reading a requirement with well-written acceptance criteria knows exactly what to test, what inputs to use, what outputs to expect, and what constitutes a pass or a fail. A QA engineer reading a requirement without acceptance criteria must infer all of this from context, which introduces inconsistency and gaps.
Well-written acceptance criteria save time at every stage of development because they replace guesswork with precision. They reduce the number of review cycles between engineering and product. They reduce the number of bugs that reach production because the test cases were undefined. They reduce the number of conversations that begin with I thought the requirement meant...
Remember this: Acceptance criteria are not a formality. They are the precise definition of done. Cover the happy path, the edge cases, and the error states. Write them before development begins, not after. And if a requirement cannot be expressed in testable acceptance criteria, the requirement is not yet clear enough to be built.