◀ Course contents Part 1 · Module 1-03

Business Outcomes & Product Outcomes

Connect the features you ship to the results that matter

Shipping features feels like progress, but features are just outputs. This guide draws the chain from outputs to product outcomes (a change in user behavior) to business outcomes (company results), and shows which one your team should actually own.

Ready?

1

Outputs vs. Outcomes

A team finishes the quarter having shipped fourteen features. Every one landed on time, every one was well built, and the retro is genuinely positive. Retention is flat. Activation is flat. Revenue is flat.

Nothing went wrong with delivery. What went wrong is that nobody ever asked what each of those fourteen things was supposed to change.

This is the distinction between an output and an outcome, and it is the most useful one in the whole discipline. An output is something you produced: a feature shipped, a page redesigned, an integration launched. It is entirely within your control, and you can guarantee it by working hard. An outcome is a change in behaviour or in the business: more accounts reaching first value, fewer people abandoning checkout, more customers renewing. It is not within your control — you can only influence it — and no amount of effort guarantees it.

That asymmetry explains why teams drift toward outputs. Outputs are safe. You can promise them, plan them, and be judged fairly on them. Outcomes involve admitting that you might do everything right and still not move the number, which is an uncomfortable thing to put in a plan.

But a roadmap made only of outputs cannot fail visibly, and anything that cannot fail cannot teach you anything either. The useful question for any roadmap item is not “will we ship it?” but “what will be different if we do, and how will we know?” If nobody can answer the second half, you are about to spend a quarter producing things.

The test that separates them A chooser. Ask whether hard work alone guarantees the result. If yes it is an output; if no it is an outcome, because outcomes depend on how the part responds. Can you guarantee it by working hard? yes It is an OUTPUT. Real work, fully in your control — and it proves nothing. no It is an OUTCOME. It depends on how people respond, so it can genuinely fail.
This is the whole distinction in one question, and it explains the drift: outputs are safe to promise, so roadmaps fill with them. Anything you can guarantee cannot tell you whether you were right.

Everyday example, the gym

"I went to the gym 20 times this month" is an output, an activity you did. "I can now run 5k without stopping" is an outcome, the change that activity produced. You can hit the gym 20 times and get nothing if you do it wrong. The gym visits only matter because of the change they're supposed to cause. Same with shipping features: the feature isn't the win; the change it creates is.

What you build

Output

A feature, screen, or release. "We shipped a redesigned dashboard." Easy to count, easy to fake progress with.

What changes

Outcome

A measurable change in behavior or results. "Users now complete setup 30% more often." What actually matters.

A team that measures itself only by outputs is a feature factory, shipping endlessly, learning nothing about whether any of it helped.

Shipped, and nothing moved

A team closed a quarter having shipped fourteen features, every one on time. Retention, activation and revenue were all flat. Nothing had gone wrong with delivery — the roadmap had simply never been asked which number each item was supposed to move, so nothing on it was accountable to an outcome.

Quick check

Which of these is an outcome, not an output?

2

Business vs. Product Outcomes

A team improves the report builder until people build far more reports. Usage doubles. It is a real, measurable, hard-won change in behaviour. Renewals do not move at all.

What happened is that they achieved a product outcome that was not attached to a business one — and these are two different things that are easy to confuse because both are “outcomes”.

A product outcome is a change in what users do: more people activate, sessions get longer, fewer tickets get filed. A business outcome is a change in the health of the company: revenue, retention, cost, market share. Product outcomes are closer to your work and move sooner. Business outcomes are what the company actually needs and move later.

The trap is assuming the first automatically produces the second. In the report-builder story it did not, for a mundane reason: the people building reports were analysts, and the people deciding on renewal were executives who only ever read them. Serving the first group beautifully did nothing for the second, and the connection had never been examined because it felt obvious.

So the working method is to state both, and state the link between them out loud. “If more accounts reach first value in week one, more of them will still be paying in month three, because early value is what makes the renewal conversation easy.” Written that way, someone can disagree with the middle clause — which is the whole point. The link between a product outcome and a business outcome is an assumption, not a fact, and it is the part most worth arguing about before the quarter starts.

