Outcome Over Output¶
Definition¶
Patton distinguishes output — the software you actually deliver — from outcome — the change in behavior it produces in the people who use it. "Your job isn't to build software, it's to change the world." Prioritizing by outcome means asking what specific people need to be able to do differently, rather than which features seem important in the abstract; without a named target outcome, he argues, "prioritization is close to impossible," because every feature can be defended as valuable to someone in isolation.
In the Book¶
Chapter 2's central case is Globo.com's rebuild of its shared content-management system with eight teams and an immovable deadline: Brazil's upcoming presidential election. When the combined story map showed a year-plus of work, Patton asked the teams "Do you need all of this to go live for the election?" — reframing the question from "what's on our backlogs" to "what specifically has to be true about the news website experience during the election for this to be a win." That single reframe let the teams slice a first release around one target outcome (impressing visitors and advertisers with faster, more innovative election coverage) instead of trying to sequence hundreds of undifferentiated backlog items. Patton contrasts this with the trap the teams were already falling into — "identifying sequence and dependency assuming they'd need to build everything," a purely output-oriented question of when rather than an outcome-oriented question of why. He generalizes the lesson with a line meant to be quoted on its own: "scope doesn't creep; understanding grows" — what looks like uncontrolled growth in a backlog is usually the team discovering, through mapping, what the outcome actually requires.
Why It Matters¶
A list of features or deliverables can always be made longer, because more is always defensible in isolation; a list of target outcomes forces a decision, because you can specify concretely what would count as having achieved it and stop once you have. This is the general antidote to endless scope in any domain where "more work product" gets mistaken for "more value" — the discipline of naming the external change you're trying to cause before deciding what internal work is worth doing to cause it.