Why What You Build Matters Less Than You Think

There's a meeting I've been in dozens of times. Someone puts up a slide — a roadmap, color-coded and beautifully organized, feature after feature stretching into a horizon that always looks more certain than it is. The team nods. The stakeholders nod. Everyone leaves feeling like something was accomplished.

And then nothing changes.

Not for users, not for the business. Just more features, shipped on time, received with mild indifference by people who never asked for them. I spent years in that cycle before I could name what was wrong — the problem wasn't the team, wasn't the execution, wasn't even the roadmap. It was that we were measuring the wrong thing entirely.

Output is not the same as outcome. This sounds obvious. It isn't.

The Difference Between Output and Outcome

An output is what you build — a feature, a flow, a redesign. An outcome is what actually changes because you built it, and those two things can be completely disconnected in ways that take months to notice. You can ship a beautiful onboarding experience that nobody uses, hit every sprint milestone and watch your retention quietly fall, deliver a product that is polished and documented and demoed and still have no idea whether it's doing anything for anyone.

Most teams track the first list. Very few track the second.

Finding the 20%: Outcome-Based Thinking

There's a version of the Pareto principle that keeps coming back to me in this work: roughly 20% of what you build drives 80% of the value. I believe that. I've lived it. And if it's true, it means that without real discipline about what you're building and why, most of your energy is going into the 80% that barely moves the needle — which is a brutal thing to sit with when you've just shipped a quarter's worth of work.

Outcome thinking is how you find the 20%. It forces a different kind of question at the start of every project, not "what should we build?" but "what needs to be true for this to matter?" That question, asked honestly before a single design is opened, tends to lead somewhere different. Usually somewhere better.

The teams I've seen do this well aren't the ones with the best process. They're the ones who've decided to care more about what changes than what ships.

There are three layers worth keeping in mind — not as a framework to present in a meeting, just as a mental model for understanding where your work is actually landing.

The Three Layers of Product Success

The first is product outcomes: adoption, engagement, how many people are actually using what you shipped. These move fastest, sometimes within days of a release, and they're the easiest to see. The second is customer outcomes — satisfaction, loyalty, whether people feel like their lives got slightly easier because of something you made. These take longer to surface, because you can't rush trust and you can't manufacture it with a survey. The third is business outcomes: revenue, retention, growth, the numbers that matter to a board. These move slowest of all, because they're the cumulative result of everything else done consistently, over time, without shortcuts.

Most teams obsess over the first layer. Most stakeholders obsess over the third. The middle — the customer — is where the actual leverage is, and it's consistently the one that gets the least attention.

Here's an example I keep coming back to. You redesign your onboarding flow — simpler, cleaner, faster — and you measure whether new users complete it. That's the product layer, and if the numbers improve, that's a real signal worth celebrating for about five minutes.

But then you have to go deeper. Are those users coming back a week later? Are they telling someone else? Are they getting enough value before they have a reason to leave? Those questions live in the customer layer, and they take weeks, sometimes months, to answer clearly. Only much later do they show up in the numbers that actually move a business: better retention, lower acquisition cost, word-of-mouth that compounds quietly in the background. The mistake is expecting the third layer to respond to a change in the first. The chain has to run its course, and no amount of optimism speeds it up.

I'm not arguing against shipping features. I'm arguing for knowing why you're shipping them — which sounds simple and turns out to be one of the harder cultural shifts a team can make.

Before any project starts, not mid-sprint and not at the retrospective, three questions are worth sitting with. What specific outcome are we trying to drive? Not "improve the product" — a real number, a real behavior, a real change in how someone feels using this. How will we know if we're wrong early enough to do something about it? And what are we not going to build to make room for this, because outcome thinking only works if it creates constraints. Otherwise it's just another way to feel good about a full roadmap.

The teams that ask these questions consistently aren't the ones with the best tooling or the most sophisticated process. They're the ones who've decided, at some point and somehow, to care more about what changes than what ships.

That's a cultural shift more than a tactical one. And it's harder to put on a slide.