Predictability vs Outcomes
I was first taught about the importance of outcome over output way back when I was an engineer getting coached to become a tech lead, and I was explicitly told that it was no longer enough to just build and ship, I had to make sure the solution actually solves the underlying problem.
I have been writing about the importance of outcomes over output for more than a decade, and it is a core theme of all of the books.
And it’s not just me, as many people have been echoing the same critical point, in books, articles, posts and talks.
And I really don’t think I’ve ever encountered anyone that tried to argue that output was more important.
Yet, here we are, in 2026, in the midst of AI turbocharging product development, and we have never had the problem of abundant output yet scarce outcomes more than we do today. I wrote about that recently in The AI Productivity Paradox.
But it was only a few months ago that I realized that I was framing this all wrong.
The issue is not whether outcomes are more important than output; of course they are.
But it’s also true that we can’t achieve outcomes without output, so outcomes versus output is not really a trade-off. And it’s very easy to tell yourself “well outcomes are hard, and we need to create output anyway, so I’ll focus on lots of output, and hope something works.”
The focus on output may be the symptom, but I really don’t think it’s the root cause.
Increasingly I have come to see the root cause as the desire for predictability.
The real trade-off is the relative priority of outcomes versus predictability.
Many product teams have an intuitive understanding of this trade-off. As Henrik Kniberg has long emphasized, “100% predictability = 0% innovation.” The Agile Manifesto tries to capture this point. One of the product model principles described in the book TRANSFORMED is innovation over predictability.
In this context, “outcome” is probably a more precise term than the more general “innovation.”
Recently I wrote an article discussing my regrets after publishing INSPIRED, and I explained that “One of my biggest mistakes was that I simply didn’t appreciate just how powerful and deeply rooted the desire for predictability was.”
Predictability is not inherently a bad thing. In fact, there are certain situations where real predictability is absolutely necessary, and we’ve long had techniques for managing those cases.
But this is all for the situation where outcomes are the priority, yet you still need to occasionally deal with cases where predictability is critical.
Unfortunately, most companies are implicitly making a different choice. To them, predictability is the clear priority, and outcomes are a hoped-for consequence of shipping what was promised.
Especially in organizations still running the project model, where their feature teams are set up “to serve the business,” and so they aren’t in a position to take responsibility for outcomes.
That is the only explanation I have for the many companies that adopted SAFe over the years. It is a model that very clearly is optimized for predictability, and makes no serious attempt at achieving outcomes.
Even though so many companies prioritize predictability, it’s no secret that they are often very poor at meeting their predictability goals, and executives, stakeholders and customers know this, and the resulting lack of trust often just makes the situation worse, as output becomes the fallback way to gauge progress.
If you frame the trade-off with company leaders as predictability vs outcomes, they’ll very likely say that of course they need and expect both. And from their perspective, it’s not hard to understand why both are so desirable. But it’s not hard to understand how these two worthy goals of predictability and outcomes can be at odds.
If you’re prioritizing outcomes, then you need to acknowledge that many, if not most, of the product ideas on your roadmaps are simply not going to work. This means understanding what you can’t know, and admitting what you don’t know.
As Steve Jobs explains in the famous Lost Interview, believing a great idea is 90% of the work is a dangerous “disease” that ruins companies.
Outcomes require humility, and knowledge of the craft of product, especially product discovery, where we are working to quickly discover a solution that can generate the necessary outcome.
This problem goes far beyond executives and stakeholders. Many product leaders and product managers contribute to this problem every day by continuing to push untested ideas onto product roadmaps, usually with expectations on dates or at least timeframes.
Framing this trade-off as predictability versus outcomes hopefully gets closer to the essential decision that a company needs to make when deciding their culture and what they choose to reward and incentivize.
I am increasingly having this exact conversation with company leaders, and I believe we are now at the very heart of the issue, and the root of the difference between the project model and the product model, and those that are using AI to achieve better results, versus those just running faster in the wrong direction.