You delivered every feature and nobody's happy
A feature is something you build. An outcome is the difference it makes — and only one of them was ever the point.
Walk into too many companies mid-pivot to “outcome-driven” and you’ll find the same thing: a roadmap that sounds like a transformation but runs exactly as it did before. Leadership saw the problem, read the books and issued the decree — “no more feature factories.” The team, wanting to comply but not given the time and autonomy to invest in real transformation, reaches for a version of compliance that takes an afternoon instead of a quarter. They go down the roadmap and rename everything.
“Build SSO” becomes “Deliver enterprise authentication.” “Add CSV export” turns into “Enable customer data portability.” “Upgrade the search index” blossoms into “Provide a world-class discovery experience.” Every line is a feature wearing a grander name. The roadmap is the same roadmap. The order is the same order. The way they decide what to build hasn’t budged, and neither has the way they’ll — or won’t — know whether any of it worked.
They’ve run find-and-replace on a feature list and called it a transformation.
This isn’t a strawman, and it isn’t rare — it’s the rule. The move from features to outcomes is the most preached idea in product transformation. It’s also the one most often faked. People adopt the vocabulary in an afternoon and skip the part that actually costs something. Then a year later they’ve shipped everything they promised, the burndown charts look beautiful and somehow nobody — not the customer, not the business, not even the team that shipped it — is any happier.
By happy I don’t mean satisfied in some vague, mood-survey sense. I mean the only thing that actually counts: the customer got a real problem solved, and the business got the change it paid to produce. Shipping features guarantees neither. I want to unpack why that is, and what an outcome actually is, because the gap between renaming your features and genuinely working from real outcomes is the gap between a busy year and a year that mattered.
If you’re new, welcome to Customer Obsessed Engineering! I publish about one article each week. Free subscribers can read about half of every article, plus all of my free articles.
What an outcome actually is
There’s a line from General Patton that product people love to quote: “Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” Marty Cagan opens his case against roadmaps with it. A conventional feature roadmap does exactly what the General warned against. It dictates the how — build this, then this, then this — instead of naming the what, the result you actually need, and it quietly smuggles in an assumption: that whoever wrote the list already knows which features will produce that result.1
Cagan’s example is a single innocent-looking line: “integrate PayPal.” Why is it there? Is it because a segment of customers genuinely can’t pay any other way? Because international payments are failing? Because the fees are too high? Because a competitor has it and someone got nervous? Each of those is a different problem, and the roadmap line names none of them. Maybe integrating PayPal addresses the real one; maybe it’s beside the point entirely. With only the feature in front of you, there’s no way to judge whether it’s the right bet — and no way to tell afterward whether it worked. The feature is on the roadmap. The reason is nowhere.2
Here’s the distinction the whole topic hinges on. A feature is something you build. An outcome is the difference that thing makes for a customer or for the business. Josh Seiden, whose Outcomes Over Output is the book on this exact subject, compresses it to one line: an outcome is “a change in human behavior that drives business results.” Cagan and Felipe Castro frame the same idea operationally — an outcome is two inseparable parts: a clear problem to solve and a measure that tells you whether you’ve solved it. “Integrate PayPal” is an output. “Reduce checkout abandonment for international customers” is the beginning of an outcome — and the moment you state it that way, you’ll notice that PayPal is now just one of several ideas you might test, not a foregone conclusion.34
That’s the real shift, and it’s why renaming does nothing. “Deliver enterprise authentication” is still an instruction to build a thing. It never names the problem, so it can never be measured, so the team is right back to being judged on whether they shipped — which is precisely the trap everyone claims to be escaping.
How to write one that holds up
The format I use, the one described in Chapter 2.2 Roadmaps and OKRs of the Delivery Playbook, is deliberately boring: we will [objective] as measured by [key result]. The objective is the problem, stated qualitatively. The key result is the measure, stated in numbers. Force both halves to exist and you make it almost impossible to disguise a feature as an outcome, because a feature has no measure of success that isn’t just “we shipped it.”
The most common way this goes wrong is mistaking the work for the result. I’ve seen this version more times than I can count:
Objective: cut warehouse order processing data-quality errors reported to the support desk.
Key result: implement improved CSV to JSON data intake parser to handle empty, missing and null data values reliably.
Implementing fixes to the parser is an activity. It’s the thing you suspect might reduce errors. It is not evidence that errors went down overall. A real key result names the change in the world you’re after:
Objective: cut warehouse order processing data-quality errors reported to the support desk.
Key results:
support desk data quality issues reduced from over 20 per day to less than 1 per week.
orders that fail on bad warehouse data reduced from current 7% to under 1%.
Notice those measure customer-visible reality, not internal effort. And notice they’re leading indicators where possible — things you can watch move week over week — rather than a single lagging number you only get to read at the end. Teresa Torres draws this line cleanly: a business outcome like revenue or churn is a lagging indicator, mostly outside any one team’s direct control, while a product outcome is a measurable change in user behavior that the team can move now and that leads the business result. So if the outcome you care about is annual recurring revenue, you don’t wait a year to find out how you did. You pick the behaviors that roll up to it — activation, conversion, the support tickets that signal friction — and move those.5
Castro keeps a running list of what clear problems sound like, and it’s worth internalizing the cadence: help customers solve issues without having to contact us; reduce the time for a user to produce their first monthly report; reduce the subscriber churn rate; connect job seekers with more suitable jobs. Every one names a difference in someone’s experience. None of them names a feature. That’s the test.6
Why renaming isn’t enough
If stating an outcome were the whole job, the move would be easy and far more teams would pull it off. Too often, they don’t, and Cagan is precise about why. Working from outcomes only functions when two other things are already in place.7
The first is context. An outcome handed to a team in isolation isn’t enough — the team also needs the bigger picture of where the company is going, which is the job of a genuine product vision. Without it, a team optimizing its little metric can cheerfully march in the wrong direction. The second is a real product strategy: the reasoning that connects top-level business goals to the specific, prioritized problems each team is asked to solve. Most organizations skip this entirely. They have business goals and they have a pile of feature ideas they hope will hit those goals, and the empty space between the two is exactly where strategy is supposed to live.8
Here’s the typical misstep. A company decides to “do outcomes,” and immediately limits itself to the outcomes its existing dashboards can already measure. Everything else stays a feature. But the most valuable problems are very often the ones you don’t instrument yet — the ones that require defining a new metric and doing the unglamorous work of collecting the data. Letting your current KPIs decide which problems are allowed isn’t rigor. It’s the tail wagging the dog.9
This is also the real reason OKRs earned such a black eye. Thousands of companies layered the OKR ritual on top of an unchanged, output-driven roadmap process and were baffled when nothing improved. The technique didn’t fail them. They’d bolted a product-model practice onto a feature-factory operating model and kept everything else the same — the same funding by project, the same stakeholders dictating features, the same definition of done. You can’t adopt the scoreboard and refuse to change the game.10
This is what I’ve written about in Product teams really do outperform and, more tactically, in Can you rely on SAFe to deliver elite-performer gains?. So renaming alone is nowhere near enough, but an honest shift toward true outcome-based goals is a real beginning. It’s also just half the battle if your ultimate goal is elite-performing results.
This newsletter grows by word of mouth… I’d really, truly appreciate it if you could refer a friend. Your referrals make it worthwhile.
Not everything is an outcome — and an honest test
A fair objection: does every line really have to become a problem-to-solve with a metric attached? No, and pretending otherwise is its own kind of theater. There’s always a set of keep-the-lights-on work — bug fixes, a compliance report you now have to file, a tracking pixel a partner needs. Cagan’s advice is refreshingly blunt: unless there’s real risk involved, don’t agonize over the outcome. Put it straight on the backlog and knock it out. Reserve the outcome discipline for the work where it actually changes what you’d build.11
I like to test assumptions. Challenge them by looking for an outcome. A true KTLO emergency — the system is down, get it online fast — is easy to wave off as “exempt” but don’t stop there. Make sure the server doesn’t crash again. Put a metric in place to validate the tracking pixel actually delivers data our partner can act on. “Exempt” means no decision changes based on the answer. Do the work, keep it, and move on no matter what. Measuring it would be theater. That’s true KTLO.
On the other hand, if the result would change what you do next, it’s product work wearing a KTLO costume, and it earns an outcome.
Each passes its litmus test by informing a decision — keep going, change approach or kill it. A measure that informs nothing is a vanity metric.
And if you want to know honestly where you stand today, run the look-back test Cagan recommends. Pull up last year’s roadmap and grade it — not on how many items you delivered, but on how many actually moved the business result they were meant to move. Most teams have never done this, and the first time is uncomfortable, because the delivery rate is usually high and the impact rate is usually grim. That discomfort is the point. It’s the same gap the research keeps finding at the industry level: the majority of shipped features see little or no use. A team measured on output looks productive while quietly building a mountain of work nobody wanted. Outcomes are how you stop mistaking motion for progress.1213
Where to start on Monday
You don’t need a reorganization to begin. You need one honest pass through your current roadmap.
Take it line by line, and for each feature ask two questions: what problem is this supposed to solve, and how would we know if it did? Write the answers down. Some lines will resolve cleanly into a problem and a measure — those were outcomes all along, just mislabeled. Some will expose that you have no idea why the feature is there, which is the most useful thing you can learn. And some are keep-the-lights-on work that belongs on the backlog, no ceremony required. What you’re left with maps almost one-to-one onto a set of OKRs, which is exactly what Cagan means when he says the two are the same idea in different clothes.14
The goal of all this isn’t tidier paperwork. It’s what I call line of sight — the property that any person on the team, asked at any moment why they’re working on the thing in front of them, can name the customer problem it solves and the number that will prove it. When that line of sight exists, you stop shipping features into the void and hoping. You start solving problems and knowing.
You can rename every feature on your roadmap by Friday. It will feel like progress and change nothing. Or you can do the harder, slower work of naming the problems and the measures — and actually have something to show the next time someone asks whether all that shipping made anyone happier. It will count for something — but it’s only base camp on the climb to a true product-team transformation.
For the mechanics of turning objectives into measurable key results, see the Delivery Playbook chapter 2.2 Roadmaps and OKRs, and its companions on 2.1 Product strategy and 1.3 Product vision. For the evidence that outcome-driven product teams genuinely outperform, see Product teams really do outperform: bringing the receipts.
Word-of-mouth is how this newsletter grows, and your support means everything.
The line is widely sourced to George S. Patton, War As I Knew It (Houghton Mifflin, 1947). Marty Cagan opens “The Alternative to Roadmaps” (Silicon Valley Product Group, September 7, 2015) with a looser paraphrase of it. The PayPal example and the year-end look-back exercise are from Cagan’s article.
Cagan, “The Alternative to Roadmaps,” op. cit.
Josh Seiden, Outcomes Over Output: Why Customer Behavior Is the Key Metric for Business Success (Sense & Respond Press, 2019). The definition — “an outcome is a change in human behavior that drives business results” — is the book’s central thesis.
Marty Cagan and Felipe Castro, “Outcomes Are Hard,” Silicon Valley Product Group. Source for the problem-plus-measure framing, the list of clear problem statements, the “letting existing metrics dictate problems” mistake and the account of why bolting OKRs onto an output-based roadmap fueled the OKR backlash.
Teresa Torres, Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value (Product Talk LLC, 2021). Torres distinguishes business outcomes — lagging indicators such as revenue or churn, largely outside a single team’s direct control — from product outcomes, measurable changes in user behavior that a team can move now and that lead the business result.
Cagan and Castro, “Outcomes Are Hard,” op. cit.
Marty Cagan, “Roadmap Alternative FAQ,” Silicon Valley Product Group, September 21, 2015. Source for the point that an outcome alone is not enough context (a product vision is also required), the 1:1 mapping between OKRs and an outcome-based roadmap and the handling of keep-the-lights-on items.
Marty Cagan, Empowered: Ordinary People, Extraordinary Products (Wiley, 2020) and Transformed: Moving to the Product Operating Model (Wiley, 2024). The distinction between a genuine product strategy and a pile of hopeful feature ideas is developed at length in both.
Cagan and Castro, “Outcomes Are Hard,” op. cit.
Cagan and Castro, “Outcomes Are Hard,” op. cit.
Cagan, “Roadmap Alternative FAQ,” op. cit.
Cagan, “The Alternative to Roadmaps,” op. cit.
Pendo, 2019 Feature Adoption Report, which analysed 615 product subscriptions and found roughly 80% of features rarely or never used. The older Standish Group CHAOS research points the same direction (and has itself drawn methodology critiques); I lay out the fuller evidence in Product teams really do outperform: bringing the receipts.
Cagan, “Roadmap Alternative FAQ,” op. cit.