Output is what the scrum team produced. Features, releases, story points, items moved to Done. Outcome is what changed for a user or for the organisation as a result. The two are related but not proportional, and the gap between them is where most product effort disappears.
The relationship
Output is necessary and not sufficient. Nothing changes without something being built, and plenty gets built without anything changing. Output is entirely under the team's control, which is exactly why it is the tempting thing to measure. Outcome depends on people outside the team deciding to behave differently, which is why it is the honest thing to measure.
A useful chain runs output, then adoption, then behaviour change, then business result. Each arrow can fail. Reporting only on the first link tells you the team was busy.
Why output is the number that gets counted
Output is countable on the day the work finishes and belongs entirely to the people reporting it. An outcome arrives later, sometimes months later, and by then other things have changed as well, so attributing the movement to one release takes argument rather than arithmetic. The easy number is not a conspiracy, it is the one available on the day somebody asks.
Impact is one step further out
The last link in that chain has a name of its own. Outcome is the behaviour that changed, and impact is what that change was worth, arriving as revenue, as retention or as a cost of service that has fallen. The distinction earns its keep when a target is set, because an impact target with no outcome underneath it leaves a team nowhere to start. Nobody can build revenue directly.
Stating a goal as a behaviour change
A feature shipped is not a problem solved, and the surest way to keep the two apart is to write the goal as something a person will do differently. Add a bulk export names a deliverable and is finished the moment the button exists. Finance leads pulling their month end figures without leaving the reporting screen names a behaviour, and it is finished only when they do it. The second wording is harder to write, tells the Developers what the item is for, and leaves everyone able to say afterwards whether it worked.
Naming the measure before the work starts
An outcome still needs a measure chosen in advance, or it becomes a story told afterwards. Once a release is out, a plausible account of why it helped can be assembled from whatever else moved that quarter, and it tends to be believed, because nobody wrote down beforehand what would have counted as failure. Choosing the number first can come back negative, which is precisely what makes it evidence rather than decoration.
Four actions that increase outcome while reducing output
Order by the outcome, then cut. For each item near the top, name the behaviour it is supposed to change. Then find the smallest version that could plausibly change it. Most items shrink considerably under that question, and some disappear.
Say no in the open. A backlog that only ever grows is a backlog nobody is deciding about. Removing items that no longer serve the Product Goal is a product owner action with an immediate effect on outcome per unit of output, because it stops work being spread across candidates that were never going to matter.
Validate before building rather than after. The cheapest feature is the one discovery showed nobody wanted. Moving evidence earlier reduces output directly.
Release smaller and watch. Each release that goes out and gets observed produces information that shortens the next one. Batching six months of work removes every opportunity to learn in between.
What to do about being measured on output
Most organisations count output because it is countable. The move that works is not to refuse the count but to attach the outcome to it. Report the feature and the behaviour it changed side by side, every time. After a few cycles the conversation moves on its own, because the cases where the first number moved and the second did not become impossible to ignore.