What makes an outcome good?

Overview

You already know an outcome is a measurable change in someone's behavior that matters to the business, and in lesson 5 you accepted that recognizing one is also your job. One step is missing: not every sentence that sounds like an outcome actually is one. "Improve the user experience" has the shape of an important goal, but it says nothing you could audit six weeks later. This lesson gives you a concrete criterion —three questions, not a gut feeling— for telling a good outcome apart from a vague, disguised, or simply useless one as a guide for work.

A good outcome has to pass three tests at once: it names a concrete metric (not "the experience", but checkout conversion); it declares a direction and a magnitude of change (not "improve", but "go from 22% to 26%"); and it connects to real value for the user or the business, not just an internal team activity. If a proposal is missing any of the three, it's not an actionable outcome yet — it is, at best, a good intention waiting for someone to turn it into something measurable.

How this connects to the module. In lesson 3 you defined what an outcome is in general; here you sharpen your aim to recognize the good ones among the ones that just look like it. This matters especially after lesson 4: Mercado's team didn't fail for lack of intention — several of the 10 pure-output items probably had, in some document, a sentence that sounded like an outcome ("improve conversion with recommendations"). The problem is that sentence never passed this lesson's three tests, and that's why nobody could audit it afterward. Lesson 7 follows this thread: even a good, well-defined outcome also needs a declared mechanism explaining why the feature should move it.

An analogy: the thermometer and the counted pills

Imagine a doctor who, at the end of every visit, proudly reports: "I gave the patient three pills." It's a real, verifiable fact —they counted the pills, they administered them—, but it doesn't answer the question that actually matters: did the fever go down? Another doctor, instead, uses a thermometer: they measure the temperature before the pill, they measure it after, and report "the fever went from 39° to 37.2°." Both doctors did the same real work of administering the pills. The difference is in what they decided to measure: one measured their own activity (pills given), the other measured the patient's actual condition (the fever).

A good outcome is the thermometer, not the counted pills. And here's the nuance this lesson adds: not just any number works as a thermometer. If the doctor instead measured "how many times the patient asked for water" —a real number, measurable, with a before and after— they still wouldn't be measuring what matters: asking for water isn't reliably connected to the fever. A good outcome needs all three things at once: a number (not an impression), that moves in a declared direction (not "improved", but "went from 39 to 37.2"), and that number genuinely connected to the condition you actually care about (the fever, not how many times they asked for water). This lesson's three questions are, literally, how you choose the right thermometer before treating the patient.

Worked example: the three-question checklist, executed

Let's build isGoodOutcome, a checker that applies the three tests —named metric, declared direction, connection to real value— to a set of typical proposals from a Mercado planning meeting, some good and some vague.

// isGoodOutcome(): a candidate outcome needs all three things: a named
// metric, a direction/magnitude of change, and a connection to real value
// for the user or the business (not just team activity).
function isGoodOutcome(candidate) {
  const reasons = [];
  if (!candidate.hasMetric) reasons.push('does not name a metric');
  if (!candidate.isDirectional) reasons.push('does not state a direction or magnitude of change');
  if (!candidate.tiedToValue) reasons.push('does not connect to value for the user or the business');
  return { statement: candidate.statement, good: reasons.length === 0, reasons };
}

const candidates = [
  { statement: 'Improve the checkout experience', hasMetric: false, isDirectional: false, tiedToValue: true },
  { statement: 'Raise checkout conversion from 22% to 26% this quarter', hasMetric: true, isDirectional: true, tiedToValue: true },
  { statement: 'Launch the new seller dashboard', hasMetric: false, isDirectional: false, tiedToValue: false },
  { statement: "Raise the app's average rating from 3.8 to 4.3", hasMetric: true, isDirectional: true, tiedToValue: true },
  { statement: 'Have the team feel more productive', hasMetric: false, isDirectional: false, tiedToValue: false },
];

console.log('=== Is this a good outcome? ===\n');
candidates.forEach((c) => {
  const r = isGoodOutcome(c);
  console.log('"' + r.statement + '"');
  console.log('  verdict: ' + (r.good ? 'GOOD OUTCOME' : 'NO -- ' + r.reasons.join('; ')));
  console.log('');
});

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

=== Is this a good outcome? ===

"Improve the checkout experience"
  verdict: NO -- does not name a metric; does not state a direction or magnitude of change

"Raise checkout conversion from 22% to 26% this quarter"
  verdict: GOOD OUTCOME

