Josh Seiden has written a book of remarkable economy. Outcomes over Output makes a single argument, makes it clearly, provides the tools to act on it, and stops. There is no padding, no extended methodology, no framework with a registered trademark. Just a precise and necessary challenge to the way most technology organisations measure their own progress.
The argument: organisations manage outputs - features shipped, story points completed, releases delivered - because outputs are visible, countable, and controllable. But outputs are not value. Value is the change in human behaviour that the output produces. Chasing outputs without understanding the behaviour change they are intended to create is how organisations build things that technically work and practically fail.
The gap between output and outcome is where most technology investment disappears. A feature is shipped. The metric does not move. The team debates whether the feature was well-built, well-designed, or well-communicated. Nobody asks the prior question: did we understand the specific behaviour change we were trying to produce, and did we design for that behaviour change, or just for the feature?
For engineering leaders, this book matters because it reframes what the team is accountable for. Not the code. The behaviour the code was intended to change. That reframing changes how work is defined, how success is measured, and how learning happens after delivery. It is a small conceptual shift with large practical consequences.
Seiden's definition of outcome is precise and important: not a business metric, not a user metric, but a change in what specific people do as a result of the product. A customer who was previously calling support now self-serves in the app. A manager who was previously running manual reports now uses the dashboard. An engineer who was previously deploying once a week now deploys daily.
These are outcomes. The metric that captures the behaviour change - support call volume, dashboard sessions, deployment frequency - is the evidence that the outcome occurred. The feature that enabled the behaviour change is the means. Most organisations measure the means (was the feature shipped?) or an abstracted metric (did revenue grow?) without ever specifying the behaviour change that connects the two.
The book's most practically useful section is its treatment of OKRs. Seiden's observation is that most OKR implementations produce key results that are output metrics in disguise - "launch the new onboarding flow," "complete the API migration," "release three new integrations." These are things the team will do, not changes the team will produce.
Outcome-based key results name the behaviour change: "increase the percentage of new users who complete a second session within seven days from 40% to 60%." This formulation is harder to write, because it requires the team to understand the customer behaviour well enough to specify the change and name the metric. But it is also the only formulation that forces the team to ask whether what they are building will actually produce the intended result.
Seiden offers a set of framing questions that, when applied consistently, move teams from output thinking to outcome thinking. What are the user and customer behaviours that drive the business results we want? How can we change those behaviours? How will we know if we've succeeded?
These seem simple. In practice, they are revealing. Most teams can answer "what will we build?" and "when will it be done?" with precision. The magic questions - particularly "how will we know if we've succeeded?" - expose the absence of a genuine outcome hypothesis. If a team cannot specify in advance what behaviour change would tell them the feature worked, the feature is built on hope rather than hypothesis.
Once a team is oriented around behaviour change rather than feature delivery, the operational model changes. Work becomes a series of experiments: hypotheses about what behaviour change a specific intervention will produce, followed by minimum viable tests, followed by measurement, followed by decisions to persist, pivot, or stop.
This is not a novel idea - it is the lean startup applied at team level. What Seiden adds is the clarity that this model is not compatible with a fixed annual roadmap of features. Outcome-oriented teams need a clear destination (the outcome they are pursuing) and freedom to find the best path to it. The roadmap is replaced by a hypothesis backlog, and velocity is replaced by learning rate.
The final and most important argument in the book concerns what has to change above the team level for outcome orientation to take hold. Teams cannot manage to outcomes if management is measuring outputs. Teams cannot run experiments if they are committed to roadmaps. Teams cannot learn if they are not given the time and space to measure the effect of what they shipped.
Outcome orientation is not a team-level change. It is an organisational-level change in what leadership pays attention to, celebrates, and holds people accountable for. The easiest signal: is the leadership conversation after a release "did we ship it?" or "did it work?" The answer tells you everything about the incentive structure the team is operating inside.
Write down the last three features your team shipped. For each, write down the specific behaviour change it was intended to produce. If you cannot write it down, the feature was built without a behavioural hypothesis - and you have no way of knowing whether it worked.
"Did we ship it on time?" and "did it work?" are not the same question. Organisations that measure only the first one are not measuring product success. They are measuring delivery success - which is a necessary but insufficient condition for value creation.
A roadmap full of features is a bet. A roadmap full of outcomes is a strategy. Both require execution - but only one of them tells the team what problem they are solving.
The teams most resistant to outcome measurement are often the ones most invested in the output model - because output measurement protects you from the uncomfortable question of whether what you built actually mattered.
If your team cannot tell you, with data, whether the last release changed user behaviour in the intended direction, you do not have a feedback loop. You have a delivery pipeline that ends at shipping.
Rewrite your current sprint goals in outcome terms. Not "build X" - "produce Y behaviour change in Z group of users, evidenced by W metric." Run one sprint against outcome goals and measure the difference in how the team talks about their work.
Identify the three customer behaviours most correlated with the business results you care about. These are your outcome targets. Make them visible, measure them weekly, and orient your quarterly planning around moving them.
Audit your OKRs. For each key result, ask: is this a behaviour change with a measurable metric, or is it a deliverable with a date? Rewrite one key result in each objective as a genuine outcome measure.
Add "how will we know if it worked?" to your definition of ready. Before any work item enters a sprint, the team should be able to answer this question with a specific behaviour metric. If they cannot, the item is not ready.
Schedule a retrospective specifically on outcome measurement. What did you ship last quarter? What were the intended outcomes? What did the data show? What would you do differently? The discipline of closing this loop is the practice that separates learning organisations from outputting ones.
"If you want to change the world, you have to change behaviour. Features are means. Behaviour change is the end. Make sure you know which one you are managing."
- Josh Seiden