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.

In practice, this looks like: before taking on a task, write one sentence — "We'll know we solved the problem when..." This short exercise often reveals that the problem is formulated vaguely — because agreeing on a metric is hard exactly where there's no clarity in the problem itself. In that case it's better to return to the problem statement and sharpen it, rather than move forward with a fuzzy metric.

Example: report export

Let's look at how metric selection plays out in a concrete situation — and why the obvious candidates usually don't work.

Setup: an analytics team at a B2B service spends several hours every Friday manually transferring data from the system into Excel and assembling a summary report for management. A product engineer hears this pain, understands the problem, and takes on building an "Export to Excel" button.

The feature is ready. What to measure? The first instinct is to count button clicks. Convenient: the event is logged, data is visible from day one. But a click doesn't equal a solved problem. The analyst might click, open the file, find an inconvenient date format — and still spend an hour on manual fixes. The "button clicked" metric would record "success" in the face of failure.

The second candidate — the number of unique users who downloaded the file in a week. Slightly better, but the same problem: downloading a file doesn't say whether it replaced the manual work or landed next to it as one more step.

The third option — survey the analysts two weeks after launch. Honest, but slow and unreliable: surveys give self-assessment, not fact. People tend to answer what seems right rather than what they actually do.

In the end they chose something different: the share of Fridays on which the analyst did not create a duplicate manual summary spreadsheet. The proxy metric was counted from file storage — if by Friday evening an export file appeared without a "manual" file alongside it, the week counted. The guardrail metric was the average report preparation time by self-report once a month, to avoid optimizing only the file count at the expense of actual time.

After a month the primary metric showed 62%. Not bad, but 38% were still doing it manually. They went to investigate: it turned out the date format in the export didn't match what the management template spreadsheet expected. Fixing the format took a day and brought the metric to 89%. Without an outcome focus the feature would have been marked closed after the first deploy, and the source of dissatisfaction would have stayed invisible.

Notice the structure of the choice: first reject the convenient metrics (clicks, downloads), then formulate a proxy metric as close as possible to real behavior, and add a guardrail. The guardrail is what would have caught any case where the primary metric grew at the expense of report quality rather than its speed.

This structure is worth reproducing every time: list of candidates → test each one ("can it be gamed without solving the problem?") → pick the primary → guardrails. Takes half an hour, saves a month of work going nowhere.

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.

The fourth — a proxy metric becomes the real goal. A proxy is an approximation: there's no direct sensor, so you measure something that correlates with what you need. The trouble starts when the proxy stops being treated as an approximation and starts being grown for its own sake. This is a variant of the third trap, with an added step — the lost understanding of what the proxy was measuring indirectly in the first place.

What this means in practice

In practice, work with outcome metrics breaks down at several typical points. Here are the most common, along with what the mistake looks like from the inside:

Common mistakes:

  • The metric is chosen after shipping. When the feature is already in production, admitting it moved nothing is psychologically hard — and the metric quietly gets picked to confirm a decision already made. Formulate it before the work begins, while there's no temptation to justify the time spent.
  • Too short a time horizon. "Let's look after the first week" for slowly changing behavior will give noise, not signal. Agree upfront on how long to wait for movement and what counts as a meaningful change.
  • One metric with no guardrails. Any metric can be optimized at the expense of an adjacent one: registration speed at the expense of data quality, number of exports at the expense of whether anyone uses the file. One or two guardrail metrics nearby keep the balance.
  • Forgetting to revisit the metric. Six months later the product changes, user behavior changes — but the metric stays the same and now describes not the user's pain but the team's habit of reporting on that number.
  • Confusing a process metric with an outcome metric. "Development speed increased" or "we're deploying more often" — those are process metrics: they describe team efficiency, not benefit to the user. An outcome metric is always about what changed on the user's side, not the development side.

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.

A simple way to build this into the work rhythm: two or three weeks after a release, ask yourself one question — "what changed for the user?" — and answer it with data, not a feeling. If there's no answer, it means the metric wasn't set in advance or wasn't looked at afterward.

What's next

A chosen outcome metric works in tandem with two neighboring steps: it defines what and how much is worth building, and it is checked after the release and first contact with reality. And the original problem statement is where the metric is derived from: without it, the metric hangs in the air.