Most teams do not need an AI strategy.

Somewhere in your organisation there may already be a document with a name like "AI Strategy 2026". It probably took weeks to produce. It probably contains a maturity model, a set of pillars, and a slide about culture. And it probably has not changed what anyone actually does on a Tuesday morning.

That is not because the people who wrote it are foolish. It is because "we need an AI strategy" is the answer boards reach for when the honest answer is "we do not yet know what this is for". A strategy document feels responsible. It creates the sense of movement without requiring anyone to commit to a specific change, in a specific team, with a specific result that could visibly fail.

The teams getting real value from AI tend to have done something much less impressive. They picked one piece of work that was slow, boring or error-prone, tried a small tool against it, kept it if it helped and dropped it if it did not. The learning came from contact with a real problem, not from a planning cycle.

The strategy-first instinct, and why it misfires

Strategy-first thinking assumes you can decide where AI fits before you have used it anywhere. With this technology that assumption rarely survives contact with reality. The useful applications are usually mundane and specific to how your organisation actually works: the shape of your inbox, the state of your data, the particular ways your processes leak time. None of that is visible from a strategy workshop. It is only visible up close, inside a workflow.

There is also a quieter problem. A broad strategy tends to generate broad projects, and broad AI projects fail in expensive, slow-motion ways. The scope is fuzzy, success is undefined, and by the time anyone asks hard questions there are too many people involved for an honest answer.

Start with one painful, measurable workflow. Earn the right to a strategy later.

Small and specific is not a lack of ambition. It is how you build the judgement that a sensible strategy would eventually need.

Finding the right first problem

You are looking for a workflow, not a technology. Some questions that surface good candidates:

• Where do capable people spend hours on work that feels beneath them? Re-keying data, summarising documents, drafting the same kind of reply again and again.
• What does the team complain about in the pub rather than in meetings?
• Where does work sit waiting? Long queues and slow turnarounds often hide a repetitive step nobody wants to own.
• What do you currently not do at all because it would take too long? Reading every customer reply, for instance, rather than a sample.

A good first problem has four properties. It hurts, so people care whether it improves. It recurs weekly or daily, so there is enough volume to judge results. It can be measured, even crudely, in hours spent or errors made or days of turnaround. And it is bounded: you can describe the input and the desired output in a sentence or two.

If a candidate problem fails that last test, keep looking. "Improve customer service with AI" is not a workflow. "Draft a first reply to routine delivery enquiries for a human to review" is.

What a bounded experiment looks like

The word experiment matters. This is not phase one of a programme, and it should not be resourced like one.

A reasonable shape: one workflow, one named owner who actually does the work today, a few weeks of elapsed time, and the smallest tool that could plausibly help. Sometimes that is an off-the-shelf product. Sometimes it is a thin piece of custom software around a language model. Occasionally it is a spreadsheet and a better process, which is a perfectly good outcome to discover cheaply.

Before you start, write down three things. The baseline: what the work costs today, measured however roughly. The success line: what result would justify rolling this out properly. And the kill criteria: what result, by what date, means you stop. Deciding the kill criteria in advance is what stops a mediocre pilot limping on for a year because someone's credibility is attached to it.

Keep the blast radius small. Run the new tool alongside the existing process rather than replacing it, use real inputs rather than sanitised demos, and keep customers out of the loop until the output has earned trust internally.

Evidence, guardrails and a human who owns the outcome

AI output is plausible by design, which means it fails politely. A wrong answer looks like a right answer wearing the same clothes. So the discipline that matters most is review: a named person checks the output, corrects it, and notices the patterns in what it gets wrong.

That person should own the outcome, not merely operate the tool. If the AI drafts a reply and the reply is wrong, it is their reply. This is not about blame. It keeps the accountability exactly where it was before the tool arrived, which is what makes it safe to move quickly.

Sensible guardrails for a first experiment are mostly boring ones. Be clear about what data goes into which tools, and check that against your privacy obligations before you start rather than after. Keep the tool out of irreversible actions: drafting is fine, sending is not, at least at first. And log what the tool was asked and what it produced, so that when something odd happens you can find out why.

Signs AI is not the answer

Some problems look like AI problems and are not. Walk away, or fix something else first, when:

• The underlying process is broken. Automating a mess produces faster mess.
• Nobody can name the decision or task the AI is supposed to improve.
• The data the tool would rely on is wrong, stale or scattered beyond use. Cleaning it up is the real project.
• A form, a report or an integration would solve the problem more reliably for less money.
• The volume is tiny. If the task happens four times a year, the review overhead will exceed the saving.

Saying "not this, not yet" to a weak AI idea is a result, not a failure. It costs a few weeks and saves a programme.

Measure the boring things

Resist inventing an AI scorecard. Measure the workflow, using the same plain measures you would use for any operational change: hours spent on the task, error or rework rate, turnaround time from request to done, and whether the people involved would fight to keep the tool if you took it away. That last one is the most honest signal you will get.

Measure the baseline before the experiment starts. Numbers collected afterwards, from memory, will flatter whichever outcome the room prefers.

The strategy can come later

After two or three of these experiments you will know things no workshop could have told you: where AI genuinely helps in your organisation, what it costs to run properly, what your data can and cannot support, and how your people react to working alongside it. If at that point someone still wants to write a strategy, good. It will be short, specific and grounded in evidence, which is to say it will be an actual strategy.

Most teams never need the document at all. They need one painful workflow made noticeably better, then another. The direction takes care of itself.