Where the time actually goes

Point AI at the wrong part of the work and you get a small number. I've seen it happen on programmes run by very capable people, and it almost never happens because the technology failed. It happens because nobody looked closely enough at the work before choosing where to aim.

So before anything gets built, I ask the same four questions of every piece of work. They come from product management, and there's nothing clever about them.

Four questions

1. What is the job to be done? Not the task as it's described in the process map, but what the person doing it is actually trying to achieve.
2. What pain does it remove? For the person doing it, and for the client waiting on it.
3. What gain does it create? Time, quality, revenue, or something the client couldn't have before.
4. What happens five minutes before it, and five minutes after?

The fourth is the one people skip, and it's usually the one that changes the answer.

The seventy days

Take a customer's contract renewal in a business-to-business software company. Ask the first three questions and the obvious answer is a drafting agent: pull the account, price the renewal, draft the paperwork. It works. It speeds up the actual work, which comes to about four days.

Now ask the fourth question. Five minutes before, someone is waiting on usage figures from another team, and pricing can't start until they arrive. Five minutes after, the customer's procurement team sends it back with changes to the same three clauses as last year, and it goes round again. The whole thing takes about seventy days. The work is four of them.

Build the drafting agent and you save days. Build something that gathers the usage figures before anyone asks, and flags the clauses this customer always pushes back on, and you can remove most of the seventy days. That's what the customer and your cash flow actually feel.

The same shape turns up almost everywhere I've looked: in a finance team's month-end close, in a claim, in a new supplier being set up, in a piece of client work. The work is small. The waiting around it is the prize.

I've seen this difference measured on a large programme. The judgement-heavy work barely moved. The repeatable work, and the waiting wrapped around it, improved several times as much, with the same technology. What differed was where it was pointed.

Go or stop, one stage at a time

The other way AI programmes go wrong is by trying to do everything at once. A strategy, a platform, a dozen use cases, a transformation office. It feels serious. It usually means a year passes before anyone can say whether any of it works.

I've used the same five stages for years, long before AI. I helped develop them and later wrote them up as the IDEAS framework: ideation, design, execution, acceleration and scaling. There's nothing novel about the stages. What matters is the decision between them.

• Ideation. Shape the idea until someone would pay for it, or until the people who'd use it say they'd use it.
• Design. Test it with those people, on their own files, before building anything properly.
• Execution. Build it, and measure it against a baseline taken before you started.
• Acceleration. Make it faster and cheaper without losing the quality you measured.
• Scaling. Take it to the next market or team, configured rather than rebuilt.

Between every stage there's a decision to carry on or stop, taken in the room, against criteria written down before the work started. Agreeing first what would make you stop is what makes stopping possible.

What AI changes, and what it doesn't

AI makes every stage faster. An idea that used to take a quarter to prototype can be in front of users in a week; I know because I spend a lot of evenings doing exactly that. The cost of finding out whether something works has fallen sharply, and that should change how businesses decide what to build.

What it doesn't change is the need to measure. A faster stage with no gate just gets you to the wrong answer sooner, and at scale. The temptation now is to skip straight from a promising demo to rolling it out everywhere, because rolling out is cheap too. I'd still take one workflow, one team, one market, and a number before and after.

Scale works best as a series of small, reversible decisions, each taken on evidence the next team can see for themselves. When it works, the second team asks to be next.

Start here

Pick the workflow with the biggest gap between the time the work takes and the time the whole thing takes. Sit with the people who do it and ask the four questions, especially the fourth. Write down, before you start, what result would make you stop. Then build the smallest thing that would test it.

Most of the time, the first thing you learn is that the prize is somewhere other than where you'd assumed.