Delivering features isn’t the same as delivering value. Focusing on outcomes means prioritizing the impact we create over the features we build.
In the early years of my career, I was like Wile E. Coyote. My focus was on building things instead of achieving results.
In school and college, success was about getting good grades. Follow the instructions, ace the test, and move on. When I landed my first job, I brought that same mindset with me. But now, it was about getting the design approved and meeting project requirements. It felt amazing to move tasks from the “to-do” column to “done.”
Delivered on time — Check.Looks great — Check.Developers approved — Check. 
For a while, I thought I was nailing it. But then something started bothering me. Some of the products I designed didn’t work as planned. Others failed to achieve business goals. Some never even got made — they just ended up archived in some obscure folder.
I remember one project in particular where I put my heart and soul into it. It was a website for a pharma company. After four months of hard work, we presented the finished product. The stakeholders were thrilled. But months later, the project still hadn’t gone live. Turns out a change in management had shut it down.
Wasting all that effort made me realize I was on the wrong track. My focus had been on delivering outputs, not creating value. I was optimizing for delivery, but not for impact.
It’s great to ship something we’ve worked on, but delivering features is not the same as delivering value. Finishing the product is just part of the process. What we really want is to make our customers successful. Their success is our success.
Outcome-Driven Design
Companies love to say they’re customer-centric, but they still measure success by how many features they’ve shipped. They prioritize technical aspects over their customers’ needs. But the real value isn’t in the features we build, it’s in the impact those features have on the people who use them.
Designers can’t measure success by how awesome the interface is.Developers can’t measure success by how clean the code is.Managers can’t measure success by delivering the product “on time.”
Yes, we design products, but products and features are just means to an end. They are outputs. We don’t want a well-designed product, we want to achieve an outcome.
An outcome is a change in human behavior that drives business results. It’s not about what you make, it’s about what happens because of what you made.
Framing the work around outcomes changes the focus from building things to changing behaviors. It also provides a compelling narrative: The solutions created by the team, modify customer behavior, which results in a positive impact on the company.
In Outcomes vs Outputs (it’s a quick read, and totally worth it), Josh Seiden explains the framework. Start by defining the Impact — the business result you’re aiming for. Next, identify the Outcome — the specific customer behavior that will drive that business result. Finally, think about the Outputs — the actual features or products that will influence that behavior.
The order is important. You start with the end result and work backward. The specific solutions are the last thing you consider, not the first. For example, if the end goal (Impact) is to reduce customer support costs, the desired behavior (Outcome) might be for users to resolve issues on their own. Possible solutions (Outputs) could be a redesigned help center, an FAQ section, or a chatbot.
Aligning leadership and product teams around outcomes
Nick Fury is a leader who focuses on outcomes. He sets the goal of defeating the bad guys but leaves it to the Avengers to figure out how to get the job done.
In many companies, leaders define what to build, and the minions are left to execute. This top-down approach is poison for innovation and creativity. It takes away the team’s autonomy and motivation by reducing designers and developers to task-doers. You can’t make meaningful contributions with these constraints.
But the opposite extreme is just as problematic, giving teams broad goals without any direction. When objectives are too vague, like ‘Increase revenue,’ the team is left to figure out how on their own. There are infinite ways to achieve that goal and without a clear strategy, they can head down the wrong path.
Working with outcomes solves both alignment problems. Leaders, with their broader vision, define the expected impact for the company. But the team, closer to the product and customers, should decide how to achieve that impact.
Leaders select which mountain to climb, but the team chooses the route to take.
This alignment between leadership and product teams doesn’t just clarify goals, it also fuels innovation. Focusing on changing customer behaviors, rather than delivering a predefined feature, opens the door to creative solutions. Teams are free to experiment with different ideas, test them, and adapt as they learn. This flexibility to iterate and explore multiple paths leads to breakthroughs that wouldn’t be possible by following a rigid feature roadmap.
Start designing for outcomes, not outputs
Amazon’s Fire Phone, the so-called “The iPhone Killer” turned out to be a $170 million fiasco. It had a flashy 3D interface that no one cared about but lacked basic apps like Gmail, YouTube and Google Maps. How did Amazon launch a product so disconnected from its users? By focusing on flashy features instead of understanding what their customers actually needed.
Working with outcomes changes this dynamic. It forces us to dig deeper and ask the right questions: What do our customers really need? What problems are they trying to solve? It keeps us from getting distracted by market trends or stakeholders’ whims and instead ensures that we’re creating real value.
Stop measuring success by the number of features you ship and start measuring it by the value you create.
Let go of detailed long-term plans and embrace uncertainty. The path to success is not a straight line, you need to discover it. You’re not just a Product Designer — you’re an Outcome Designer. Next time, instead of asking, “What will we build?” ask, “What will people be doing differently if we succeed?”
From Product Designer to Outcome Designer was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.
