Outcome vs output: how to rewrite a feature roadmap as outcomes

Outcome vs output in one sentence: an output is what the team ships, and an outcome is the change in customer behavior that the output is meant to cause. Impact sits one level higher: it is the business result that follows when enough customers change what they do. A roadmap made of outputs is a list of features with dates, and everyone reads it as a list of promises. A roadmap made of outcomes names the customer problems the team will solve and the numbers that will show they are solved.

A quick example

CatChow, an online pet-food shop, had "Reorder reminders" on its roadmap for the second quarter. The team shipped on time. In the first month the system sent 1,900 reminder emails, and 46% of them were opened: 874 opens. The roadmap line turned green.

Nobody had written down what the reminders were for. When Sofia, the junior PM, asked, the answer was: new customers buy once and don't come back. Of the 2,000 people who place a first order each month, only 38% place a second one within 60 days. Two months after the launch the share was still 38%.

The output was delivered. The outcome did not happen. The roadmap could not show the difference, because the line said "reminders" and not "more first-time buyers come back".

Output, outcome and impact

Here are the three levels for four of CatChow's feature requests. The outcome is what each feature is meant to cause, not a guarantee.

The arithmetic, worth doing before the work starts:

• Reminders: $2{,}000 \times (0.45 - 0.38) = 140$ extra second orders; at an average order of 30 dollars that is $140 \times 30 = 4{,}200$ dollars a month.
• Checkout: 3,200 new shoppers reach the payment step and 2,000 pay, so 37.5% drop out. At 30% the shop gets $3{,}200 \times 0.70 = 2{,}240$ first orders, 240 more.
• Tracking: 320 fewer tickets at 6 minutes each is 1,920 minutes, or 32 hours.

A note on terms: many teams, and our course, use "outcome" for both the customer and the business level and call the top one a business objective. Separating impact is useful because the team controls less at each level: impact also depends on prices, competitors and the season. That is why a team's roadmap lines work best at the outcome level.

Why a feature roadmap turns into a list of promises

A feature with a date reads as a commitment. Brandon, CatChow's key account manager, saw "Bulk ordering, April" on the roadmap and promised it to PurrPoint, a chain of vet clinics. Ian, the CEO, repeated the dates to the board.

The estimate comes before the problem. Lucy, the tech lead, had to estimate "bulk ordering" before anyone knew what the clinics struggle with.

Done means shipped. Last year CatChow shipped all 14 features on its roadmap, on time, and churn did not move. A team that counts releases and never checks what changed is a feature factory.

A roadmap states direction; exact dates and scope belong in a release plan. The lesson on what a product roadmap is and isn't covers that boundary.

How to rewrite a roadmap item as an outcome

1. Ask "why does that matter?" until the answer describes a customer doing something differently. Bulk ordering → clinic admins stop ordering by phone → prescription diets don't run out.
2. Name who changes and what they do differently. "Partner clinics always have the diets they need in stock."
3. Add a signal, a baseline and a target. Stock-outs per month: from 6 to 1.
4. Delete the feature from the sentence. If the sentence still makes sense, you have an outcome.
5. Check that the team can move the number within a quarter or two.

If you can't answer step 1 from your desk, talk to customers: good customer interview questions reveal the problem behind a request.

CatChow's roadmap, before and after:

The features don't disappear; they move under the outcome as options. For the first line the options were reminders, a one-click reorder button and a sampler of small packs. Interviews showed that new buyers weren't forgetting to reorder: many had bought a large bag their cat refused to eat. Reminders could not fix that; a sampler could.

On a roadmap such outcomes become themes, next to the vision, business objectives, timeframes and a disclaimer: see the five components of a roadmap.

How to pick the metric

• Use a signal you can already see or can start tracking this month. Without a baseline a target is a guess.
• Stay close to the behavior and fix the time window. The share of new buyers who reorder within 60 days responds to the team's work within a quarter; annual revenue does not.
• Plan how you will know the work caused the change. If the share rises from 38% to 45% in December, was it the sampler or the holiday season? Hold the change back from a random part of new customers and compare the groups. More in correlation vs causation.

Common mistakes

An output dressed up as an outcome

"Launch loyalty points in Q2 to increase engagement" contains a feature, a date and a fuzzy word. Ask who would do what more often. If the honest answer is "the feature will be live", it is an output.

An outcome the team cannot influence

"Grow company revenue by 30%" is a fine business objective, but no single team moves it alone, so the team cannot tell whether its work helped. Break it down to a number the team affects directly: repeat purchases, checkout completion, clinic reorders.

Vanity metrics

10,000 app downloads, 1,900 reminders sent, 874 emails opened. Such numbers measure how far the output spread, not whether the problem got smaller. Ask: could this number go up while the customer's problem stays the same? CatChow's reminders showed that it can.

"But when will feature X ship?"

The question is fair: whoever asks it has a contract, a campaign or a board update to plan. Answer that need.

1. Ask what depends on the date. Brandon needs something PurrPoint can rely on, not a feature name.
2. State the outcome and where it stands now.
3. Commit to what is near and checkable: a pilot, a review date, the day you will know more.
4. Give distant work a timeframe, not a date: Now, Next or Later. Keep exact dates for fixed external events.

Sofia's answer to Ian:

Bulk ordering is one of three options for the same goal: partner clinics don't run out of prescription diets and can reorder without phoning us. Today they run out about 6 times a month; the target is 1. The work is in Now. A pilot in two PurrPoint clinics starts within three weeks, and after a month of the pilot I'll show you the stock-out numbers. Then we'll pick the option that works and set a rollout date for all 14 clinics.

The answer names the goal, its current number and two near checkpoints.

Key takeaways

• Output is what the team ships, outcome is what customers do differently, impact is what the business gains.
• A feature with a date is read as a promise; an outcome with a metric is read as a goal.
• To rewrite a roadmap line, ask why it matters, name who changes, add a baseline and a target, and drop the feature.
• Choose metrics the team can move and that can't grow while the problem stays.
• Answer "when?" with near-term commitments, a timeframe and the date you will know more.

FAQ

What is the difference between outcome and impact?

An outcome is a change in customer behavior: more first-time buyers reorder. Impact is the business result of that change: more revenue from repeat orders. Impact depends on many things outside one team's work.

Is a key result in OKR an outcome?

A good one is. "Raise the share of new buyers who reorder within 60 days from 38% to 45%" is an outcome. "Launch the loyalty program by June" is an output written in the key-result slot.

Can an outcome-based roadmap have dates?

Yes, where they are real: a trade show, a contract deadline, a pilot that starts next month. For everything else use broad timeframes and keep detailed dates in the release plan.

Learn it hands-on

The free lesson Outcomes over outputs turns CatChow's spreadsheet of feature requests into outcomes step by step, with exercises on spotting outputs in disguise and a practice task checked by AI. It is part of the free course Outcome-Based Product Roadmaps.