Most AI investments fail because the buying happens before anyone names the decision it was meant to improve. The working sequence runs downwards, not upwards: a decision worth improving, then the workflow that carries it, then the data, then the model, and the tool last. Build a decision inventory scored on frequency and cost-of-error, take three from the top-right quadrant, design the workflow with named checkpoints, and put a dated gate on it with kill criteria written on day one.
Before you read any further, try this on your own business.
Name the three decisions your AI investment was supposed to improve. Decisions, not tools.
Most of the leaders I put that question to can’t answer it, and mind you, these are not careless people. They’re running companies where the buying happened before anyone asked that question, and everything downstream has been paying for it since.
The shape of it
See whether you recognize your own company in this:
Licenses bought across three or four functions, each one procured separately by whichever team moved first. A copilot rollout with a strong opening in the first two weeks, followed by a usage curve that flattens, or worse, falls off a cliff a few weeks later. Demos that are genuinely impressive. Dashboards that are genuinely beautiful. Then, a year later, real money spent, and not one recurring decision in the business that happens faster or lands better than it did before.
I don’t read that as a technology failure. Every one of those investments bought capability. But none of them changed how decisions get made, because nobody redesigned the system that applied the capability.
Five things have to be in place before AI changes anything that matters:
- A decision worth improving,
- A workflow that carries the decision,
- Data on which the workflow stands,
- A model,
- And a tool.
Most companies start at the bottom of that list and work their way up. Not surprisingly, they run out of steam somewhere around the third step. To make it work, you need to start at the top and work your way down.
Start with the decisions, not the tools
The first move is a decision inventory, and it’s less sophisticated than it sounds. List the recurring decisions your business makes. Then score each one on two things:
- How often it comes up,
- What it costs you when you get it wrong.
Now you’ve got two axes, four quadrants, and four different answers.
- High frequency and low cost is where straightforward automation works best, and it’s the easiest place to show an early win.
- High frequency and high cost is the augmentation zone, and in my experience it’s where the real value sits and where most teams are often far too timid.
- Low frequency and low cost should be left alone, because the design effort will cost you more than the decision is worth.
- Low frequency and high cost needs a human in front, AI behind, and a strong paper trail to keep track.
None of this requires information you don’t already have. You know which decisions come round constantly and which ones hurt when they go wrong. Putting them on two axes just gives you a bird’s-eye view. The inventory won’t tell you what to build. It tells you what’s worth building.
Then pick three from the top right. Not thirty. Three. Thirty is how you end up exactly where we started, with a lot of licenses and no real progress.
Design the workflow before you buy anything
This is the part that gets skipped, and I understand why. It’s the least interesting work in the whole sequence and it doesn’t demo well.
A workflow isn’t a prompt and it isn’t a piece of software. It’s a designed answer to these five questions:
- Which steps does the machine take first?
- Which steps stay human, and why that human?
- Who checks the output before it moves anywhere, and against what standard?
- What happens when it’s wrong, and who finds out?
- How does this get better over time?
If I had to bet on one of those mattering most, it’s the third. The verification layer is what almost everyone leaves undesigned, and I think it explains most of the cases where trust never forms. An output that nobody is checking is an output that nobody acts on. So the work gets done twice; the second time by a human who no longer trusts the first pass, and several weeks in, somebody concludes the pilot didn’t work.
To make that concrete: On a forecast cycle, a checkpoint is a named person, a stated tolerance, and a written rule about what happens outside it. For example, variance under 2% moves through untouched. Anything above it stops and gets a human explanation attached before it goes anywhere near a board pack. Building this checkpoint takes an afternoon, and it’s the difference between a first pass people use and a first pass people have to redo.
There’s a side effect here worth calling out too — Sit down to map a workflow properly and you usually discover that the underlying process was never properly documented in the first place. As uncomfortable as that may be, it’s also free value. You’d have wanted to know either way.
Put a date on it
Then run it, and give it an ending.
I’ve come around to the view that the word ‘pilot’ is part of the problem. A pilot has no end date and no failure condition, so it drifts, and drifts, and then it dies slowly without anybody learning anything from it. A gate behaves differently.
- Days 1 to 5 — Baseline. Measure the decision as it stands today. Cycle time, rework rate, error rate. If you skip this, you’ll have nothing to measure against later.
- Days 6 to 20 — Design. The workflow, not the tool. Checkpoints named. Owners named.
- Days 21 to 50 — Run both paths live. Yes, it costs more to run two parallel systems, but it’s also the only way to produce evidence that will convince a skeptical CFO.
- Day 55 — The gate. Against kill criteria you wrote down before you started.
- Day 60 — Scale it or stop it. Both are good outcomes. Drift is the only bad one.
Write the kill criteria on day one, before anyone’s reputation is attached to the answer. By week eight the definition of success will have moved, and nobody will have noticed it moving.
If you’re on the board rather than in the function
The technical ground here is intimidating, and it doesn’t need to be. You don’t need a view on model architecture to do this part of your job properly. You need five questions and a feel for what a straight answer sounds like.
The fifth one is where I’d double down. A management team that can’t tell you what it has deliberately chosen not to automate usually hasn’t sat down with the problem long enough. The exclusion list tells you how much thought has gone into the process.
None of this asks you to become technical. It’s the same oversight instinct you’d bring to a new market entry or a change in treasury policy. Somebody names the objective, somebody owns the control, and somebody can tell you what happens when it goes wrong.
Where this leaves you
Your competitors have access to the same models you do. They can buy the same tools by Friday. Whatever gap opens between you over the next two years will have very little to do with which vendor anyone picked, and almost everything to do with who did the thinking work sitting above the tool.
None of that is complicated:
- Three decisions worth improving,
- A workflow with checkpoints somebody owns by name,
- A date on the calendar when you decide whether it worked.
I’ll admit, it’s far less exciting than buying something new. But it’s also the part your competitors are most likely to skip.
Kamran Habibollah is the founder of Third Horizon Capital Advisory, which provides CFO-grade strategic finance insights to founders, CEOs and boards. He spent 20+ years in global technology enterprises running multi-billion-dollar P&Ls.
Kamran Habibollah
Founder & Principal, Third HorizonTwenty years in technology and telecommunications finance, including senior finance leadership at Cisco, across the Middle East, Africa and Europe. He advises founders, CEOs and boards on capital strategy, transactions and investor relations from Dubai.
More about Kamran →