What is an outcome?

Overview

You already have half of the equation: an output is something your team produced and fully controls. This lesson defines the other half, the one that really decides whether that effort was worth it. An outcome is a measurable change in someone's behavior, or in a business metric, that happens as a consequence of what you shipped. It's not "how well-written the code turned out" nor "how much the team liked the design": it's a number that moved, compared against a previous number, and that keeps moving beyond what normal noise would explain.

The short definition you'll use for the rest of the guide, taken almost verbatim from Josh Seiden, the author who popularized the term: an outcome is a change in human behavior that drives a business result. Notice the three pieces of that sentence, because all three are mandatory: (1) there's a change — a before and an after, not a still photo; (2) the change is in human behavior — someone does something different from what they used to do; (3) that change drives a business result — it isn't just any change, it's one that matters to Mercado as a company. If any of the three pieces is missing, you don't have an outcome yet; you have, at best, an output with a nice story wrapped around it.

How this connects to the module. In lesson 2 you saw that an output —"we shipped the recommendations carousel"— by definition carries no data about the result. This lesson names and shapes that missing data: the outcome. With both definitions complete, lesson 4 will cross them over Mercado's 12 shipments and count, for the first time with real numbers, how many of those shipments produced a genuine outcome and how many stayed pure output. And lesson 7 will use this same idea —a change with a before and an after— to start asking why a feature should move a metric, not just whether it did.

An analogy: the guests who left satisfied

Back to the dinner. You already saw that "I served five courses" is an output: it describes your effort, it says nothing about the result. That same dinner's outcome is a different sentence, very different in nature: "the guests left satisfied, and three of them have already asked when the next one is".

Notice the differences, because they're exactly the three pieces of the formal definition. First, there's a change: before the dinner, those guests had no formed opinion about coming back to your house; afterward, three of them actively want to come back. Second, it's a change in behavior: it's not that "they felt good" in the abstract —that's hard to verify—, it's that they did something: they asked about the next date. Third, that change matters to you as a host: it's the signal you actually wanted when you threw the dinner; nobody throws a dinner to be able to say "I served five courses", they throw it so people have a good time and want to come back.

And here's the nuance that makes the analogy useful: if you ask a guest "did you have a good time?" and they say "yes, it was lovely" out of politeness, that's not yet a reliable outcome — it's an opinion, easy to inflate, hard to verify. But if three people, without you asking, spontaneously ask when the next dinner is, that's a genuine behavior change, something they did, not something they said to be nice. The distinction between "a stated opinion" and "a real behavior" is, almost exactly, the distinction between a vanity metric and a real outcome — a topic the metrics guide takes up in depth; here it's enough that you feel it.

Worked example: did the number move, or is it just noise?

An outcome isn't just any change in a number: every business metric has natural variation from one day to the next, from one week to the next, without anyone having done anything. For a change to count as an outcome, it has to move beyond that normal noise. Let's model that idea with a function outcomeDelta, and run it on two of Mercado's shipments: one suspected of having moved checkout, and one suspected of not.

// outcomeDelta(): compares a metric before/after a shipment and says whether
// it truly moved, beyond the normal noise of a business number.
function outcomeDelta({ metric, before, after, noiseThreshold }) {
  const deltaAbs = +(after - before).toFixed(2);
  const moved = Math.abs(deltaAbs) > noiseThreshold;
  return { metric, before, after, deltaAbs, moved };
}

const savedPaymentMethods = outcomeDelta({
  metric: 'checkout conversion',
  before: 22.4,
  after: 24.1,
  noiseThreshold: 1,
});

const recommendationsCarousel = outcomeDelta({
  metric: 'checkout conversion',
  before: 22.4,
  after: 22.5,
  noiseThreshold: 1,
});

function printOutcome(name, r) {
  console.log(
    name + ' -- ' + r.metric + ': ' + r.before + '% -> ' + r.after + '% (delta ' +
    (r.deltaAbs >= 0 ? '+' : '') + r.deltaAbs + ' pts) => ' +
    (r.moved ? 'OUTCOME (moved)' : 'no outcome (noise)')
  );
}

printOutcome('Saved payment methods', savedPaymentMethods);
printOutcome('Product recommendations carousel', recommendationsCarousel);

What to expect. When you run the file with Node, the output is exactly this:

