Outcomes over outputs
The difference between shipping and changing something, the three kinds of goal that get confused with each other, and why leading indicators beat lagging ones for a team that wants to act.
- An outcome is a change in human behavior that drives business results. An output is the thing you shipped.
- Three kinds of goal get called the same thing: business outcomes, product outcomes, and traction metrics. Your team should own the middle one.
- Leading indicators move before the result and put you in a position to act. Lagging indicators confirm what already happened.
- The most useful thing your team can find is a leading indicator that reliably predicts a lagging one that leadership cares about.
The distinction
Output is what you produce. Outcome is what changes because of it.
"We shipped the referral flow" is an output. "More new users arrive through a friend" is an outcome. You can achieve the first with certainty by working hard. You cannot achieve the second by working hard, only by working on the right thing, which is precisely why it is the more honest measure.
A team measured on outputs will always hit its numbers and can still be worthless. A team measured on outcomes sometimes misses, and that miss carries information.
Three things people call a goal
Most confusion in goal-setting comes from three different measures wearing the same word.
| Type | What it measures | Example | Who should own it |
|---|---|---|---|
| Business outcome | The health of the business | Net revenue retention, annual recurring revenue | Leadership |
| Product outcome | How the product drives that business result | Share of customers who reach their second project | The product trio |
| Traction metric | Usage of one specific feature | Number of users who opened a template | Nobody, usually |
Why your team should own the product outcome
Give a team a business outcome and you have given them something they cannot move alone. Revenue depends on sales, pricing, marketing, and support. When it moves the wrong way, the honest answer is often that it was not the product, and the team learns to point at other departments.
Give a team a traction metric and you have quietly told them the solution is already decided. "Increase template usage" assumes templates are the answer. There is no discovery left to do, only tuning.
The product outcome is the one the team can actually move and still has room to be creative about.
Use traction metrics only when you are tuning a solution you have already validated, not when the intent is to find new ones. A team improving a known checkout flow is well served by a conversion number. A team asked to grow retention is not.
Leading and lagging indicators
Some numbers tell you what is about to happen. Others tell you what already did.
| Leading | Lagging | |
|---|---|---|
| Timing | Moves before the outcome | Moves after the outcome |
| Puts the team in | A position to act | A position to explain |
| Feedback speed | Days | Weeks or months |
| Examples | Booked sales calls, free trial signups, first-week saves | 90-day retention, quarterly revenue, churn |
| Risk | May not actually predict the thing you care about | Confirms too late to change anything |
A team measured on 90-day retention gets one honest read per quarter. Any change they make takes three months to evaluate, by which point four other things have changed too. That team cannot learn at the speed it works.
The job is to find a leading indicator that genuinely predicts the lagging one. Sonja Martin's team at tails.com went through exactly this: 90-day retention was too slow to experiment against, so they moved to 30-day, then to 5-day. The 5-day number gave them week-over-week feedback, but they had to keep checking that it still predicted the 90-day result, because a leading indicator that has stopped predicting is worse than none. It is confident and wrong.
A leading indicator is a hypothesis about causation, not a fact. Confirm it tracks the lagging measure you care about, and re-check that link periodically. Otherwise you will improve a number that has quietly stopped mattering.
Getting to a good outcome when you are handed a feature
You will often be handed an output and asked to deliver it. Working backward is a normal move, not a confrontation.
- Ask what business result the request is meant to produce. "What would be different for the business if this worked perfectly?"
- Ask which customers it is for, specifically.
- Propose the product outcome that connects the two, and offer it as the measure instead.
- Keep the feature on the table. You are not refusing to build it, you are proposing how to tell whether it worked.
Setting an outcome should be a two-way negotiation between the product leader and the trio. Leadership carries business context the team lacks. The team knows what is measurable and achievable in the product. Neither side can set a good outcome alone.
Anti-patterns
- Too many outcomes at once. Every one of them seems equally important, which means none of them focuses anything.
- Ping-ponging. Switching outcomes before the current one has had time to move, so nothing compounds.
- Individual instead of team outcomes. Set team outcomes. Individual ones split the trio into three people pulling in different directions.
- Outputs wearing outcome clothing. "Launch the new dashboard by Q3" is a deadline for an output, however it is phrased.
Write down your team's current goal. Ask whether you could achieve it perfectly and still have created nothing of value for a customer. If yes, it is an output.