Outcomes vs. outputs: measure impact, not deliverables

An output is what the team produces; an outcome is the change it causes in people or business. How to tell them apart, which metrics mislead, how to set goals.

info Quick Definition

An output is what the team produces: a feature, a screen, a project or an initiative. An outcome is the change that output causes in people’s behaviour or in a business result. The difference looks small, but it defines whether a team is accountable for what it shipped or for what it changed.

What is the difference between an output and an outcome?

Each author defines it with their own nuance:

Teresa Torres (Product Talk, 2026): an output is something you build or produce (a feature, a project, an initiative), and an outcome is the impact of that output: a change in customer behaviour or a business result. When a team is tasked with delivering outputs, it is done when the software ships.
Josh Seiden (author of Outcomes Over Output), in a conversation published by Intercom in 2019: an outcome is a change in human behaviour that drives business results. Torres quotes the same definition.
Marty Cagan (SVPG, 2019): feature teams “are all about output” and receive a prioritized list of features and projects. Product teams are cross-functional and are focused on and measured by outcomes, not output.
Product School (2025): outputs are what the product team delivers, and outcomes are the change that delivery creates.

What they share: a team should be accountable not for shipping features, but for the change those features aim for.

Why does it matter to a designer?

Because design is one of the most visible deliverables. Screens, prototypes and flows can be counted, shown and approved. If the team is measured by that, the incentive is to deliver more, not to check whether what was delivered works. A designer who presents five finished screens may be doing good work and still have changed nothing.

Thinking in outcomes gives design a more useful question. Instead of “what did we deliver?”, the question becomes “what will people do differently once this exists?” That question leads straight to research, hypotheses and testing.

How do you identify an outcome?

In the Intercom conversation, Seiden proposes a concrete question for any feature: what will people be doing differently as a result of this? If the answer is “they will use the feature”, that is an output. If the answer describes an observable change, such as “they will run fewer searches before finding what they need”, that is an outcome.

Seiden gives an NPS example: no single team can change NPS directly, so the job becomes a scoping problem. The team asks which behaviours of its own and its customers it can change, and turns them into changes it can design and test.

Product Talk also recommends that setting outcomes be a two-way conversation: the leader brings the business-wide view and the team brings knowledge of the customer and the technology. Neither side should dictate. Its example: “our outcome is to deliver an Android app” is an output; asking about its value surfaces the underlying outcome of engaging more people, which can be scoped to all platforms, to mobile users or to Android users.

Why do traction metrics mislead?

Product Talk warns that some metrics look like outcomes but only measure adoption. Its example: increasing the percentage of users who viewed a performance report. It looks like a good outcome, but Torres calls it a traction metric because it measures adoption of a single feature, not value to the customer: viewing the report does not show it was useful, and some customers may not need it at all.

Sentiment metrics such as CSAT or NPS have limits too. Product Talk finds them tricky on their own because they are not directional. It suggests pairing them with a behavioural metric, such as “increase engagement without negatively impacting satisfaction”.

Another trap is the output dressed up as an outcome. “Launch the new onboarding” sounds like a result, but it is still a deliverable. The outcome could be something like “more people complete their first task in the first week”.

How do you test it?

An outcome is a hypothesis until it is checked. Seiden talks about framing the work as a hypothesis (“we think that if we make this feature, it will generate this outcome”) and testing it with an experiment or an MVP. In his view uncertainty is normal: you do not need to be certain that a change will shift behaviour, but you need at least a hunch that justifies testing it.

For a new outcome, Product Talk recommends setting a learning goal first (“learn what moves the needle on this metric”) and a performance goal second (“increase X by Y%”). That way the team knows whether the test taught it something, even if the number has not moved yet.

For the practical side, Lean UX proposes the same cycle from the design side: assumption, minimum test, measurement and decision.

Example

Illustrative example: a design team for an online shop has as its goal “Redesign the cart”. Reviewing it, the team asks what should change in the behaviour of people who buy. It rewrites the goal: “More people complete a purchase after adding a product to the cart”. As a first test, it shows the shipping cost on the cart screen itself, rather than at the end, for half the users. If the purchase rate rises, the change becomes permanent. If it does not, the team learns that shipping was not the main barrier and looks for another hypothesis, without having redesigned the whole cart.

For your team: take three deliverables from the last planning cycle and, for each one, write which behaviour should change. If you cannot write it, the deliverable probably does not have a clear outcome.

When should you NOT force the distinction?

When the deliverable is mandatory because of regulation, security or contract. An output can be necessary even without a measurable outcome.
When the outcome cannot yet be measured and there is no reasonable way to approximate it. Then start with a provisional indicator and review it.
When the metric becomes the goal and the product starts optimising it at the expense of the experience.
When the team has no access to behavioural data. Without it, the outcome is a guess.

Common mistakes

Calling a deliverable an outcome under another name.
Using adoption metrics as if they measured value.
Measuring only sentiment, with no behaviour alongside it.
Setting targets so conservative that they are always met and teach nothing.
Forgetting the learning goal and measuring performance alone.
Dropping the distinction as soon as someone asks for delivery dates.

To order what to measure over time, read the note on the North Star Metric: there, input metrics are how outcomes become levers for work. The OKRs for design apply the same idea to quarterly objectives, and the team’s KPIs should point at outcomes, not only at deliverables.

Sources

Frequently asked questions

What is an output and what is an outcome?

An output is something the team builds or produces: a feature, a project or an initiative. An outcome is the impact of that output, meaning a change in customer behaviour or a business result.

Why are adoption metrics not outcomes?

Because they measure that someone used something, not that it helped them. Product Talk calls them traction metrics: they indicate adoption, not value. An outcome describes what people do differently after the change.

How do you turn a business goal into product outcomes?

By asking which behaviour would have to change. Josh Seiden suggests asking what people will be doing differently as a result of a feature, then stating a hypothesis and testing it.

Why does this matter for design?

A team measured by screens delivered has little incentive to check whether what it delivered works. Measuring outcomes pushes design to work with hypotheses and to accept when a solution changes nothing.