"Launch the new seller dashboard"
  verdict: NO -- does not name a metric; does not state a direction or magnitude of change; does not connect to value for the user or the business

"Raise the app's average rating from 3.8 to 4.3"
  verdict: GOOD OUTCOME

"Have the team feel more productive"
  verdict: NO -- does not name a metric; does not state a direction or magnitude of change; does not connect to value for the user or the business

Three of the five proposals fail, and it's worth looking at why each one fails, because they're three different ways of failing. "Improve the checkout experience" is missing the metric and the direction — it's a genuine intention, but nobody could say, six weeks later, whether it was met or not; there's nothing to compare. "Launch the new seller dashboard" fails all three tests at once, and for a reason you already know from lesson 2: it's literally an output ("launch X") dressed up with the tone of a goal — it doesn't say what should change as a consequence of launching it. "Have the team feel more productive" does, on the surface, have something that resembles a metric ("productivity"), but it fails the most important test: it isn't connected to value for the user or the business — it's an internal team condition, and even if true, it tells Mercado nothing about whether checkout converts better or GMV goes up.

The two that do pass —"raise checkout conversion from 22% to 26%" and "raise the rating from 3.8 to 4.3"— share a structure worth memorizing: [direction verb] + [named metric] + [starting value] + [target value]. That structure, by itself, forces all three tests to be met: you can't write a goal like that without naming a metric, without stating a direction, and —if you chose a metric that truly reflects the business, like checkout conversion instead of, say, "number of design meetings held"— without connecting it to real value.

The most common trap: output disguised as a goal

It's worth pausing on the dashboard case, because it's exactly the pattern that produced ten of the twelve pure-output items in Mercado's quarter (lesson 4). A proposal like "launch the seller dashboard" feels like a goal — it has the grammatical shape of one ("we're going to achieve X")—, and that's why it slides through a planning meeting unquestioned. But look at the simple test: if you replace the verb with "ship" or "build" and the sentence still means exactly the same thing ("build the seller dashboard"), it's an output wearing an outcome's clothes. A good outcome, by contrast, can't be rephrased as an output without losing information: "raise checkout conversion to 26%" isn't the same as "build something" — it doesn't say what to build, only what has to happen. That asymmetry is the fastest test you can apply in any meeting: if the goal can be achieved by building anything that meets it, it's an outcome; if the goal can only be met by building that specific thing, it's an output.

Common mistakes

Accepting a metric just because it's easy to get. What happens: someone chooses to measure "visits to the dashboard page" because the data already exists in the analytics panel, without asking whether that metric truly reflects the value being sought (do sellers act on what they see, or do they just come in and leave?). Why it happens: data availability weighs more, at decision time, than actual relevance. How to spot it: you can report the metric easily, but when someone asks "and what effect does that have on GMV or on seller retention?", there's no clear answer — it fails the third test, tiedToValue, even though it passes the other two. How to fix it: before fixing on a metric, trace (even in one sentence) the connection to the result that actually matters. If you can't trace it, keep looking for a better metric, even if it's harder to get.

