outcome vs output
Also called: outcomes over outputs
The distinction between what a team produces (output: features, releases, documents) and the difference those things make for customers and the business (outcome: changed behavior, solved problems, moved metrics).
Output is what a team produces: features, releases, redesigns, campaigns. Outcome is the difference those things make: customers behave differently, a problem goes away, a business metric moves. A handy test: an output can be ticked off the day it ships, while an outcome can only be checked after users have had time to react.
Why the distinction matters for roadmaps: a roadmap of outputs judges the team by whether it shipped on time. That can look great while nothing improves. Releases go out, KPIs stay flat and customers ignore the new features. A roadmap of outcomes judges the team by whether the intended change happened, which is the reason the work was funded in the first place.
To turn an output into an outcome, ask why until you reach a change in behavior or results:
- "Build a mobile app" → why? → customers struggle to reorder on their phones → outcome: more repeat orders from mobile users.
- "Integrate with a CRM" → why? → sales managers retype leads by hand → outcome: less time from lead to first call.
Outputs don't disappear. You still need them to reach outcomes, and the release plan is full of them. On the roadmap, though, they come second, as candidate solutions under the outcome they serve. That way, if a solution doesn't deliver, the team swaps the solution, not the goal.
Example
Three items from CatChow's request list, rewritten:
Each outcome now allows other solutions too: delivery answers might come from order-status SMS rather than a chat.
Common mistakes
- Calling a deliverable an outcome. "Launch the new checkout" is an output, even with a date attached. An outcome names a change in behavior or results.
- Picking outcomes the team can't influence. "Grow company revenue by 20%" is too far from one team's work. Choose a closer leading indicator.
- Declaring victory at release. Plan when and how you will check the outcome, not just when you ship.
- Measuring only activity. Clicks on a new button can rise while the real problem stays. Tie the metric to the problem.
- Dropping output planning altogether. Teams still need release plans; outcomes decide what goes into them.
Learn it in the course
- Outcomes over outputs · The difference between what a team ships and what changes because of it, how to climb from a feature request to a measurable outcome, and the traps that make an outcome useless.