And what metric does that move?

Every three months, we tend to do the same thing: a stakeholder asks for something, we analyze it, estimate it, plan it for some week in the coming months, and when that week arrives, we execute. At first glance, everything looks neat and well organized. But if you’ve also been stuck in this loop, you may have felt at some point that, after delivering every planned feature perfectly, nothing really changed for your users or for the business. And that’s the core problem: we focus too much on outputs (features) and far too little on outcomes (real impact).

My good friend Fede Kotek, the person who knows the most about these topics, once strongly insisted that I read the book Outcomes Over Output. What the book makes very clear is this: it doesn’t matter how technically flawless a feature is if it fails to change any user behavior. What do we gain from a beautiful, perfectly built feature, like a stunning banner, if no one uses it or, even worse, if users actively dislike it? Technically, we delivered. In practice, we created no real value.

The book argues that output-based planning often results in “guesses, fiction, or lies.” This happens because, especially in software development and other highly uncertain types of work, predicting the delivery of a specific feature by a fixed date is extremely risky.

This traditional model also has another major issue: rigidity. How many times have you wanted to adjust priorities halfway through and had to go all the way to the Supreme Court just to get approval? In real-world environments, where we’re constantly learning new things, adapting shouldn’t be seen as a failure, but as a clear sign of intelligence and flexibility. It’s understandable that stakeholders often want certainty, fixed dates, and a defined list of features, but that expectation clashes with the inherently uncertain nature of the work and with the agile philosophy of adapting and discovering the best way to achieve a result.

So the proposal is that instead of asking “what are we going to deliver and when?”, outcome-based planning focuses on “what customer behavior do we want to change to drive business results?” and “how will we know if we’re right?”. This approach allows for far more flexibility and experimentation to achieve the desired outcome, rather than rigidly sticking to a list of features and deadlines.

Outcome-based management means defining hypotheses and success metrics before execution begins. A direction is agreed upon, and performance is reviewed over a period of time. If the change seems to work, you move on to other areas. If it doesn’t work as expected, you double down and try again. This suggests an iterative, data-informed approach rather than relying on precise upfront estimates.

Where does AI fit into all of this?

If this shift in mindset sounded complex until now, the good news is that technology is finally on our side. Today, thanks to AI, we can dramatically shrink the gap between idea and validation, making experimentation the norm rather than the exception.

You’ve probably heard new concepts like vibe coding or tools like Cursor and Windsurf, which allow us to drastically speed up the process of building and validating ideas. Instead of writing every line of code manually for weeks, we can now turn ideas into working software in a fraction of the time. And what do we gain from that? The ability to experiment faster, validate hypotheses in minutes, and fail fast so we can learn even faster.

This is the real shift: AI doesn’t just accelerate how we build things, it allows us to quickly discover what actually changes user behavior. We no longer have to bet everything on a feature planned months ago, fingers crossed that it will work. Now, we can test continuously, adjust on the fly, and make sure every step is aligned with the real impact we’re trying to achieve.

When we start working under this outcomes-driven paradigm, our day-to-day work changes dramatically: we have a clear north star, a goal to pursue, and we rapidly validate hypotheses that move us closer to it. Did what we built fail to bring us closer to that goal? No problem, we pivot and iterate. Did it move us close enough? Great, we invest our efforts elsewhere in the business.

It’s not just about building faster, but about failing faster, learning faster, and evolving faster. Because in a world where everything is constantly changing, the real competitive advantage isn’t delivering more, but discovering sooner than anyone else what truly matters.

So next time someone asks for a feature, ask Fede’s magic question: “And what metric does that move?”

What do you think? Leave your comment here :)

References: