How to Write PRDs for Product Managers
Outcome-Focused, Not Output-Focused
This is the principle most product managers understand in theory and violate in practice. And it is worth being direct about why, because the temptation is real and entirely understandable.
An output is what you build. An outcome is what changes as a result.
An output-focused PRD describes features, screens, flows, and components. An outcome-focused PRD describes the change in user behaviour or business performance those features are meant to produce. The output is the means. The outcome is the point. When a PRD is built around outputs, the team knows what to deliver. When it is built around outcomes, the team knows what they are actually trying to accomplish. That second layer of understanding is what enables good judgment when reality does not match the plan, which it never does exactly.
Consider the difference between these two goal statements.
- Output-focused: Build a dashboard where users can view their account activity in one place.
- Outcome-focused: Reduce the time it takes for users to identify and act on account anomalies, measured by a 30% reduction in time-to-detection and a corresponding decrease in support tickets related to undetected issues.
The first tells the team what to build. The second tells the team what to accomplish. A team working from the first statement finishes when the dashboard is shipped. A team working from the second keeps asking whether what they are building is actually producing the change they intended, which is a far more valuable question.
Why teams default to outputs is not laziness. Outputs are concrete and comfortable. They can be listed, tracked, and completed. Features feel like progress because they are visible and finite. Outcomes are harder. They are uncertain, delayed, and require the team to think beyond delivery into impact.
But output-focused PRDs produce teams that ship on time and miss the point. They produce features that were built exactly as specified and moved none of the metrics they were supposed to move. They produce retrospectives full of the uncomfortable phrase we delivered everything and nothing changed.
The way to avoid this is to build the connection between output and outcome explicitly into every section of the PRD.
- Every goal should describe a change, not a deliverable
- Every success metric should measure impact, not completion
- Every requirement should be traceable to a user need or business result
A team that ships everything in the PRD but moves none of the metrics has not succeeded. Outcome-focus is what keeps the PRD honest about what success actually means.