Most AI strategies fail in the same place. They produce a long list of things the company could build. Then everyone returns to their existing priorities.
I have seen this often enough that I no longer think the problem is a shortage of ideas. Most teams have more ideas than they can use. What they lack is a short path from knowing what should change to actually changing it.
This article explains why we start AI work with one real workflow instead of a strategy document, how to choose that workflow, and the four questions that tell you whether the first change is worth carrying forward.
Why AI Strategies Stall After the Idea List
A typical AI strategy process looks productive. Workshops collect use cases, someone scores them by impact and effort, and the result is a well-organised list. Everyone agrees it is a good list.
Then nothing moves. Not because people disagree, but because every item on the list has to cross the same distance: the gap between someone understanding a business problem and the organisation being able to change the work.
That distance is where the real obstacles live. Development queues that are already full. Systems that do not talk to each other. Unclear permissions about which data may go where. And very often, nobody who quite owns the result once the workshop is over.
A longer list does not shorten that distance. It spreads attention across more items that each face the same obstacles.
The long way runs through queues, systems and permissions. One bounded change, built with the people who know the work, takes the short way.
Start Smaller: Show Us One Workflow
So we start somewhere smaller. The first request is always the same: show us one workflow you want to improve.
Not a department, not a transformation programme. One recurring piece of work that gets stuck, costs your experts time, or depends on information that has to be rebuilt every time. Reporting that takes too long, knowledge trapped in an old system, or intake work that someone does by hand every week are typical candidates.
What we ask for
One workflow
A recurring task with a clear start and end, not a vague area of the business.
The people who understand it
The person who does the work, and the person who can decide about it.
Real examples
Actual documents, reports or cases from last month, not a description of how the work should go.
One bounded change
Something we build or test together, small enough to evaluate under real conditions.
Real examples matter more than most teams expect. A process described in a meeting is always cleaner than the process in practice. The exceptions, the workarounds and the one spreadsheet everybody quietly relies on only show up when you look at real cases.
The Four Questions That Decide What Comes Next
The goal of the first change is not to produce something impressive. Demos are cheap now. The goal is to find out four things.
Does it help under real conditions?
Test it on real cases, with the real people, in the real tools. A result that only works on the example we prepared together does not count.
Where does it fail?
Every AI-supported workflow has cases it handles badly. Finding them early is a result, not a setback. It tells you where a person has to stay in the loop.
Who reviews the output?
Someone has to be responsible for what comes out. If nobody can name that person, the workflow is not ready, however good the output looks.
Can the team carry it forward?
If the improvement only works while we are in the room, it is not an improvement yet. The people who own the workflow need to be able to run it, adjust it and explain it.
One workflow runs through four questions. What comes out is not a demo but a decision.
What One Working Improvement Gives You
That first working improvement does more than another strategy document. It gives the company three things a list of ideas cannot.
Evidence: you know whether the approach works on your data, in your tools, with your people.
An internal owner: someone in your team has built it with us, understands it and can defend it.
A practical next decision: extend it, adapt it or stop it, based on what actually happened.
The next workflow then starts from a different place. The team has seen how a change moves from idea to daily work, which permissions it needed and who had to say yes. The second improvement usually moves faster than the first, because the path has been walked once.
This is also how a real AI strategy emerges. Not as a document written up front, but as a sequence of decisions backed by evidence.
How to Choose Your First Workflow
If you want to try this with your own team, look for a workflow with these properties.
It recurs, weekly or monthly, so improvements add up and you can compare before and after.
It is painful for the people doing it, which makes them willing to help and to adopt the change.
The rule behind it can be described. If nobody can explain how the work is done, writing that down is the first step.
The data it needs can be reached without a long integration project.
Someone can own the result once the first version works.
This is also how we structure our own engagements. You can read more about it on how we work .
Moving Fast Means Shortening the Distance
Moving fast with AI does not mean pursuing every possibility at once. It means shortening the distance between knowing what should change and being able to change it.
So the useful question for a leadership team is not "what could we do with AI?" It is: where is that distance longest in our company, and which workflow sits right in the middle of it?
Frequently Asked Questions
- How do I start an AI strategy in a mid-sized company?
- Start with one recurring workflow that gets stuck, bring the people who understand it, and test one bounded change on real examples. Use the results to decide the next step. A strategy document is more useful after that first working improvement than before it.
- Why do AI strategies fail?
- Rarely for lack of ideas. Most stall because every idea has to cross the same obstacles: full development queues, disconnected systems, unclear data permissions and no clear owner. A longer list of use cases removes none of them.
- How big should the first AI project be?
- Small enough to test under real conditions with the people who do the work, and important enough that they care about the result. One workflow and one bounded change is usually the right size.
- Who should own an AI-supported workflow?
- The team that does the work, with one named person who reviews the output and one technical owner for tools and access. If neither can be named yet, clarifying that is the first deliverable.
How we work · Work · Insights