Product outcome and business outcome Three stacked layers: the output the team shipped, the product outcome it is meant to cause, and the business outcome that depends on that. Two arrows connect them, and each arrow is labelled as a claim: that shipping it makes people use it, and that using it makes them renew. Output we shipped the report builder 1 · shipping it makes people use it Product outcome people build far more reports 2 · using it makes them renew Business outcome more customers renew
Arrow 2 is where the report-builder story failed: usage doubled and renewals did not, because the people building reports were not the people deciding on renewal. A product outcome only reaches the business if the same person is on both ends of the arrow.

Everyday example, the farmer

A farmer wants money from the harvest, that's the business outcome. But they can't reach out and grow the cash directly. What they can control is watering, healthy soil, and pulling weeds, the product outcomes. Do those well and the harvest (and the money) follows. Product teams are the farmer: you tend the behaviors you can influence, and the business result grows from them.

Company result

Business outcome

Money-and-company metrics: revenue, retention rate, cost, market share. What the business ultimately cares about.

Behavior change

Product outcome

A change in what users do that drives the business result: activation rate, weekly active use, tasks completed.

Teams can rarely move a business outcome directly, but they can move user behavior. That's why product teams own product outcomes.

When the product outcome is not the business outcome

A team improved a report-building flow until people built far more reports. Usage rose sharply. Renewals did not move at all, because the customers renewing were not the ones building reports — they were the executives reading them. A real product outcome that was attached to the wrong business one.

Quick check

A product team is told to "increase annual revenue by 20%." Why is a product outcome a better target for them?

3

Connecting the Chain

Everything a team does forms a chain: we ship something, that changes what users do, and that changes something the business cares about. Written out, it looks like this — we shipped the onboarding checklist → more accounts reach first value → more of them are still paying in month three.

The chain looks like a plan. It is more accurate to see it as a set of claims, because the arrows are doing all the work and none of them are guaranteed.

The first arrow says the thing you built will change behaviour. It might not — people may not notice it, or may not want it. The second says the behaviour change will reach the business. It might not, for exactly the reasons in the previous lesson. Each arrow is an assumption, and a chain is only as strong as its weakest one.

This is why so many roadmap arguments feel unresolvable. Two people are usually not disagreeing about whether to build the thing; they are disagreeing about one specific arrow, without either of them saying which. Drawing the chain forces that into the open, and the conversation gets noticeably shorter.

It also tells you what to measure and in what order. If you only measure the last link, you will wait months to learn nothing useful — you will know it did not work, but not which arrow broke. Measuring each link means that when the chain fails you can point at the join, and the next attempt starts from evidence rather than from the beginning.

From output to business outcome Three stacked layers connecting what a team ships to what the business gets: the output, the product outcome it is assumed to cause, and the business outcome assumed to follow from that. Two arrows link them, and each is labelled as the assumption it is: that the checklist gets accounts to first value, and that reaching first value keeps them paying. Output we shipped the onboarding checklist assumption · the checklist is what gets them there Product outcome more accounts reach first value assumption · reaching it is why they keep paying Business outcome more of them are still paying in month three
The arrows between these are assumptions, not facts. Most roadmap arguments are really disagreements about one of those arrows, which is much easier to settle once it is drawn.

Everyday example

A recipe is a chain too: buy these ingredients, follow these steps, get this dish. If the dish is wrong, the useful question is which step failed — and a cook who only tastes at the end knows the meal is bad without knowing what to do differently tomorrow.

Output → product outcome

The feature should change a behavior. Redesigned setup → more users finish setup.

Product outcome → business outcome

The behavior should drive results. More users finishing setup → higher retention → more revenue.

Leading vs. lagging

Product outcomes are leading indicators (move early, predict). Business outcomes are lagging (confirm late).

The arrow that was never checked