Declaring direction without magnitude ("improve" isn't enough). What happens: the proposal says "we're going to improve checkout conversion" — it names a real metric, but without saying how much or by when, so any movement, however small, can be reported as success. Why it happens: putting a concrete number feels risky — what if you don't get there? How to spot it: at the end of the quarter, a 0.1-point movement (which you saw in lesson 3 is noise) gets celebrated the same as a 3-point one, because the original goal never specified what counted as success. How to fix it: always include a starting value and a target, even if it's an estimate ("from 22% to something above 24%"). Without that magnitude, there's no way to tell a real achievement from noise — the same problem lesson 3's noiseThreshold solved.

Confusing "measurable" with "connected to the business". What happens: a perfectly measurable metric with a clear direction gets chosen —for example, "number of comments on product reviews"— without verifying that moving it genuinely matters to Mercado as a business. Why it happens: the first two tests (metric, direction) are the easiest to satisfy on paper, and sometimes that's enough for the proposal to feel complete. How to spot it: it passes hasMetric and isDirectional, but when you ask "why this and not another metric?", the answer is vague ("because it sounds good to have more reviews") instead of tracing a connection to GMV, retention, or some real business result. How to fix it: the third test (tiedToValue) is the one that demands the most discipline, which is why it's the one most often skipped. Always insist on completing the sentence "...and this matters to the business because..." before accepting a metric as a bet's outcome.

Exercises

Exercise 1 — Audit three new proposals. Apply isGoodOutcome's three tests (without running the code, reasoning through each one) to these three proposals for Mercado's next quarter:

• (a) "Reduce the product page's load time."
• (b) "Lower cart abandonment from 68% to 55% over the next two months."
• (c) "Increase the number of pull requests merged per week."

See solution

• (a) NOT a good outcome. It names a metric implicitly (load time) but is missing the exact magnitude/direction (reduce by how much, in how much time?) and, above all, doesn't trace the connection to value: a faster load time might raise conversion, but the proposal doesn't say so explicitly — it stays halfway between a technical metric and a business outcome.
• (b) GOOD OUTCOME. It names the metric (cart abandonment), declares the direction and magnitude (68% to 55%) and the timeframe (two months), and connects directly to business value: less abandonment means, almost by definition, more completed purchases and more GMV.
• (c) NOT a good outcome — it's a team activity metric, not one of external value. It clearly fails the third test: more merged pull requests tells Mercado nothing about whether anything improved for a user or the business; in fact, optimizing for this number could even incentivize small, trivial PRs with no relation to real outcomes — the classic mistake of measuring activity instead of results, the same trap from lesson 4 applied to a different number.

Exercise 2 — Fix the vague proposal. Take "Improve the checkout experience" (the first one in the worked example, which failed two of the three tests) and rewrite it so it passes all three. Use a real metric from this guide's vocabulary (checkout conversion, GMV, cart abandonment).

See solution

A valid rewrite: "Raise checkout conversion from 22.4% to 25% next quarter, by reducing the number of steps in the payment flow." Check the three tests: it names the metric (checkout conversion), declares direction and magnitude (22.4% → 25%, within a defined timeframe), and connects to real value (checkout conversion is directly tied to GMV, the metric Mercado truly cares about). Notice the rewrite also starts hinting at a mechanism ("by reducing the number of steps") — that's, previewed here, exactly lesson 7's subject: a good outcome says what should change; the mechanism explains why it should change.

Exercise 3 — The substitution test. Use the test explained in "The most common trap": if a goal can be rephrased as "build/ship X" without losing meaning, it's a disguised output. Apply this test to "Increase active seller retention at 30 days" and to "Launch push notifications for sellers." Which one passes the substitution test (it's a genuine outcome) and which one doesn't?

See solution

"Increase active seller retention at 30 days" passes the test — it can't be rephrased as "build X" without losing information, because it doesn't say what to build: it could be achieved with push notifications, with a better dashboard, with pricing incentives, with improved onboarding, or with several things at once. It's genuinely an outcome: it describes a result, and leaves the path open.

"Launch push notifications for sellers" does NOT pass the test — it's literally an output: the sentence already specifies what to build, not what should change as a consequence. It can be rephrased exactly as "build push notifications for sellers" without losing an ounce of meaning — in fact, they're the same sentence with a different verb. To turn it into an outcome, you'd first have to ask what for those notifications are wanted (to raise retention? so they react faster to orders?), and declare that metric as the goal — the notifications would then correctly become the output built to pursue that outcome, not the outcome itself.

Summary and next step

In this lesson you learned the three-test checklist for recognizing a good outcome: it names a concrete metric, declares a direction and magnitude of change, and connects to real value for the user or the business. With the thermometer and the counted pills you saw why choosing what to measure matters as much as measuring something — not just any number works as a thermometer. And with isGoodOutcome run over five typical Mercado proposals, you saw three different ways to fail: no metric or direction, disguised as an output, or disconnected from real value. You also learned the substitution test: if a goal can be rephrased as "build X" without losing meaning, it's still an output, not an outcome.

Before moving on you should be able to: apply the three tests to any outcome proposal you come across; recognize an output disguised as a goal with the substitution test; and rewrite a vague proposal as a concrete, actionable outcome.

Lesson 7, the last one before the project, closes the module with the question that's still pending: even with a good, well-defined outcome, how do you know that the feature you're building will actually move it? You'll see that declaring the right metric isn't enough — you also need an explicit mechanism connecting the feature to the behavior change you're after.

Resources

• Amplitude, "What Makes a Good vs Bad North Star Metric" — amplitude.com/blog/good-bad-north-star-metric. An extensive treatment of how to tell a metric that reflects real value from one that only measures activity — this lesson's same question, applied to the metric that guides an entire product. In English.
• Josh Seiden, "Outcomes Over Output" — outcomesoveroutput.com. Revisits the formal definition of outcome with examples of well- and poorly-formed goals. In English.