Outputs vs Outcomes

A product team ends the year with a party. Forty features shipped. Every sprint delivered, every deadline met, the board of tickets a wall of green. One awkward detail: nothing moved. Not revenue, not customer satisfaction, not retention — flat, all of it. So here's the question this entire module orbits: was that team productive?

By the end of this video, you'll be able to tell outputs from outcomes on sight, explain the trap called the feature factory, and use the one reframe that modern organizations are built around: outputs are hypotheses.

An output is what you produce. Features shipped, posts published, forms deployed, tickets closed, reports written. Outputs are countable, visible, and comfortably within your control — which is exactly why teams love measuring them.

An outcome is the change your work creates — for a customer or for the business. A problem solved. A behavior changed. A number that matters, moved. Outcomes are harder to count, arrive later, and are never fully in your control. Which is exactly why teams avoid measuring them.

Read those two sentences back and you can already see the trap forming.

That trap has a name: the feature factory. A feature factory is any team — in any industry — that measures itself by how much it ships rather than what changes. The machinery runs beautifully: backlogs groomed, sprints completed, velocity charts climbing. And it can run for years while the thing that actually matters stays flat, because everyone is being graded on motion.

Nobody builds a feature factory on purpose. It happens because outputs are easy to see and outcomes are not, so organizations drift toward celebrating what's visible. Our forty-feature team wasn't lazy or unskilled. They were answering the question they were asked — "how much did you ship?" — instead of the question that mattered: "what changed?"

Let's run one example through the full chain, from a hospital rather than a software company — because this logic belongs to everyone.

A clinic team deploys a new patient scheduling form. That's the output: a thing now exists that didn't before. Within a month, average patient wait time drops by twenty minutes. That's the outcome: a change in the patients' world. Over the following quarter, patient satisfaction climbs and the clinic serves more people with the same staff. That's the level beyond outcome — call it impact: the organization-level results that outcomes add up to.

Output, outcome, impact. The form, the shorter wait, the healthier clinic. Notice the direction of certainty: you fully control the output, you influence the outcome, you hope about the impact. Modern teams aim their goals at the middle of that chain — outcomes — because that's where control and meaning overlap.

Now the reframe that ties this to everything you've learned. In the modern way of working, an output is never the goal — it's a bet about the goal. The honest sentence hiding inside every backlog item is: "We believe that shipping X will move Y."

We believe the new form will cut waiting time. We believe the blog series will bring qualified leads — and there's the marketing version of our story: posts published are outputs; more qualified leads are the outcome those posts were always secretly betting on.

Say the quiet part out loud — "we believe X moves Y" — and something powerful happens: shipping stops being the finish line and becomes the experiment. You ship, then you look. Did Y move? If yes, double down. If no, you just learned something a feature factory never learns, because a feature factory never looks.

This is also why last module's durable teams matter so much. A project team disbands when the output ships — nobody's left in the room when the outcome arrives, or doesn't. A durable team that owns a product over time is still there to see whether Y moved. Organizing around long-lived products and outcome goals instead of temporary projects and output goals — that's what people mean by the product model, and you now understand its entire logic in one sentence.

You might think "done" means produced — coded, published, deployed, delivered. That's understandable; it's how nearly every workplace talks. Actually, in the way of working you're learning, done starts to mean usable and valuable — remember the Definition of Done from Module 2: not "I finished my part," but "it works and someone can benefit." This module sharpens that further: the deepest version of done is "the change we bet on actually happened." Hold all three levels; you'll use them next lesson.

Three things to keep. One: outputs are what you produce; outcomes are what changes — and teams drift toward counting outputs because they're easier to see. Two: the feature factory is high output, flat outcomes, running on the wrong question. Three: outputs are hypotheses — "we believe shipping X moves Y" — and durable teams exist so someone's still there to check.

If outcomes are the destination, the backlog is the route map — and the backlog has a native language designed to smuggle outcomes into every single line item. It's called the user story, and its most important words are its last three. Next lesson.