The chain read: ship a checklist, more accounts reach first value, more of them renew. The first two links held. The third did not, because the accounts that renewed had a champion inside the company and the ones that churned did not — first value was real but never the constraint. The chain was right in form and wrong in its middle assumption, which is the only place a chain can fail.

Quick check

Weekly active use (a product outcome) starts climbing this month; annual retention (a business outcome) won't be measurable for a year. What does this show?

4

Setting Good Outcome Targets

The first one cannot be argued with, which sounds like a strength and is the problem. Nobody will object to it, nobody can tell you it has been missed, and at the end of the quarter the team will have a genuine disagreement about whether it was achieved — with no way to settle it.

A strong target has three properties, and it is worth checking all three. It is behavioural — it describes something people do, not something they feel. It is measurable with a number you already collect or can start collecting today. And it has a baseline and a deadline, because “raise retention” without a starting point is not a target, it is a direction.

The word “happier” fails all three at once. There is no behaviour named, no instrument that reads it, and no threshold that would count as success. It is a sentiment dressed as a goal.

Setting a real number feels riskier, and it is — you can now miss it in public. That is exactly why it works. A target you can miss is the only kind that changes what a team does in week three, when there is still time to react. A target you cannot miss changes nothing until the retro, by which point the quarter is spent.

What makes a target usable A checklist contrasting strong targets with weak ones. Strong targets name a behaviour, carry a number with a baseline and a deadline, and can be missed. Strong target Weak target Names a behaviour people do Has a number you already collect States a baseline and a deadline Can visibly be missed Describes a feeling ("happier") Has no instrument that reads it Gives a direction with no start point Cannot fail, so never resolves
Every item on the right is comfortable, which is why weak targets survive planning meetings. A target you can miss is the only kind that changes what a team does in week three.

Everyday example, the thermostat

"Make the house feel nicer" is a bad target, vague, unmeasurable, and everyone pictures something different. "Set the living room to 21°C by 6pm" is a good one, it's a specific, measurable thing you can actually control with the dial in front of you. A good product outcome is the thermostat setting, not the fuzzy wish. Name the behavior, put a number on it, and make sure your team's hand is on the dial.

Weak target vs. strong target

Weak: "Make users happier." Not behavioral, not measurable, not clearly ours.

Strong: "Increase the share of new users who complete a first project in week one from 22% to 40%."

The strong one names a behavior, gives a number, and sits squarely within what the team can move.

Weak target, strong target

A quarter opened with "make users happier" and ended in an argument about whether it had been achieved. The following quarter opened with "raise week-four retention from 24% to 30%", and the same team disagreed about tactics but never about whether they were winning.

Quick check

Which is the strongest product-outcome target for a team to own?

Drill what you learned
Scenario 1 easy

At your quarterly review, your team proudly reports it shipped 14 features. No one mentions whether any metric moved.

What's the problem with this report?

Scenario 2 easy

Leadership sets your team's sole objective as "increase gross revenue by 15% this year."

How should you reframe it for your team?

Scenario 3 easy

Your redesigned onboarding is live. Signups look flat, but the share of new users who finish setup jumped from 20% to 45% this week.

How do you read this?

Scenario 4 easy

Your roadmap for next quarter is a list: "Build dark mode, build SSO, build a new dashboard, build export-to-PDF." A stakeholder asks, "What will be true for users that isn't true today?"

What does that question expose?

Scenario 5 easy

A designer proposes tracking "number of buttons clicked" as the team's success metric for a new feature.

What's the risk with this metric?

Scenario 6 medium

Your team's product outcome — "weekly active teams" — is climbing nicely. But revenue is flat and the CFO is unhappy.

What's the most likely explanation to investigate first?

Scenario 7 medium

To hit a "daily active users" target, a growth team adds a daily push notification that pulls people in for a two-second glance. DAU rises 25%. Retention and satisfaction don't budge.

What happened to the metric?

Scenario 8 medium

Two teams pitch their quarterly targets. Team A: "Ship the mobile app." Team B: "Raise the share of users active on mobile from 10% to 30%."

