Outcomes Over Output

The idea

In Outcomes Over Output (2019), Josh Seiden defines an outcome as a change in human behaviour that drives business results. Output is what a team makes: features, releases, documents, code. Impact is the high-level result the organisation wants, such as revenue or retention. Outcomes sit between them: the things people (customers, users or employees) do differently because of what you made.

Seiden's argument is that output is easy to count but says little about value, while impact is what matters but is too broad and slow to steer by. Outcomes are the useful middle: specific enough for a team to influence and measure, and linked closely enough to impact to matter. He suggests asking what customer behaviours drive business results, and how to get people to do more of them. Managers then give teams outcomes to achieve and let them work out which output will create them. Martin Fowler made the same point for software teams: unused features waste effort and leave code to maintain.

Why it works

Features are guesses. A roadmap of features assumes we know which ones will change behaviour. Making the outcome the goal keeps that assumption open to test.

Behaviour is a leading indicator. Revenue moves slowly and has many causes; a change in what users do shows up in weeks and can be linked to the work.

Less output can be more value. When success is a behaviour change, a team that solves the problem with a small change, or by removing something, gets credit instead of being penalised for a short release list.

Where it applies

• Roadmaps and funding, setting targets as behaviours rather than feature lists.
• Platform teams, measuring adoption and changes in how product teams work, such as time from commit to production, rather than capabilities launched.
• Modernisation programmes, where "migrated 40 services" is output and "teams release weekly instead of quarterly" is an outcome.
• Architecture reviews, asking which behaviour a design is meant to change and how the system will show it.

How to apply

1. Start from impact. Name the business result that matters, such as lower churn or lower cost to serve.
2. Find the behaviours that drive it. Ask who does what that leads to that result, using data and conversations.
3. Write the outcome precisely: who, what behaviour, and how much more or less.
4. Instrument the system so the behaviour is visible, ideally before work starts.
5. Let teams choose the output, review progress against the outcome, and stop work that does not move it.

Example scenario

An enterprise architecture team ran a programme to "deliver an API platform": a gateway, a developer portal and forty published APIs. After a year all three targets were met, yet product teams still integrated point to point, and integration lead time had not changed.

The programme was reset around an outcome: "product teams take a new integration to production in under two weeks, using a published API, without raising a ticket". Measuring that showed the blocker was access approval, not missing APIs. The team automated approvals and documented the ten most used APIs properly, published few new ones, and lead time fell. The architecture got smaller as the outcome got clearer.

Questions to ask

When not to use it

• Obligations with a fixed output, such as a regulatory report, where the output is the requirement.
• Foundational work whose outcome is distant; give it a nearer proxy, such as a team's ability to change something, rather than forcing a customer metric.

How it misleads you