Outcome Over Output
Shipping eleven things is not the same as changing one number that matters.
It is the last Thursday of the quarter and you are building the roadmap review deck. You have eleven shipped items. Bulk invoice import, a redesigned settings page, three new webhook events, a Slack integration. The slide looks great. Then somebody senior asks what changed for customers because of it, and the room goes quiet, because nobody knows. That silence is the whole lesson.
An output is a thing your team produced. A feature, a page, a migration, an API. An outcome is a change in human behaviour that you can observe, and that the business cares about. Outputs are easy to count and easy to promise. Outcomes are hard to count and impossible to promise honestly, which is exactly why teams drift toward counting outputs.
Output goal
- Ship bulk invoice import by March.
- Deliver 14 roadmap items this quarter.
- Launch the mobile app.
- Done means merged and deployed.
Outcome goal
- Cut the time to send a month of invoices from an hour to ten minutes.
- Raise the share of accounts that invoice on time.
- Get finance teams doing their monthly close without exporting to a spreadsheet.
- Done means the behaviour moved and stayed moved.
Notice what the right column does to your options. If the goal is bulk invoice import, there is exactly one acceptable answer and your job is project management. If the goal is cutting the time to send a month of invoices, bulk import is one candidate. So is remembering last month's line items. So is a template that carries forward. So is fixing the three validation errors that make people redo the upload. You get to pick the cheapest path to the same result, and sometimes the cheapest path is not a feature at all.
Worked example
Ledgerline, a B2B invoicing tool
The team was asked for bulk CSV import. Before building it, they watched six finance managers do a monthly run. Five of them were not blocked by entering invoices. They were blocked because the tool silently rejected any client whose billing address was missing a postcode, so they would upload, get a count mismatch, and spend forty minutes hunting the bad row. The team shipped inline row level errors and a fix-and-resume flow in nine days. Time to complete a monthly run dropped hard. Bulk CSV import stayed unbuilt for another two quarters, and nobody missed it.
The Ledgerline team could only find that because their goal was stated as an outcome. A feature goal would have sent them straight to the CSV parser, and they would have shipped a faster way to hit the same wall.
Eleven things shipped, one number watched
Why teams slide back to output
- Outputs are inside your control. Outcomes are not, and being measured on something you do not fully control feels unfair.
- Outputs make a clean commitment. Sales can sell a date. Nobody can sell a probability.
- Output progress is visible weekly. Outcome progress is lumpy and often flat for a while.
- A feature that ships is a story with an ending. An outcome that moves is a number that someone else might explain away.
These are real pressures, not character flaws. The way through is not to ban roadmaps or refuse dates. It is to make the outcome the headline and the output the footnote. You still say what you plan to build. You just say what it is for, in a form that can be checked, and you stay willing to change the build if the check fails.
Three questions that convert an output into an outcome
- Who behaves differently?
- Name a specific person doing a specific job. Not 'users'. 'The finance manager at a 40 person agency doing the month end run.' If you cannot name them, you are guessing.
- What do they do now, and what do you want them to do instead?
- Both halves have to be observable. 'Exports to a spreadsheet, then re-uploads' becomes 'completes the run inside the product'. Feelings like 'is delighted' do not count.
- Why does the business care?
- Connect the behaviour to something real: retention, expansion, support cost, sales cycle. If you cannot draw that line in one sentence, the outcome may be true but not worth a quarter.
One caution. Outcome thinking is not a licence to be vague. 'Improve the customer experience' is worse than 'ship bulk import', because it cannot be wrong. A good outcome is narrow enough that you could fail it in public and everyone would agree you failed. If your goal cannot be failed, it is not a goal, it is a mood.
Start small. Take the next item on your roadmap and write one sentence underneath it: when this works, someone will do X instead of Y. Show that sentence to your engineers. If they cannot picture the person, rewrite it. If they can, you have just given them the freedom to propose something cheaper than what you asked for, which is usually where the good ideas come from.
Quick check
Why does an outcome goal give a team more useful freedom than a feature goal?
The takeaway
State goals as a change in what a named person does, and let the feature be one candidate answer rather than the answer.
Try this tomorrow
Take the top three items on your current roadmap and write one sentence under each: after this ships, [specific person] will do [X] instead of [Y]. Bring the three sentences to your next standup and ask the team whether any of them could be achieved more cheaply.
Answer the check above, then bank the day.
Where this comes from
- Inspired, second edition, Marty Cagan
- Escaping the Build Trap, Melissa Perri
- Radical Focus, Christina Wodtke
Product Thinking is one of six tracks. These lessons summarise and build on the work above, they do not reproduce it. Buy the books, they are better.