Module 1: Outcomes Over Outputs

What is an output?

Next →

Overview

Before you can tell an output apart from an outcome, you need to define the first one precisely, without extra adjectives. An output is something your team produced and delivered: a feature in production, a redesign published, a dashboard users can already open, a button that already works. The simplest test for recognizing an output: can you point to it in a changelog, in a deploy, in a demo? If yes, it's an output. It's concrete, it's verifiable, and —this is key— it's entirely your team's responsibility: if you decide to build it and you build it well, the output exists. No one else decides whether it shows up or not.

This lesson isn't here to say outputs are bad. Quite the opposite: without outputs there's nothing. You can't generate value for a user without building something first. The problem —which you'll see with full clarity in lesson 4— isn't having outputs, it's measuring yourself solely by them, as if the work ended the moment of deploy.

How this connects to the module. This is the first of the two pieces lesson 1 builds: you saw the full list of Mercado's 12 shipments, and that list, as it stands, is a list of outputs: things the team delivered, countable, verifiable, each with real engineering effort behind it. In lesson 3 you'll define the counterpart —the outcome—, and in lesson 4 you'll cross the two definitions over those same 12 shipments to see how many were only output. Everything you learn here is half of that count.

An analogy: the plates on the table

Let's continue with lesson 1's dinner. "I served five courses" is a sentence about outputs: it precisely describes what you did. You can count them, you can photograph them, you can put them on a list for your host résumé: starter, main course, two sides, dessert. No one can dispute that the five courses exist; they're there, served, on the table.

But notice what that sentence does not say. It doesn't say whether the main course was cooked just right. It doesn't say whether one of your guests is vegetarian and couldn't eat anything. It doesn't say whether the conversation flowed or whether everyone left early. "Five courses served" is a complete description of your effort, and an empty description of its effect. That's exactly the nature of an output: it measures what you did, not what it achieved.

Now transplanted to Mercado: "we shipped the recommendations carousel" is an output. It precisely describes the team's work —design, code, QA, deploy—. But it doesn't say whether anyone clicked on a recommendation, whether those recommendations led to a purchase, or whether the carousel simply takes up space on the page without anyone noticing it. The output is the plate on the table. What happens next —whether someone ate it and was satisfied— is a different matter, and that matter is the subject of lesson 3.

Worked example: the report that only knows how to count

Let's model exactly what an output can and can't tell you. We write a function outputReport that takes a list of shipments and returns the only thing an output, by definition, can offer: how many there are and what they're called.

// "Output" view: the only thing this report knows is that 12 things shipped.
function outputReport(shipments) {
  return {
    count: shipments.length,
    names: shipments.map((s) => s.name),
  };
}

const shipments = [
  { name: 'Checkout page redesign (visual refresh)' },
  { name: 'Product recommendations carousel' },
  { name: 'Seller analytics dashboard' },
  { name: 'Product reviews and ratings' },
  { name: 'Search filters by price range' },
  { name: 'One-click reorder button' },
  { name: 'Wishlist and favorites' },
  { name: 'Dark mode' },
  { name: 'Social share buttons' },
  { name: 'Saved payment methods' },
  { name: 'Real-time inventory sync for sellers' },
  { name: 'Simplified 3-step checkout' },
];

const report = outputReport(shipments);
console.log('=== Output report: Mercado quarter ===\n');
console.log('Features shipped: ' + report.count);
report.names.forEach((n) => console.log('  - ' + n));
console.log('\nWhat this report CANNOT answer: how many of these 12 things');
console.log('changed a user behavior or a business metric.');
console.log('An output, by definition, does not carry that answer.');

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

=== Output report: Mercado quarter ===

Features shipped: 12
  - Checkout page redesign (visual refresh)
  - Product recommendations carousel
  - Seller analytics dashboard
  - Product reviews and ratings
  - Search filters by price range
  - One-click reorder button
  - Wishlist and favorites
  - Dark mode
  - Social share buttons
  - Saved payment methods
  - Real-time inventory sync for sellers
  - Simplified 3-step checkout

