The team reports: twelve features shipped this quarter. It sounds like success. But the only honest question is whether the user is better off — whether the pain that started it all is gone. Often there's no answer, because no one measured it. They measured something else — how much was done, not what changed.
This is where the line between output and outcome runs. Output is what you shipped: features, screens, lines of code. Outcome is what changed for the user: the job started getting done, a step vanished, an error stopped happening. Product thinking measures the outcome. Output is merely a means, and mistaking the means for the goal is the most common way to run fast in the wrong direction.
Output measures you, outcome measures the user
Output is convenient to count, because it's entirely under your control and visible right away: a feature is either in production or it isn't. That's why it's so tempting — it gives a sense of progress. But it describes your activity, not the benefit. You can ship ten features and move not a single user's job.
Outcome is inconvenient in exactly the opposite way: it's about the user, it shows up not right away, and it depends on more than just you. Yet it alone answers the question of what all this is for. "A seller loads a catalog in an evening instead of a week," "the cart abandonment rate dropped," "support stopped getting messages about this step" — these are outcomes. They describe the world after the problem was solved, not the volume of work done.
How to choose an outcome metric
An outcome metric is derived straight from the named problem. If the problem is "a new seller can't quickly stand up a catalog and doesn't launch in time for the season," then the metric is the share of new sellers who stood up a catalog within a reasonable time, or the time from registration to first sale. Not "import is built," but "sellers launch."
A good metric passes three checks. It's tied to the user — it describes their behavior or their result, not your output. It moves within a foreseeable time — otherwise you can't steer by it. And it's hard to game without genuinely solving the problem: if a metric can be "improved" by a trick that doesn't help the user, it's a bad metric.
It's often useful to keep one outcome metric as the primary one and a couple of guardrails alongside it, so you don't optimize one thing at another's expense. Time to first sale can be "improved" by letting in a junk catalog — so alongside it you watch card quality or returns. The primary metric sets the direction; the guardrails keep you from cutting corners.
Traps of measurement
The first is vanity metrics: numbers that are pleasant to show and always go up, but say nothing about a solved problem. Total registrations, number of features, overall page views. They create an illusion of movement. The test is simple: if a metric went up and you can't say who is better off, it's vanity.
The second is measuring what's convenient for the report rather than what matters. Output falls into this trap first: it's easy to count, so that's what gets reported. Ease of measurement shouldn't decide what to measure.
The third is optimizing the wrong thing. Any metric, once it becomes a goal, starts deforming behavior: the team honestly pulls toward exactly that metric. If the metric is chosen wrong, you'll get exactly what you asked for and not what you wanted. That's why a metric is chosen carefully and revisited if it has started living apart from the benefit.
Keeping the outcome in focus alone
When one person carries the whole path, the outcome metric is their steering wheel and their conscience. There's no one on the sidelines to ask "did it actually get better?" — they have to ask it themselves, both before shipping and after. Before — to decide whether to build at all: what outcome do we expect and how will we know it has arrived. After — to close the loop: to see whether the metric moved, and if it didn't, not to celebrate a shipped feature.
This same thing saves you from overload. When it's clear which outcome matters, it becomes visible that many tasks don't move it — and they can be left undone. The outcome metric turns an endless list of "would be nice to build" into a short list of "this will move what matters." Without it, a product engineer measures themselves by the volume shipped and burns out, not knowing whether they helped anyone.