The foundation for adopting an outcome-led approach to product development
“Focus on the outcome, not the output” has been a mantra that many product teams recant in their daily work. What are the prerequisites for adopting this approach though?
For some time I could not quite put my finger on what was bothering me when seeing different posts saying “don’t just ship fast and often!”, “don’t measure yourself on how many features you delivered” or “always focus on outcomes first”. This post is an attempt to clearly articulate what raised my eyebrows when finding quotes similar to those above and what my beliefs in this regard are.
Spoiler alert🚨. I think the adoption and success of an outcome-led approach require maturity in problem framing and decomposition, execution, and simultaneous focus on both outcome and output.
A lot has already been written on the topic and it is not my intent to regurgitate the definitions again. Let’s just say that by an output I am talking about a delivered tech or user-facing feature and by an outcome — an observable change in business or customer operations resulting from the output. Please note, I do not consider burnt story points or time spent as an output.
