What is the Outcome vs. Output Distinction?
An output is something a team produces: a feature, a design, a release. An outcome is the change in user behavior or business results that the output causes. The distinction matters because teams can be incredibly productive (high output) while achieving nothing meaningful (no outcomes).
The shipping velocity of your team is an output metric. Whether users actually adopt what you shipped and whether it moves a business needle are outcome metrics.
Why This Distinction Matters
Teams measured on outputs become feature factories. They optimize for throughput: more features, more releases, more story points. But shipping faster does not mean shipping better. A team that ships one feature that doubles retention outperforms a team that ships twenty features nobody uses.
The outcome mindset changes how PMs work. Instead of writing PRDs that specify exactly what to build, outcome-oriented PMs define the problem and the target metric, then let the team find the best solution.
How to Shift from Outputs to Outcomes
Start with your OKRs. Are your key results output-based ("launch feature X") or outcome-based ("increase activation by 15%")? Rewrite any output-based key results as outcomes.
Change how you define success for each initiative. Before starting work, answer: "What user or business metric will change if this works?" If you cannot answer that question, you do not understand why you are building it.
Create a learning loop. After shipping, track the outcome metric. Share results with the team and stakeholders. Celebrate impact, not just delivery.
Outcome vs. Output in Practice
Spotify shifted from output tracking ("features shipped per squad") to outcome tracking ("impact on user engagement per squad"). This changed how squads planned their work, prioritizing high-impact bets over safe incremental features.
Amazon's "working backwards" process starts with the desired customer outcome and works backward to the features needed. The press release and FAQ written before development describe outcomes, not features.
Common Pitfalls
- Measuring only outputs because they are easy. "Features shipped" is easy to count. "Impact on retention" requires analytics infrastructure. Build the infrastructure.
- Outcomes without accountability. Defining outcome goals but then not tracking them post-launch defeats the purpose.
- Confusing activity with outcomes. "We ran 15 experiments" is an output. "We found 3 changes that improved conversion by 8% each" is an outcome.
- All-or-nothing thinking. You still need to ship things. Outputs matter. The point is that outputs are means, not ends.
Related Concepts
The outcome vs. output distinction is central to OKRs, product strategy, and avoiding the feature factory trap. Outcomes are measured through product analytics and tracked via key results. For practical application, see hypothesis-driven development.