Someone in your company has already tried AI, because somebody always has. A prototype got built in a week. A platform got priced, and a pilot ran for a quarter before it stopped so quietly that nobody in the building ever had to call it off. The tools worked. The demos were fine. Nothing was wasted either, because something real did get settled.
What got settled was a technical question. Nobody could say afterwards which business problem had been solved, or what solving it would have been worth. Both questions come before the build.
That step is the diagnosis.
The concern is not the problem
A concern arrives from your board, from a customer, or from a quarter that came in worse than forecast. It is real. Nobody can price it yet, because what your leadership team is looking at is the concern rather than the thing underneath it that produces what they see. Naming it is the work. It is harder than it looks.
RAND interviewed 65 experienced data scientists and engineers about why AI projects fail (RAND Corporation, 2024). First on its list is neither the model nor the budget. People misunderstand what problem the AI is supposed to solve, or never manage to say it clearly to each other.
Two years on, the finding has not aged. A 2026 paper reading the same failures company-wide lands in the same place (McClure and Gerdau, 2026). Their verdict is that AI failure is a problem of how a company learns rather than a gap in technology.
One caveat, from the study itself. Most of RAND’s interviewees were engineers rather than executives, so the list may tilt towards leadership failures for that reason.
A prototype answers a smaller question
A quick build answers one question. Can it be made to work? Usually it can. That is worth knowing, and it is still not the question your company needs answered. A build shop will build whatever you ask for. That is what a build shop is for.
The risk is never the building. It sits one step earlier, in whether anyone ever stopped to check that the thing being built moves a number your leadership team actually cares about.
The number decides everything after it
Everything rests on one number. What is solving this problem worth? That number sets the budget, fixes the scope, and decides which of your candidate problems goes first. It decides when to stop.
The number has to look forward. Where the margin went last year is history. Nobody can act on history. What changes next year, and what that change adds, is a number you can act on inside the year. And it has to be in your own figures, because a number your CFO did not help produce is a number your CFO will not defend.
Which is why the diagnosis is charged work. Give it away and every decision that comes after it rests on trust instead of a number. Charge for it and it gets scheduled, staffed, argued over and checked, like any other piece of work.
What a real diagnosis contains
A diagnosis is not a report. It is work that ends with a named problem and a price on solving it. Ask any supplier for these seven. The same list works on your own people.
- The problem underneath the concern. In one sentence, in business terms. If it names a technology, it has named a means, not a problem.
- A number in your own figures. Forward-looking. In units your CFO already reports. Finance helped produce it.
- A definition of solved. Written down before the build starts, naming the number that must move.
- What would prove it wrong. A real diagnosis names the conditions that would make its own answer false.
- What it could not settle. The questions the work could not close, listed plainly. Silence is not a finding.
- A price attached to a named result. Not to hours, seniority or elapsed time. A change of scope becomes a new named problem, not an overrun.
- A date, and a name. The day the number gets read is agreed in advance. One senior person is answerable for the answer, from the first meeting to that reading.
Everybody expects the first three. The last four are what make the first three checkable, which is also why they are the four you will most often find missing from a proposal. A supplier who will not write down what would prove them wrong has not finished the work.
A diagnosis you cannot fail is not a diagnosis
We drafted a problem statement of our own and then killed it. It described a number as a wound, but when we checked it against its own sector the number turned out not to be unusual at all. The strong form died. A narrower claim went in its place, which is the test working rather than the test failing.
Two checks did most of that work, and anyone can run them.
Check the base rate. Compare the number to its own sector before calling it a problem. A figure that looks alarming is often the industry’s normal state.
Check the mechanism. A complaint about timing is often a complaint about detail. One we tested said the accounts arrived too late, and the timing turned out to be fine. What was missing was per-project detail during the year, which is a different problem needing a different tool.
What skipping it costs
The cost does not disappear. It moves. It shows up as a tool your people never open, because it solved a problem they did not have. It shows up as a renewal you cannot justify, because no baseline was ever written down at the start. A year on it arrives as a question nobody can answer. What did that get us?
A named problem with a number attached changes that. The work has a target. The spend has a test, fixed before anyone is invested in the answer.
So take the last AI proposal on your desk. Find the number, and whose figures produced it. Then find the sentence saying what would prove it wrong, and the date the number gets read. If those are missing, you are holding a build rather than a diagnosis.
The build is the visible part; the decision about what to build is where the money is made or lost.