Saved payment methods -- checkout conversion: 22.4% -> 24.1% (delta +1.7 pts) => OUTCOME (moved)
Product recommendations carousel -- checkout conversion: 22.4% -> 22.5% (delta +0.1 pts) => no outcome (noise)

Both features shipped. Both are, without a doubt, outputs. But when you look at the same metric —checkout conversion, the percentage of visits that end in a purchase— with a before and an after, the result splits clearly. Saved payment methods moved conversion by 1.7 percentage points, above the noise threshold we defined (1 point): that's an outcome. Product recommendations carousel barely moved 0.1 points, within the range any normal week produces without anyone having changed anything: that, with this evidence, is not an outcome — it's indistinguishable from having done nothing.

Notice the noiseThreshold parameter: it's not a decorative detail, it's the piece that prevents this lesson's most common mistake — confusing any movement with a real signal. No business metric is a perfectly flat line when nothing is happening; it goes up and down a little every day for reasons that have nothing to do with your feature (the day of the week, another team's promotion, the weather). The threshold is the honest way of saying "I need the change to be bigger than that normal wobble before I call it an outcome." (How you choose that threshold with statistical rigor —significance, confidence intervals— is exactly the territory of product-metrics-and-experimentation-guide; here, the point is that the threshold exists and that without it, any noise can be disguised as success.)

What genuinely makes something an outcome

Review the three pieces of the definition against the Saved payment methods example, because all three are present and that's why it's a legitimate outcome:

1. There's a real change     ->  22.4% became 24.1%, and it's not noise (beats the threshold).
2. It's behavior              ->  more people actually finished paying (not an opinion).
3. It matters to the business ->  checkout conversion is directly tied to GMV.

And compare it with a sentence that sounds like an outcome but isn't: "the team was really happy with the new checkout." There's no metric there, no before and after, and the "behavior" that changed is the team's, not a user's or the business's. It's missing, at minimum, piece 2 and piece 3. That confusion —a sentence with the shape of an achievement but not the three pieces— is so common that we'll dedicate all of lesson 6 to it: how to tell a good outcome apart from a vague or disguised one.

An important clarification before moving on: this lesson teaches you to recognize that a change beat the noise, with a simple threshold to make the idea tangible. It does not teach you to decide with statistical rigor whether that difference is significant —that requires hypothesis testing, sample sizes, confidence intervals, and it's exactly what product-metrics-and-experimentation-guide covers. Here the goal is more modest and more urgent: to get you out of the habit of looking only at whether something shipped, and start always asking "and the metric, did it move?"

Common mistakes

Confusing an output dressed up as a metric with a real outcome. What happens: someone says "the page had a lot of impact" or "we launched the page and it did really well", but when you ask for the number, what's there is an opinion or, at best, an activity metric that wasn't there before because the page wasn't there before either —so "it got traffic" isn't comparable to anything—. Why it happens: a sentence shaped like an achievement feels like an achievement, even when there's no real before and after behind it. How to spot it: ask yourself "compared to what?" — if there's no baseline before the shipment, you can't compute a deltaAbs, and without a delta there's no outcome, just an isolated measurement. How to fix it: every outcome needs an explicit comparison: the metric before shipping, the metric after, and the delta between the two. If you can't fill in those three boxes, you don't have an outcome yet — you have, at most, a promise waiting to be checked.

Calling any movement an outcome, without looking at the noise. What happens: the metric ticks up a little the week after launch, and the team celebrates it as if the feature had caused it, without asking whether that same wobble happens normally for no reason at all. Why it happens: any uptick feels like confirmation, and nobody wants to be the one who dampens the enthusiasm. How to spot it: you saw it executed — recommendationsCarousel rose 0.1 points, a real movement, and the model still marked it no outcome (noise), because it didn't beat the threshold. How to fix it: always demand a threshold, even a simple one like this example's. "It went up" isn't enough; "it went up more than it normally does while doing nothing" is.

