Outcomes over outputs

An output is something the team ships: a feature, a release, a campaign, a document. An outcome is the change that output is supposed to cause, in customer behavior or in business results: fewer subscribers running out of food, more clinics reordering without calling, a higher renewal rate. Output is necessary, but on its own it says nothing about whether anything got better.

Look at the top rows of CatChow's request spreadsheet: bulk ordering for clinics, a mobile app, loyalty points, reorder reminders, a new checkout, dark mode. Every one of them is an output: something the team would build.

A quick way to tell them apart is the output test: can you tick it off while no customer does anything differently? Then it's an output. “Send reorder reminders” is done the moment the emails go out. “Subscribers reorder before they run out” is done only when people actually behave that way. Outputs are what we do; outcomes are what changes because we did it.

A feature factory is a team that measures success by how many features it ships and never checks what they changed for customers or the business. It can deliver everything on time and move nothing. CatChow's CEO, Ian, has exactly that awkward fact for the board: last year the team shipped all 14 features on the roadmap, on time, and churn didn't move. None of the 14 was aimed at churn.

Output roadmaps make this easy. “Build the mobile app” counts as done when the app is in the store, whether or not anyone orders through it. An outcome counts as done only when the number moves.

Doesn't that make outcomes riskier for the team? You could build everything and still fail. But the team was already failing; it just couldn't see it. With outcomes you find out early whether a solution works, and you're free to try a different one instead of defending the first. On-time delivery shows that the team produced its outputs, nothing more.

How do you turn “bulk ordering for clinics” into an outcome? Start with what the customer actually said. Brandon, CatChow's key account manager, called PurrPoint, a chain of 14 clinics, and learned that their admins order by phone every week, one clinic at a time; orders get mixed up, and twice last month a clinic ran out of a prescription diet and had to send pet owners elsewhere.

Now ask “why does that matter?” one rung at a time:

1. Bulk ordering for clinics (the output).
2. Admins stop ordering by phone, clinic by clinic.
3. Orders arrive correct and on time, so diets don't run out.
4. Clinics stop sending pet owners to other suppliers.
5. CatChow grows and keeps its vet clinic channel (the business objective).

The bottom rung is an output, the middle rungs are outcomes for the clinics, and the top is the business objective they serve. Stop where the team can still influence the result: that's usually the outcome worth putting on the roadmap.

A good outcome names who changes, what they do differently and how you'll measure it. And it doesn't name a solution.

To measure it, pick a signal you can already see or can start tracking, then add a baseline and a target. For the clinics: “Prescription-diet stock-outs in partner clinics drop from 6 a month to 1.” Bulk ordering might get there. So might automatic reorders, or a simple shared order sheet.

Try it on another spreadsheet row. Research shows subscribers' biggest problem is forgetting to reorder and running out; the spreadsheet says “Build a mobile app”. The weak rewrites keep the solution (“launch the app by June”), stay vague (“the best app in the market”) or count adoption of the output (“10,000 downloads”). The strong one names the change: “raise the share of subscribers who get their next delivery before running out from 70% to 85%”. If an app gets there, great; if a reminder does, cheaper still.

An outcome is useless if it falls into one of four traps, and a sentence with a “why” in it can still fall into several. Take “Launch loyalty points in Q2 to increase engagement.” It has a why, but also a feature, a date and a fuzzy word: what would “engagement” look like in the data? Who does what more often?

The four traps:

• Can't be measured: “make customers happier” has no signal you could check.
• An output in disguise: “launch the loyalty program by the end of Q2” is still a delivery with a deadline.
• Prescribes the solution: “reduce churn by adding a pause button” fixes one possible fix in advance.
• Too broad for one team: “double CatChow's valuation” or “grow company revenue by 30%” are fine business objectives, but no single team can move them alone.

The fixes mirror the traps: name a signal, drop the deadline-plus-feature, take the solution out of the sentence, and break a company-wide number down into a change one team can actually influence.

Behind every favorite idea is a change someone hopes for. Find that change before the idea goes anywhere near the roadmap. CatChow's founders love loyalty points; such programs are usually meant to bring customers back sooner or to stop them drifting to competitors.

If the only answer is “every competitor has one”, that's a copy, not a goal. Ask what those competitors' customers actually do differently because of it. That change is the outcome worth writing down.

Then apply a simple test: write the outcome without mentioning the feature at all. If the sentence still makes sense, you've found the real goal. “More first-time buyers come back for a second order” works without the word “points”; “customers use their points” doesn't.

As with any good outcome, finish with a baseline and a target: today 38% of first-time buyers reorder within 60 days. Points then become just one bet on raising that number.

When a client wants a feature and a date in the contract, offer the outcome instead. PurrPoint wants something it can put in the contract, and Brandon needs an alternative to “bulk ordering by April”.

The clinics don't really care about “bulk ordering”. They care about never running out of prescription diets and not spending an hour on the phone. CatChow can commit to working on exactly that and to reporting progress, without promising a specific feature by a specific month.

A vague “we're working on it” won't sell, though. To become an offer, the outcome needs two things: a number both sides will track (stock-outs, orders placed without a call) and a concrete first step (a pilot in two clinics within weeks, with their admins trying early versions).

Clients tend to trust a team that is visibly solving their problem more than one that only promises a feature. And if the pilot shows a cheaper solution works, nobody has to renegotiate a contract.

An outcome-based roadmap rests on a deal: the team commits to the outcome and, in return, chooses the output. Leadership says what must change and by how much; the people closest to the work decide how.

At CatChow, the tech lead, Lucy, sees the clinic outcome and asks to explore two or three options instead of estimating “bulk ordering” now. That's the deal at work. If bulk ordering turns out expensive and a shared order sheet would cut stock-outs just as well, a feature commitment forces the team to build the expensive thing anyway; an outcome commitment lets it switch.

The deal also moves estimates to after the problem is understood, so they're smaller, more honest and attached to a solution already compared with alternatives.

How it fits together: outputs are bets on outcomes. The why ladder finds the outcome, the four traps check it, and the deal frees the team to pick the best bet. Next, Anatomy of a product roadmap puts outcomes on one page as themes.