Almost every AI strategy engagement I have been part of begins the same way. A cross-functional group gets invited to a workshop. The brief is to identify AI opportunities. Someone facilitates. Ideas go up on the board. By the end of the day there is a wall covered in sticky notes and a sense that the organisation has made progress on its AI strategy. I want to explain why that sense of progress is almost always wrong, and why the unit of analysis those workshops produce is the source of the problem rather than the solution to it.
The output of a use case workshop is a list. Sometimes a prioritised list, sometimes not, but always a list of broad capability areas where AI might add value. Fraud detection. Customer service automation. Predictive maintenance. Supply chain optimisation. These are not wrong as general directions. They are useless as investment decisions. A use case describes what AI can do in a domain. It says nothing about which specific decision within that domain is currently being made badly, what it costs when that decision is wrong, who owns the outcome, or how you would know if AI had improved it. You cannot build an accountable programme on a use case. You can build a budget line on one, which is why they persist.
Use cases are vendor language dressed up as strategy
The use case is the natural unit of analysis for a technology vendor. A vendor’s job is to articulate what their product can do and match it to a domain where the buyer operates. Fraud detection is a use case because it describes a capability the vendor can sell. It is broad enough to apply to a large number of buyers and vague enough that no specific performance commitment is required. The vendor does not need to understand your fraud operation, your decision architecture, or the specific point in your process where losses are highest. They just need to convince you that fraud detection is a domain where AI adds value, which it is, and that their product does it, which it probably does in some form.
Consultants have adopted the same language for the same reason. A use case is a large enough scope to justify a meaningful engagement. It is ambiguous enough that success can be defined retrospectively. The use case workshop is efficient from the consultant’s perspective because it generates a backlog of opportunities that each require further investigation, scoping, and eventually delivery work. The breadth is a feature, not a bug. The organisation leaves with twenty use cases and needs help prioritising them. That is the next engagement.
I am not suggesting that vendors and consultants are acting in bad faith. Most of them believe the use case framework genuinely helps. But the incentive structure is real, and the result is that the organisations paying for AI strategy receive outputs that are optimised for the market rather than for the business.
The decision forces the questions the use case avoids
A decision is a specific point in a business process where a choice is made, the outcome of that choice is measurable, and the quality of the choice can be improved. It is specific enough to have an owner, an economic value, a current performance baseline, and a clear definition of what better looks like. Every use case contains decisions. Most use cases contain dozens of them, of wildly varying value and varying readiness for AI intervention.
The difference between a use case and a decision in practice is the difference between “AI-assisted credit decisions” and “the underwriting decision on self-employed applicants under a specific loan threshold where our current decline rate is fifteen points higher than the market and our data tells us a meaningful proportion of those declines are recoverable.” The first is a use case. The second is a problem worth solving, with an owner, an economic value, and a way of measuring whether the AI investment worked.
When you replace use cases with decisions as the unit of analysis, several things happen immediately. The conversation shifts from what AI can do to what the business needs. The economic baseline becomes a design requirement rather than an afterthought. The ownership question gets asked before the technology question rather than after. The prioritisation becomes tractable because decisions can be ranked by value and by readiness rather than by enthusiasm and political visibility. And the governance question, who is accountable for the outcome, has a natural answer because decisions have owners.
The brainstorming format compounds the problem
The use case workshop does not just produce the wrong output. It produces it through a process that actively prevents the right analysis from happening. Brainstorming is designed to generate volume and suppress criticism. It is the right format for creative ideation where novelty matters. It is the wrong format for identifying where AI will deliver the most business value, which requires systematic analysis of where decisions are being made badly and what that costs.
I have never seen a use case workshop that started with a structured review of business performance data and asked which decisions are most responsible for gaps between current outcomes and target outcomes. That analysis would identify the highest-value opportunities with far more reliability than a brainstorming session. But it requires domain knowledge, access to operational data, and a willingness to look at where the business is underperforming, none of which are features of the typical workshop format.
The result is that AI investment ends up concentrated in areas with enthusiastic sponsors and visible technology potential rather than in areas with the largest economic opportunity. The two sets sometimes overlap. Often they do not. The organisations doing this well have stopped asking their people where AI could add value and started asking their data where decisions are failing and what those failures cost.
The practical consequence of getting this wrong
An AI programme built on a use case rather than a decision cannot be measured in business terms because no business baseline was established. It cannot be owned in business terms because ownership was never assigned to someone accountable for the outcome. And it cannot be defended in business terms when the inevitable question arrives about what the investment produced, because the answer requires connecting a technical capability to a business result through a chain of logic that was never assembled.
This is not a theoretical concern. It is the most common reason I see AI programmes that are technically successful and commercially invisible. The model performs well. The capability is real. And when the CFO asks what it delivered, the honest answer is that nobody defined what delivery meant before the programme started.
The fix is not a better workshop format. It is a different starting point. Before any technology is selected, before any data is explored, before any vendor is engaged, the question to answer is which decisions in this organisation are most responsible for the gap between current performance and where we need to be, and what would it be worth to make them better. That question produces a very different AI strategy than a wall covered in sticky notes. It also produces one that can be defended, measured, and built on.