What this report CANNOT answer: how many of these 12 things
changed a user behavior or a business metric.
An output, by definition, does not carry that answer.

Notice, carefully, the shape of the object outputReport returns: it only has count and names. It has no impact field, no metricMoved, nothing that speaks of results, because an "output" object doesn't have that data: it never did, because it isn't part of its definition. It's not that the report is incomplete by oversight; it's that you're looking at the correct half of the problem, and that half, alone, is blind to the result by construction. This is the technical reason, not just a rhetorical one, why "we count shipped features" is never a success metric: the data structure that describes an output doesn't even have a place to store whether it worked.

Recognizing an output in any context

The definition generalizes beyond software, and it's worth seeing it in other trades so you recognize it effortlessly:

  • In construction, an output is building a wall. It's verifiable (the wall is there or it isn't), and it's entirely the bricklayer's responsibility.
  • In a restaurant, an output is a plate served. It's on the table or it isn't.
  • In sales, an output is a call made or a proposal sent. It happened or it didn't.
  • In software engineering, an output is a deploy to production: the feature exists, it runs, a user could use it.

In all four cases, the question "did it happen?" has a binary, verifiable answer at the moment it happened. That's the distinguishing mark of an output: it resolves in the present, with what you control. The question "did it work?" —whether the wall doesn't fall in the first tremor, whether the customer came back, whether the proposal closed, whether the user used the feature and it changed something— gets resolved afterward, with data that depends on people who aren't you. That second question belongs to the outcome, and it's the subject of lesson 3.

A short way to say it, one that will serve you the rest of the module:

Output  = what YOU fully control: did it get built and shipped?
Outcome = what the WORLD decides afterward: did anything change because of it?

Common mistakes

Counting shipped features as if it were "productivity". What happens: a team, or an individual engineer, reports their performance in number of merged PRs, closed tickets, or features shipped per sprint, and that number becomes, without anyone explicitly deciding it, the bar for success. Why it happens: it's the easiest data to get —any Jira board has it— and it climbs predictably as long as there's work in the queue. How to spot it: if you're asked "how did this sprint go?" and your answer is a number of things delivered, with no mention of what changed for a user, you're in this trap. How to fix it: an output counts work, not value. It's still useful for planning capacity and seeing if the team is unblocked, but it should never, by itself, be the definition of a quarter's success. That requires the other half —the outcome— which arrives in the next lesson.

Believing "it's in production" means "it's finished". What happens: the team celebrates the deploy as the end of the work, closes the ticket, and moves on to the next backlog item without ever looking at that feature again. Why it happens: the deploy is the most visible, most celebrated milestone of the development cycle —there's a notification, a Slack channel, maybe an emoji—. How to spot it: no one on the team can answer, two weeks after launch, whether that feature changed anything. How to fix it: the deploy is the end of the output, not the end of the work. It's still necessary to check whether it generated the expected outcome, and that check should be as scheduled as the launch itself.

Using the word "impact" to describe an output. What happens: a report or a performance review contains the phrase "this feature had a lot of impact", but when you ask which metric moved, the real answer is "we used it internally for the demo" or "the design turned out really polished". Why it happens: "impact" sounds like an outcome, and using the word feels like you've already proven it, even though there's no data behind it. How to spot it: you're asked for numeric evidence of that "impact" and you don't have it, you only have the feature working. How to fix it: reserve the word "impact" (or "outcome") for when you have a real number —a metric, a before and an after—. If you don't have it yet, the honest description is "we shipped X"; that's an output, and it's fine to say so while the rest gets checked.

Exercises

Exercise 1 — Output or not output. For each statement, say whether it describes an output (something the team controls and produced) or whether it's actually, without realizing it, describing something else:

  • (a) "We launched the price filter in search."
  • (b) "30% more users completed a search with a filter this week."
  • (c) "The seller dashboard has been in production since Tuesday."
  • (d) "Sellers update their inventory 40% faster since the dashboard exists."