Which target is stronger and why?

Scenario 9 medium

An executive says: "I don't want to hear about 'activation rate.' Just tell me the revenue impact of every feature, every sprint."

What's the reasonable pushback?

Scenario 10 medium

Your team target is "improve user satisfaction." Six weeks in, no one can agree on whether you're making progress.

What test does this target fail?

Scenario 11 hard

A PM sets the target: "Reduce world hunger through our food-delivery app." The team feels inspired but paralyzed.

What test does this fail?

Scenario 12 hard

Marketing celebrates: "We got 100,000 app downloads this month!" But weekly active users barely moved.

How do you interpret the download number?

Scenario 13 hard

Your team hit its product outcome (activation up 15 points) but leadership asks: "So what? Prove it mattered to the business."

What's the right way to answer?

Scenario 14 hard

A leader wants the team held accountable to annual net revenue retention as its only quarterly goal — a metric that won't visibly move for many months.

What's the practical problem?

Scenario 15 hard

Your team keeps a scoreboard of "story points completed per sprint" and treats rising points as the main sign of success.

What trap is the team in?

Drilled it. Now apply it to a real situation.

Put it to work
From lesson 1

Amazon writes the press release first

Amazon

Amazon's "working backwards" process requires a team to write the press release and the FAQ for a product before it is built — describing the customer, the problem, and what is different for them once it exists. Only then does anyone discuss how to build it.

The ritual exists for one reason: a press release that says "we shipped a thing" is obviously unpublishable, so the format forces the team to state an outcome or admit they cannot.

What does writing the press release first actually force?

Select all that apply — there are 3 to find.

From lesson 2

The quarter the product team hit every target and the business did not

A payments platform

Product's quarterly outcome was "reduce time-to-first-transaction for new merchants from 9 days to 3". They got it to 2.8. Every dashboard is green.

The business outcome above it was "increase processed volume from new merchants by 20%". It rose 4%.

Work out where the chain broke.

  1. Step 1 of 3

    Both numbers are real. What does the gap between them tell you?

    The chain is: ship faster onboarding → merchants transact sooner → more volume from new merchants. One of those arrows is weaker than assumed.

  2. Step 2 of 3

    Investigation shows merchants now start transacting on day 3, but their monthly volume is unchanged. Which arrow failed?

    So the product outcome was achieved, the business outcome was not, and both facts are consistent.

  3. Step 3 of 3

    What should have happened before the quarter started?

    A product outcome that cannot arithmetically reach the business outcome above it is a plan that has already failed.

From lesson 3

Three levels of the same goal

A language-learning app

Leadership has set a company outcome for the year: grow subscription revenue by 30%. Your squad owns the lesson experience. Between those two things sits a chain nobody has written down.

Put these in order, from the business outcome down to the output your squad actually ships.

Drag the rows, or use the arrows, then check.

  1. Subscription revenue grows 30% this year The business outcome. Money, at the top, owned by the company rather than any one squad.
  2. More free learners convert to paid, because more of them reach the point where the product has clearly helped The mechanism connecting the two — the sentence that says why anything your squad does could matter to revenue at all.
  3. Share of new learners completing a 7-day streak rises from 18% to 28% The product outcome: a number your squad can move, close enough to the work to be attributable and close enough to the mechanism to matter.
  4. Ship streak repair, lesson reminders and a shorter first lesson The outputs. Necessary, entirely within the squad's control, and worth nothing on their own — they are bets on the outcome above them.
From lesson 4

A target nobody could fail

An internal tools team

Four outcome targets, proposed for next quarter. Two of them are not targets at all — one because nothing could count as missing it, and one because it is an output wearing an outcome's clothes.

Proposed quarterly targets
#Target
1Improve the deployment experience for engineers
2Cut median time from merge to production from 47 min to under 15 min
3Ship the new pipeline UI, the rollback button and the status page
4Reduce failed deploys requiring manual rollback from 12% to under 5%

Which of these are usable outcome targets?

Select all that apply — there are 2 to find.

Notification