Outcome vs output: how to rewrite a feature roadmap as outcomes
Outcome vs output in product management: what each one means, where impact fits, and how to rewrite feature roadmap items as measurable outcomes.
By Sergey BruhPublished 9 min read
Outcome vs output in product management: what each one means, where impact fits, and how to rewrite feature roadmap items as measurable outcomes.
By Sergey BruhPublished 9 min read
A free course for PMs and marketers: short lessons, real product data and exercises with instant feedback.
Start the free course9 min read
What an outcome-based roadmap is, how it differs from a feature roadmap, its five components and a one-page example you can adapt.
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.
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".

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:
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.
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.
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.
"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.
"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.
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.
The question is fair: whoever asks it has a contract, a campaign or a board update to plan. Answer that need.
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.
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.
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.
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.
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.