Stop brainstorming AI use cases

The company announces its AI programme, every business unit is asked to identify opportunities, the workshops are booked, the post-its multiply and a consultancy arrives with a scoring grid. Six weeks later there is a number, say two hundred and thirty-seven use cases, each rated high, medium or low on value and on how hard it would be to build. Seventeen of them are selected for pilots. The room feels good, because something has clearly been achieved.

Then look at what was found. Not the decisions that matter most to the business, but the places where AI could be inserted.

A good method, given the wrong job

Opportunity harvesting is a good way to explore, and the ritual above asks it to do a different job: to set the company's AI strategy. That is a category error: a method built for one job, judged on another. It is an easy error to make, because the method always delivers: a list, on time, with a score next to every line.

The starting question decides the answer before anyone opens their mouth. Ask "where could we use GenAI?" and you will find copilots, chatbots, summarisation, document generation, search, classification and agents, every time, in every company and in every industry. That list describes the technology, and it would be the same in your competitor's workshop. Ask "why can we never recover quickly when our supply network breaks?" and you are somewhere else entirely, because nobody answers that question with a chatbot.

For my part, when I am handed one of these lists I read it for one thing: a line that could not have come from any other company. Most of the time I do not find one. How many would you find on yours?

Two methods for finding the work

The first is opportunity harvesting. It starts from the technology, and its strengths are real, so I would not give them up. It explores fast, it pulls the whole organisation in, it finds genuine productivity wins, and it teaches people what this technology is by letting them touch it.

The second is decision discovery. It starts from the business and works down, from the strategy to a capability, and from the capability to the one decision that limits performance. It asks what should change before it asks what to build, and AI may well be the answer, but it comes last.

What a decision looks like when you take it apart

Take one your executive team would recognise. The company wants to recover faster when supply breaks, and that is a strategy, which on its own is useless. Underneath it sits a capability, something the business must be able to do well, here supply disruption management, and inside that capability sits a workflow: detect, assess, decide, act, recover.

Somewhere in that workflow is one decision, made under pressure many times a year: what is the best response to this disruption? Reroute, change the order of work, move stock, absorb the cost, or warn the customer early. Get that decision consistently better and the strategy moves.

Now read "let's build a supply-chain copilot" again. It is a very thin description of what the business needs, and it says nothing about the layer that decides whether the rest works: does the company agree on what its own words mean? That layer is called a business ontology, and in the diagram above it sits second, before any AI.

Sometimes the honest answer is that AI is not the fix

Go down through a decision properly and it will sometimes tell you something nobody wanted to hear, and the constraint is rarely the AI model. Sometimes the data is not there. Or nobody owns the decision, so it gets made four times by four people. Or two plants define available inventory differently, so there is no single number to reason about. Or the workflow was built around a system that was replaced years ago, and the replacement is still called the new system.

In one programme I know well, the AI was already accurate, and making it more accurate would barely have changed how much of the work could run without a person. The limit sat somewhere else, in how the work handed off between teams and in the cases kept out of automation, and no amount of extra accuracy reaches that.

This is the part that gives decision discovery its credibility, and it is also why it does not sell well.

A methodology that always discovers an AI use case is not a business methodology. It is a sales methodology.

Agents make this urgent

For a summarisation assistant, harvesting is perfectly adequate, because nothing has been handed over: a person still reads, still judges, still decides. That changes as AI moves along a short and uncomfortable path, from reading to recommending, then to deciding, then to acting.

Once software acts, "where can we deploy an agent?" stops being the useful question. It becomes: which decisions are we willing to delegate, under what conditions, and with what consequences when it goes wrong. That is why the decision is the thing to design around. Look back at the diagram above: the decision is the one place where the goal, the meaning, the judgement, the authority and the result all meet. Which of your seventeen pilots was chosen that way?

Keep the list. Stop calling it the strategy.

Exploring and transforming are two different jobs, and a serious company runs both, on purpose, in two lanes.

The strategic lane needs an owner, and it cannot be the workshop. The executive team picks the five to ten capabilities that must improve, each one is taken down to its critical decisions, and the lane is judged on an operating result rather than on how many people adopted a tool. That is the whole governance, and it fits on one page.

In that same programme, the pilot had been built for one unit, but it already ran on rules every other unit shared. So the team stopped presenting it as a use case and presented it as the engine every unit would run on. That changes what a funder is judging, from a niche to the whole portfolio, and it only holds if the shared engine is real. Frame a narrow tool that way and the story collapses the first time somebody looks.

Executives approve use cases. They fund capabilities. Only the second of those two conversations ever adds up to a system.

If you want one number to argue with, look at the gap between what people say AI has done for their own working day and what the company's profit line shows. In McKinsey's 2026 global AI survey, eighty percent say AI improved their own productivity and thirty-seven percent say it had any effect on operating profit, flat on a year earlier. It is self-reported, by a firm that sells transformation work, so keep the gap and not the decimals. It is the gap you would expect to see from the outside if the opportunity lane is full and the strategic lane is empty.

Change the question on the agenda

Go back to the room with the spreadsheet in it. The question on the table was how many AI use cases we have identified, and it is a question about activity, so it always has a comfortable answer.

The rule is the one in the box above: harvest for experimentation, start from a capability for transformation, and for agents start from the decision and from who has the right to make it. So before the next meeting, put a different question on the agenda and give it the first hour: which important decisions will this company be able to make measurably better because of AI? Ask each member of the executive team to bring one decision, the number it would move, and who makes it today; that costs each of them about an hour, and the committee a morning to compare. If the answer is unclear, another hundred use cases will not fix it.

And you: which decision would you bring?

Common questions

Should we stop identifying AI use cases?

No. Harvesting is the right method for exploration, for everyday productivity such as drafting, search, summarisation and extraction, and for an organisation still learning what AI is. What has to stop is treating it as your AI strategy. Run it as one lane of a portfolio, and choose the strategic investments with decision discovery instead.

What is the difference between use-case-first and capability-first AI?

Use-case-first is what this article calls opportunity harvesting. It starts from the technology: where could we use AI, collect ideas, score them, pilot the best. Capability-first is decision discovery. It starts from the business. What must we become better at? Which recurring decision holds that back, and why is that decision hard? Only then does it ask whether AI is the right intervention. The first is faster to a list. The second is faster to a number the finance function will accept, because the outcome is named before the tool.

What does decision-first AI mean?

It is another name for decision discovery taken to its end point: the thing you design, fund and govern is a business decision rather than an application. You name the decision, who makes it today and how often, why it is hard, and what would change downstream if it got better. Then you work out which layers have to exist underneath it: the data, the shared meaning, the logic, the AI, the evaluations, the authority to act, and the way the action is carried out.

How do you choose which AI use cases to fund?

Split the portfolio. Fund the low-stakes productivity lane cheaply and judge it on adoption. For the strategic lane, have the executive team pick five to ten capabilities that must improve. Take each one down to its critical decisions. Then fund whatever makes those decisions better, whether or not it turns out to be AI.