Measuring the wrong metric for the question that actually matters to you. What happens: an outcome gets declared over a metric that's easy to move but isn't connected to real value —for example, "visits to the cart page went up"— without verifying that this metric relates to what the business actually cares about (GMV, in Mercado's case). Why it happens: some metrics are easier to move than others, and it's tempting to report the one that did go up, even if it isn't the one that matters. How to spot it: the metric you're reporting changed, but when someone asks "and what effect did that have on GMV?", nobody has a clear answer. How to fix it: before declaring victory, verify that the metric you chose is genuinely connected to the business result Mercado cares about — the relationship between "what you measure" and "what matters" is, precisely, the central criterion of lesson 6.

Exercises

Exercise 1 — Complete the three pieces. For the statement "the seller dashboard looks really polished visually, the design team is proud", identify which of the three pieces of the outcome definition (a change with a before/after, human behavior, a business result) are present and which are missing.

See solution

None of the three pieces are present. There's no change with a before and after (nothing is compared, it's a still photo of how it looks today). There's no human behavior that changed (the design team's pride is an internal opinion, not something a seller did differently). And there's no declared connection to a business result (did the polished dashboard lead sellers to update their inventory more? To sell more? It's not stated). It's a perfectly valid sentence about the quality of the work, but it is not, in any way, an outcome. To turn it into one, you'd need something like: "since the redesign, 25% more sellers update their inventory weekly" — now all three pieces are there.

Exercise 2 — Compute the verdict. Use outcomeDelta mentally (or copy it and run it) for this case: the seller retention metric (active seller retention) was at 68% before the analytics dashboard launched, and 69.2% after. The team defined noiseThreshold: 1.5 for this particular metric (because it historically varies quite a bit month to month). What's the verdict?

See solution

deltaAbs = 69.2 - 68 = 1.2. Since Math.abs(1.2) isn't greater than 1.5, the verdict is no outcome (noise), even though the number did go up. This exercise shows something important the module repeats on purpose: "it went up" is not the same as "it's an outcome". The noise threshold isn't a decorative arbitrary number — it changes the final verdict, which is why the right threshold for each metric (narrower for a stable metric, wider for one that varies a lot on its own) is a real decision, not a number set just for the sake of it. How to choose that threshold with rigor is, again, the territory of the metrics guide; here what matters is that you never declare an outcome without having asked the question.

Exercise 3 — Design the missing "before". Mercado's team wants to declare an outcome for "One-click reorder button" (buying again something you already bought before, with one click). They propose the metric repeat purchase rate (percentage of purchases that are of a product already bought before). What do they need to have, at minimum, BEFORE they can run outcomeDelta on this case? List the concrete data that's missing.

See solution

They need, at minimum: (1) the repeat purchase rate value before launching the button (the baseline — without this, there's no possible before); (2) the same metric's value after, measured with enough time elapsed for behavior to settle (launching and measuring the very next day would probably capture only initial curiosity, not a real habit change); and (3) a noiseThreshold defined before looking at the result — decided from that metric's historical variation, not adjusted after seeing the number so it "gives an outcome". That last point is subtle but important: if you choose the threshold after seeing the result, you might unconsciously tune it to confirm what you want to see. The threshold, like an outcome's targets, gets set before looking at the data.

Summary and next step

In this lesson you defined outcome with the three pieces that make it real: a change with a before and an after, a human behavior that was modified, and a connection to a result the business cares about. With outcomeDelta executed, you saw that "it went up a little" isn't the same as "it's an outcome" — you need to compare against a noise threshold, and outcomeDelta showed the exact difference between Saved payment methods (+1.7 points, a real outcome) and Product recommendations carousel (+0.1 points, indistinguishable from noise). And with the dinner, you felt the difference between a stated opinion ("it was lovely") and real behavior (asking when the next one is) — the same filter that separates a vanity metric from a real outcome.

Before moving on you should be able to: give the definition of outcome with its three pieces; explain why a number going up isn't always an outcome; and tell, in any given sentence, whether it describes an output, an outcome, or neither.

With both definitions complete —output in lesson 2, outcome in this one—, lesson 4 does what this module promised since lesson 1: cross the two over Mercado's full 12 shipments and put an exact number on the build trap. You'll see how many of those shipments were pure output, and you'll understand, with data, why GMV barely moved over the whole quarter.

Resources

• Josh Seiden, "Outcomes Over Output" — outcomesoveroutput.com. The source of the definition used in this lesson: "a change in human behavior that drives a business result." In English.
• Amplitude, "What Makes a Good vs Bad North Star Metric" — amplitude.com/blog/good-bad-north-star-metric. Goes deep into how to choose a metric that truly reflects value, not just activity — the natural bridge to lesson 6 of this module. In English.
• Marty Cagan (Silicon Valley Product Group), "Outcomes Are Hard" — svpg.com/outcomes-are-hard. Why truly measuring outcomes —and not just output— demands a genuine change in a team's discipline. In English.