Why “find the bottleneck, then decide about AI” is good advice you often cannot follow, and what to demand from AI projects instead.
The theory that sounds right
There is a piece of advice going around AI strategy discussions, and I have given versions of it myself:
Technology does not create value. Removing constraints creates value.
It is an old idea, and a good one. The performance of a system is limited by whatever is holding it back. Improve that constraint and the whole system can improve. Improve something else and you may only make one department faster at producing work nobody downstream can absorb.
Eliyahu Goldratt made this idea famous through the Theory of Constraints and The Goal, a story set in manufacturing.
Applied to AI, the advice becomes:
Do not begin by asking: “Where can we use AI?” Ask what limits the business. Find the bottleneck first, then decide whether AI is the cheapest and most reliable way to remove it.
On the surface, this is excellent advice.
It kills a certain kind of project immediately: the chatbot nobody asked for, the meeting summarizer that summarizes meetings that should not have happened, or the coding assistant given to a team that spends more time waiting for product decisions and approvals than writing code.
It forces the right question:
If this AI system works perfectly, does the company produce a better result?
Every AI project should answer that question.
But the advice hides a much harder instruction:
Find the bottleneck.
The company you actually run
The Theory of Constraints was born in manufacturing, where constraints are often far easier to observe than they are in a large knowledge-work organization.
In a repetitive production process, work may physically accumulate in front of a slow machine. Inputs, outputs and cycle times can be measured. The process may still be complicated, but much of it can be seen.
Now look at a bank, a government agency, or almost any large organization where the work happens mostly inside people’s heads.
There are hundreds of overlapping processes. Formal procedures exist alongside informal workarounds. A legacy system from 2004 is understood by three people, two of whom are approaching retirement. A regulatory change is expected in the third quarter. One guy in operations quietly holds a critical process together, although his job description says something else.
On paper, the process has four steps. In practice, requests from two major clients are exported to Excel and emailed to one particular employee because the core system cannot represent their contractual exceptions.
Nobody designed the organization as a complete system. It accumulated. And it keeps changing while you are trying to understand it.
No one has a complete picture. That is not a failure of management. It is a property of large human organizations.
So the instruction to “find the constraint before making a technology decision” can amount to:
Fully understand your company, then act.
You cannot fully understand it. You certainly cannot freeze it while you perform the analysis.
By the time you have mapped the process, the market has moved, the regulator has changed the rules and two key people have left. You have mapped a company that no longer exists.
Goldratt’s answer was that complex organizations have an “inherent simplicity”: beneath thousands of details, only a few things really govern performance.
Maybe. But you still have to find them inside an organization that nobody fully understands and that keeps changing while you look.
Two different kinds of AI projects
The mistake is treating all AI projects as one category.
There are at least two, and they should be judged differently.
Delivery projects
Sometimes the problem is not mysterious.
Claims take twelve days because employees copy the same information between three systems and wait for one approval. You know where the delay comes from and what it costs.
In that case, AI is not a strategy. It is one possible fix.
Remove the approval. Connect the systems. Standardize the inputs. Buy ordinary software. Hire another person. Or decide that the delay is cheaper than fixing it.
If one of those works better, use it.
A delivery project is not there to discover whether AI is interesting. It is there to produce a better result at a cost and risk the business can accept.
If AI is the best option, changing the technology may still not be enough. Goldratt made another useful point: organizations build rules and habits around their existing limitations. Remove the limitation but keep those rules, and much of the benefit disappears.
If AI drafts a claim in ten seconds but it still waits three days for approval, you have automated a step without improving the process.
Software teams are beginning to run into the same problem. If coding agents produce more pull requests than the team can review, coding got faster but delivery did not. The bottleneck moved to review. Unless the team changes how work is scoped, tested and approved, the agents are only producing a larger queue.
Exploratory projects
In an exploratory project, you do not yet understand enough to make that calculation honestly.
You may not know whether current models are accurate enough on your data. Whether the acceptable error rate is achievable. Whether access permissions can be preserved. Whether employees will trust the system. What production operation will cost. Whether the useful application is even on the list of twenty ideas somebody already wrote down.
For this kind of project, “What is the ROI?” is the wrong first question.
The better question is:
What important uncertainty will this project reduce, and which decision depends on the answer?
A retrieval pilot may show that your document base is too inconsistent for the proposed system. That result can prevent a much larger investment.
A workflow pilot may show that employees will not use the tool, because it adds one more interface without removing any existing work.
These results do not increase throughput. They still create value, because they make the next decision materially better.
But an uncertainty is not worth reducing merely because it exists. It must obstruct a real decision. Otherwise a team can produce an endless series of technically interesting pilots, each of which “learns” something nobody needed to know.
So an exploratory project should begin with a contract:
- The uncertainty. What do we not know?
- The decision. What will we decide differently once we know?
- The limit. How much time and money are we willing to spend?
- The evidence. What result would answer the question?
- The next step. What would make us scale, revise or stop?
For example:
We will give two employees six weeks to test AI-drafted responses on 200 past customer complaints. They will answer half normally and review AI drafts for the other half. If the AI-assisted responses take at least 25% less time without increasing factual or policy errors, we will fund the integration. If the results are close, we will revise the workflow and run one more test. Otherwise, we stop.
That is an experiment. It has a limit, a result you can measure and a decision waiting at the end.
“Let us build a chatbot and see what happens” has none of the three.
How useful applications are actually found
If you cannot identify the best use case in advance, how do you find it?
You first identify an area where AI might plausibly help. It does not have to be the ideal choice. It needs to be affordable and small enough to finish.
Then you build it and discover everything the slide deck did not mention. Those surprises are not a distraction from the project. Discovering them is part of what the project is for.
Once there is something real to show, somebody from another part of the organization asks:
Could this work for our problem?
That question matters. Their problem may be more valuable than the original one. More importantly, it now comes with somebody who understands the work, wants the result and can explain the exceptions that were missing from the official process.
The second implementation benefits from everything learned during the first.
This resembles how good software systems are built. You fire what The Pragmatic Programmer calls a tracer bullet: build one narrow path through the real system, see where it lands, and correct your aim. After two or three implementations, the common infrastructure and the right abstractions begin to reveal themselves.
The first project does not need to be the final destination. It needs to produce something useful: a business result, or knowledge that changes the next decision. You may spend weeks finding the right data, getting access approved and working out how to test the result. The next project will not have to pay for those lessons again.
That is how you find the valuable application. You build one thing, show it around, and somebody brings you a problem worth more than the one you started with.
The role of belief
An exploratory AI project depends on the people who actually understand the work. Those same people may suspect that the system is being built to replace them.
You need them to explain their edge cases, expose the workarounds missing from the official process, test unreliable early versions and tolerate extra work before any benefit has been proven.
The fully honest message would be:
We do not know whether this will create value, and we need your help to find out. If it works, it may also reduce the amount of work and perhaps the number of people needed to run this process.
That is honest. It is not especially motivating.
Management still needs to explain where the company is going, why the experiment matters and why people should participate. The result is not known, but the purpose should be.
There is a clear boundary between giving people a reason to participate and inventing the result in advance.
“We believe this could remove repetitive work, and the pilot will show us where it is reliable” is a reasonable claim.
“This program will reduce operating costs by 30%” is, unless you have evidence, a number somebody made up.
Every transformation program that transforms nothing makes the next one harder. Employees remember initiatives announced with certainty that later disappeared without explanation. After several of them, every new AI project begins with distrust.
You need enough belief to get people involved. Lie about the outcome, and the next project starts with nobody believing you.
A more realistic rule
So where does this leave a CTO or CEO deciding what to do about AI?
Sometimes the bottleneck is known. There is a visible queue, a measurable outcome and a known cost of delay. Define the outcome, compare AI with the boring alternatives, and build it only if it wins.
If the situation is less clear and the important unknowns prevent an honest business case, then stop pretending that you are delivering a known transformation and run a bounded experiment instead. Name the uncertainty. Name the decision that depends on it. Set a cost and time limit. Decide in advance what evidence would make you continue or stop. Measure what actually happens.
And hold both kinds of projects to a standard.
When the constraint is known, demand economics.
When it is not, demand learning that changes a decision.
A project that delivers neither is not delivery, and it is not exploration.
It is theater with GPUs.