How to Write PRDs for Product Managers
Testability and Clear Success Criteria
A requirement that cannot be tested is a requirement that cannot be verified as complete. A goal without a measurable success criterion is a goal that can be declared achieved at any point, for any reason, by anyone motivated to declare it. Both situations produce the same outcome: the team cannot know with confidence whether the thing they built is the right thing.
Testability is not a QA concern. It is a product discipline that begins at the point of writing.
When you write a requirement, ask immediately: how would I know if this was met? If the answer is not clear, the requirement is not yet clear. The clarity that testability demands forces a level of precision that makes every other aspect of the PRD stronger.
The simplest test for testability is this: can two people look at the product and agree, without discussion, on whether the requirement was met? If the answer is no, the requirement needs more specificity.
The difference looks like this in practice.
- Not testable: The onboarding flow should be easy to complete.
- Testable: Users must be able to complete all steps of the onboarding flow without accessing help documentation, with a target completion rate of 80% or above among first-time users within the first 30 days post-launch.
The second version has a clear condition, a clear measurement, and a clear timeframe. Either users completed the flow at that rate or they did not. Nobody needs to interpret anything. Nobody needs to have a conversation about what easy means.
Writing clear success criteria requires three specific practices.
- Define them before launch, not after seeing results. Post-hoc success criteria are not success criteria. They are justifications. The motivated reasoning that leads teams to interpret ambiguous results favourably is only prevented by committing to what success looks like before the data arrives.
- Distinguish between leading and lagging indicators. A leading indicator is something measurable quickly after launch that predicts the longer-term outcome you care about. A lagging indicator is the actual outcome, which may take weeks or months to manifest. Both matter and both should appear in the PRD.
- Include guardrail metrics. Guardrail metrics are things you must not harm in the pursuit of improving your primary metric. If improving activation rate comes at the cost of downstream retention, the feature has not truly succeeded. Defining guardrails in advance prevents selective interpretation of results and keeps the team honest about the full picture of impact.
If the team cannot look at the product after launch and determine clearly whether the feature succeeded or failed, the success criteria were not clear enough. Define them before development. Make them specific. Include guardrails. Do not move them after seeing the data.