See solution
  • (a) Output. It describes something the team did and fully controls: the feature exists, it shipped. It says nothing about whether anyone used it or whether anything changed.
  • (b) Not an output — it's an outcome. It describes a measurable behavior change ("30% more completed a search"), something that depends on what users decided to do, not on what the team built. It's a preview of the next lesson's topic.
  • (c) Output. Again: "it's in production" is exactly the mark of an output — verifiable in the present, controlled by the team.
  • (d) Not an output — it's an outcome. "40% faster" is a real behavior change among sellers, measured after launch. The dashboard (c) is the output; this sentence (d) is the result that output may, or may not, have produced.

The quick rule: if the sentence describes something the team did, it's an output. If it describes something someone else started doing differently as a consequence, it's an outcome — and that's exactly the subject of lesson 3.

Exercise 2 — Extend the report. Without changing outputReport's purpose (it should only count and list, nothing about results), add a byCategory field that groups the shipment names by whether they mention "checkout" in the name or not. Without running anything, write what console.log(outputReport(shipments).byCategory) would print for the list of Mercado's 12 shipments (use the criterion: the name contains the word "checkout", case-insensitive).

See solution

One possible implementation:

function outputReport(shipments) {
  const checkout = shipments.filter((s) => s.name.toLowerCase().includes('checkout'));
  const other = shipments.filter((s) => !s.name.toLowerCase().includes('checkout'));
  return {
    count: shipments.length,
    names: shipments.map((s) => s.name),
    byCategory: {
      checkout: checkout.map((s) => s.name),
      other: other.map((s) => s.name),
    },
  };
}

And what it would print, for Mercado's 12 shipments:

{
  checkout: [
    'Checkout page redesign (visual refresh)',
    'Simplified 3-step checkout'
  ],
  other: [
    'Product recommendations carousel',
    'Seller analytics dashboard',
    'Product reviews and ratings',
    'Search filters by price range',
    'One-click reorder button',
    'Wishlist and favorites',
    'Dark mode',
    'Social share buttons',
    'Saved payment methods',
    'Real-time inventory sync for sellers'
  ]
}

The point of the exercise: you can group, count, and organize outputs a thousand different ways —by category, by date, by team— and it will still be, at bottom, the same information: what got done. No reorganization of this list tells you whether "Saved payment methods" moved GMV. For that you need data this structure doesn't even have: whether a metric changed. That arrives in lesson 3.

Exercise 3 — The limit of the question. A coworker tells you: "if we count outputs carefully enough —by category, by days of effort, by technical complexity— eventually we'll be able to infer the impact." Do you agree? Justify your answer in two or three sentences.

See solution

No. No amount of additional detail about the output —its category, how much it cost to build, how technically complex it was— adds information about the result, because that information lives somewhere else: in user behavior and in business metrics, after launch. You can describe an output with total precision (what it is, when it shipped, how much it cost) while knowing absolutely nothing about whether it worked. They're two independent questions, and the only way to answer the second one is to measure after launch, not to describe before launch in more detail. This is exactly why the definition of outcome (lesson 3) needs new data —a metric that changes over time— and not a "more detailed" version of the output.

Summary and next step

In this lesson you precisely defined output: something your team produced and delivered, verifiable in the present, entirely under your control. With the dinner, and with outputReport run over Mercado's 12 shipments, you saw that an output describes effort, not effect — and that this isn't an accidental limitation of the report, but the very nature of the data: an output's structure has nowhere to store whether it worked. And you saw that the output isn't the villain: without outputs there's nothing to build; the problem, which arrives in lesson 4, is measuring yourself only by them.

Before moving on you should be able to: give a one-sentence definition of output; recognize an output in any trade, not just software; and explain why "counting outputs in more detail" never substitutes for measuring the result.

Lesson 3 defines the counterpart this report was missing: what, exactly, is an outcome? There you'll see how a real change gets expressed —with a before, an after, and a threshold that separates a genuine signal from the normal noise of any business metric.

Resources

← PreviousGuide introduction: from shipping features to moving metrics with judgmentNext →What is an outcome?