Most people aren't actually outcome-driven

When we ran a four-day strategy program for about 40 product managers at Avanza, one of them said the truest thing I heard all week: “I thought I was outcome-driven, until I realized how quickly I start talking about features.” She was good at her job. She believed she led with outcomes. And the moment she watched herself in real time, the belief fell apart.

Here’s what I think: most people who call themselves outcome-driven start talking features within seconds, and they don’t notice they’re doing it. The label is sincere. The habit underneath it points the other way.

Why does this matter? Because a team that thinks in features ships a roadmap of features and then wonders why the business numbers didn’t move. The cost lands on everyone: the engineers who built the thing, the leaders who funded it, the customers who got a feature nobody asked the right question about.

The tell is the timer

You can measure this without a survey. Ask someone what they’re working on and quietly time how long it takes before a solution shows up. “We’re improving onboarding” is fine for about four words, and then: “so we’re adding a progress bar and a welcome modal and a checklist.” The solutions arrive before anyone has named what should change for the customer or the business. At Avanza we made the room do this to itself, out loud, and the timer was brutal. People who had just described themselves as outcome-led were naming components inside a single breath.

The mechanism is simple. Features are concrete, and concrete things are easier to think about than abstract ones. A progress bar is something you can picture and assign and ship. “New users reach their first real action in their first session” is harder to hold in your head, so the mind reaches past it for something it can grab.

A small rewrite that changes the whole conversation

Take a real before and after. Before: “We’re going to build saved searches and price alerts for returning users.” That’s a feature statement. It names what gets built and stops there. After: “We want more returning users to come back within seven days, and we believe saved searches and price alerts are how.” That’s an outcome statement: it names the change you want (return rate inside a week), and demotes the features to a bet you can be wrong about.

The difference isn’t cosmetic. The first sentence can only be delivered or not delivered. The second can be measured, and measurement lets you be wrong cheaply: if return rate doesn’t move, you kill the feature instead of defending it. Notice what the rewrite costs you, though, the comfort of a clear to-do list. The outcome version admits you might build saved searches and still fail. That discomfort is exactly why people drift back to feature talk; it feels like progress.

Why one habit needs five capabilities

The interesting thing is that “just talk outcomes” is useless advice, because staying outcome-driven takes five separate skills, and the feature reflex wins wherever one of them is missing. That’s the spine of what we taught at Avanza, and each capability plugs a specific leak.

You start by writing a measurable business outcome, because if you can’t state the number that should move, “outcome” is just a nicer word for a feature. Then you find opportunities through intentional research instead of guessing, because most feature lists are a pile of untested assumptions wearing a roadmap. Then you prioritize hard and deprioritize out loud, even when everything feels important, because a backlog where nothing is cut is a backlog of features by default. Then you use storytelling to align leadership and teams, because an outcome that lives only in your head loses every meeting to a feature someone can demo. And you translate strategy into a focused roadmap, because the last place the feature reflex hides is the roadmap itself, where good intentions quietly turn back into a shipping list.

Drop any one of these and you regress. Skip the research and your “outcome” is a guess; skip the prioritization and your outcome is fifteen outcomes, which is none.

”But features are outcomes, this is just semantics”

Now you might be thinking: this is a word game. A feature ships, customers use it, the metric moves, so the feature is the outcome. Saved searches bring people back; calling that an “outcome” instead of a “feature” is just consultants relabeling work that was already getting done. Honestly, this is the strongest objection, and it’s right about one thing: a feature absolutely can produce an outcome. Nobody is claiming features don’t matter.

Here’s where it breaks. “Features are outcomes” only holds when the feature works, and you find that out at the end, after you’ve spent the engineering weeks. Leading with the outcome forces the question before the build: what number should move, by how much, and what happens if this feature doesn’t move it? Teams that conflate the two never plan the kill. They ship saved searches, return rate stays flat, and the feature lives on anyway because no one wrote down what it was supposed to do. The semantics are cheap; the behavior the words protect, naming the target before you commit the build and being willing to be wrong, is not.

The first move

So you don’t have to believe you’re outcome-driven. You can check. Take the thing you’re building this quarter and write one sentence: the number you expect to move, by how much, and the feature you’re betting will move it. If you can write that sentence, you’re leading with the outcome. If you reach for the feature first and the number won’t come, you just found the same gap that room at Avanza found in themselves. And if you can write the number but have no idea whether it’s any good, that’s what a benchmark is for: https://benchmark.scilla.studio.