Outcomes over output. The difference between delivering stuff and delivering value.
This post is a summary of Josh Seiden’s wonderful book ‘Outcomes over Output’.
We live in a digital era where users’ and customers’ expectations are evolving faster than ever. Yet sometimes our ways of thinking, working and organising don’t keep pace. We still work like it’s the industrial era when we mostly made physical goods, and making stuff well was the primary challenge.
When building a bridge, you know you’re done when the bridge is built and people are crossing it safely. If you’re making cars, you’re done when they roll off the assembly line. But when you’re making software products, done is less obvious. When is Microsoft Word or Google or even a Learning Management System done? In reality, software systems are never done. We just decide to stop working on them, or work on one part of them over another.
Making stuff in the industrial era
Features versus Outcomes
The problem with thinking in features is that it’s common to get caught in this kind of confusion - mistaking “making stuff” for making progress, and mistaking shipping features for being done. Features can be finished and delivered and “work perfectly” but still not deliver any value.
If you’ve ever used a microwave oven you’ve experienced this problem of too many features. How many of these buttons do you use in real life?
Outcomes on the other hand have nothing to do with making stuff—though they sometimes are created by making the right stuff. An outcome is a change in human behaviour that drives business results. They are the changes in customer, user, employee behaviour that lead to good things for your company.
Hypotheses, Experiments & Agility
Outcomes are natural partners with hypotheses. When we state our goal as an outcome, we’re either proposing some logical relationship between our work and the result we seek, or asking our teams to figure out that relationship—because we’re asking them to figure out how they might create that outcome. And once we’ve proposed that relationship, we capture it in a hypothesis, and test it with an experiment. When you combine outcome-based targets with a process that’s based on running experiments, you really start to unlock the power of agile approaches.
Outcome Oriented Managers
Good managers know to ask their teams to deliver value—in other words, don’t just deliver stuff, instead, do something that creates value. Managers can use a simple questions to start a conversation about outcomes:
What are the user / customer behaviours that drive business results? This is the outcome that we’re trying to create.
How can we get people to do more of those behaviours? These are the features, policy changes, promotions, etc that we’ll do to try to create the outcomes.
How do we know that we’re right? This uncovers the dynamics of the system, as well as the tests and metrics we’ll use to measure our progress.
Instead of planning for some mythical “feature-complete” future state (remember, software is never complete), managers can push their teams to visualise behaviour by using customer journeys as the center of the conversation. In this way, teams can deliver value early, then enhance that value through continuous, incremental delivery.
In a fast changing and uncertain world, outcomes are a great way to set goals because they allow teams to experiment—to try different solutions—until they hit on the one that works. Coordination in organisations is always going to be hard—there’s no perfect organisation of course, you’re always optimising for one factor over another—but so often, our organisations are set up around product or channel vs behaviour or customer journey. And when we do that, we’re implicitly de-prioritising outcomes and prioritising outputs.
