Outcome-Driven AI Discovery

I changed my way of finding AI opportunities.

It used to be a "document how things are done, identify problems, map AI solutions" kind of way.

The problem with this approach is that it works.

It will consistently generate a list of AI opportunities that you can implement immediately as "quick wins." You will find so many of them that you can stay busy chasing quick wins forever. And by doing that, you’ll lose track of the bigger opportunity.

If your ambition level is higher than "let’s squeeze out 10%," this approach becomes too limiting, because it anchors the problem space in today’s operating model.

And very often, that operating model is the biggest bottleneck for AI.

So I started to map AI opportunities using a system that is less step-based and more outcome-based.

Today, I’d like to share what this system is, how it works, and what benefits it brings.

Let's dive in.

Before we get into outcome-driven thinking, let’s revisit the “old” way to help us understand what this shift is really about.

Imagine someone comes to you and says:

(Guess I’ve seen this before)

A typical way to approach this would be to create a process map. You would start by asking:

“How does customer support work for you today?”

And then you map it out.

The process map might look similar to this:

Customer emails land in a shared inbox → someone assigns them → categorizes them → replies if possible → escalates if needed → gathers context → internal back and forth → issue resolution.

Once you map this, the AI ideas are obvious:

To be clear, none of this is bad. Many of them will result in relatively straightforward use cases, especially with features that already exist in tools like Outlook, Gmail, Zendesk, or whatever system the team is using.

The catch is that these improvements are incremental. (About 15% in the case of customer support). They won’t create the kind of AI impact that makes people say: “This completely changed how we serve our customers.”

So how could we think about this differently?

As Michael Hammer used to say: Obliterate, don’t automate.

Let’s take a look at the outcome-based approach.

The key shift is to stop looking at the system only from the bottom up, and start looking at it from the top down.

We don’t ask:

We ask:

And the answer to that question is usually not a process.

It is an outcome.

In the customer support example, the top-level outcome could be something like:

"Happy customers."

Or, more technically:

Resolved customer issues that lead to improved customer satisfaction and higher customer retention.

Of course, no single AI system simply creates happy customers. But the point is that “happy customers” gives us the direction. It helps us understand what this part of the business is actually supposed to produce.

And then we can break it down into several smaller sub-outcomes such as:

Now, just by describing it this way, you can hopefully see how the thinking starts to shift.

We are no longer just looking at the existing steps. We are looking at the outcomes that need to be produced.

I’ve found that there are a couple of major benefits to this approach:

Bigger opportunities: Outcomes allow you to ask much larger questions. You’re faster in “Engineered AI” territory with clear ROI impact.

Better measurement: Quantifying the value of an outcome is easier than the value of a single task, because you can ask: “What are we paying for this outcome today, and what are we willing to pay for it tomorrow?”

Better prioritization: You can optimize for the gap between “What is this outcome worth?” and “What are we paying to achieve this outcome today?”

Clearer ownership: Outcomes usually already have an owner in the organization which makes it easier to assign the core accountability for the AI initiative.

Better cross-functional thinking: Delivering high-level outcomes often cut across teams. That helps reveal opportunities that would be easy to miss in department-level process maps, because most potential often sits between functions, not in one team.

Not everything that looks like an outcome is actually an outcome. Many things are just outputs. The main difference is value capture.

Take a spreadsheet with names and contact data, for example:

Without any context, the list doesn’t tell you much, other than that some process probably generated it. No one would pay for this. But if this list contains everyone who downloaded a specific white paper, then the situation changes. Because suddenly that “list of names and contact data” becomes a “lead list.” The valuable thing is not the list itself, but the fact that it is the artifact of a process that grabbed people’s attention, filtered by interest, and made them complete a certain action – a.k.a. a lead generation process.

AI can produce a ton of outputs without creating a single outcome.

So make sure you don’t mix up the two.

Here is how outputs and outcomes compare:

The easiest way to separate outputs from outcomes is to simply ask:

If the answer is "not much," you are probably looking at an output.

If the answer closer to “take my money”, you are probably closer to an outcome.

The steps for Outcome-Driven AI Mapping are actually very similar to the traditional approach I described in my book.

It’s just a different lens you’re looking through:

So that’s how I currently think about it.

Outcome-based mapping is not a completely different process.

It is the same discipline, but with – in my opinion – a better starting point: not “How can AI improve what we do?”, but “How can AI help us achieve outcomes better, faster, or cheaper?”

Sometimes the best AI opportunity is to accelerate a step.

But sometimes the best AI opportunity is to remove steps entirely, combine several steps into one, or reorganize the work around the outcome you actually want to create.

This little distinction makes all the difference.

See you next Saturday,
Tobias