Valuing Benefit Over Outcomes
Lately I’m seeing numerous discussions of “outcomes over outputs”. I’m finding the use of the term “outcome” a bit confusing. It seems to be used in two different ways, both of which feel problematic. The first refers to customer behavior changes in response to features you deliver. The second refers to business results that come from the aforementioned customer behaviors. Both definitions miss something important: why do customers change their behavior? What benefit do they derive from a given feature? If I change the structure of my website, and users spend more time on it as a result, and I make more ad revenue as a result of that, what actually made them want to spend more time on my site?
Our purpose as service providers is to help customers accomplish something that is useful to them. Without understanding the why behind the what, you don’t know what your purpose is. You have no compass to guide decisions about which work to do or when to do it. Customers don’t actually buy features; they buy help accomplishing their goals. If you don’t understand their goals, you can’t generate (or test) a meaningful hypothesis about how a given feature will help satisfy those goals. Neither customer behaviors nor business results capture this dimension.
Focusing on the what, whether that means a feature or a customer behavior or a business result, is how we get feature factories and products that don’t meet customer needs. The word “outcome” also suffers from lacking an opinion. An outcome can be positive or negative. Any change counts as an outcome, even if the change involves users abandoning our service. While we need to learn from failure, the point is to succeed through positive outcomes.
For these reasons, I prefer the word “benefit” over the word “outcome”. Merriam-Webster defines benefit as “useful aid”. This definition perfectly captures the meaning of our work. It provides a simple formula for determining whether an outcome was successful: “does this feature provide useful aid?”
We can use this formula to connect the what to the why. We can generate customer-centered hypotheses such as “we believe users will spend more time on our site because restructuring it will make it more informative”, “we believe this widget will let customers see the metrics that matter most to them”, etc. We can then test whether we have in fact provided aid (ability to find information, see metrics) that is useful.
By defining benefits such as “easily finding information you care about” or “seeing the metrics that matter ”, you anchor outputs without constraining them. Benefits tell you where you’re trying to go without sacrificing your flexibility or creativity in getting there. As a result, valuing benefits over outcomes or outputs accomplishes the hardest challenge in modern product delivery: resolving the tension between agility and strategy.
