Sucked Into the Possibilities, Robbed of the Roadmap
About this series. I chose the name because it describes what I see. The possibilities and advances AI brings to individuals and organisations are real, and I have built programs on them.
At the same time, AI pulls people and organisations into a vortex: an endless supply of new ideas, new possibilities, and new things to do, moving faster than a roadmap can keep up with. Organisations get sucked in, lose their footing, and get carried along by whatever the technology can do next.
For the last 5 years I have worked inside that vortex, deeply embedded in organisations rather than advising from outside them, on AI transformation programs that integrate AI with human potential. The work has spanned multiple organisations and problem sets: specialised deployments and enterprise portfolios, single agents and agentic autonomous systems, and most of what lies between them.
It has also run end-to-end, from AI strategy through to implementation, on budgets ranging from 1 million to 350 million dollars, delivering returns from 1.5x to 10x. The organisations have ranged in size from 1,000 to more than 10,000 people across aviation, energy, sports, asset management, facilities management, supply chain, and consumer goods and retail.
This series is what that work has taught me, in 4 parts.
Part 1, this one, covers the pull itself: why the possibilities crowd out the grounded roadmap, and the pattern of playing too big or too small.
Part 2 covers the decision most organisations skip: what you need AI to solve, and why that one answer sets the design, structure, talent, budget, and governance.
Part 3 asks who decided that more productivity was the aim, and what employees hear when it is.
Part 4 covers the expensive, common mistakes and what overreliance is doing to thinking within organisations.
Each part stands on its own, so read them in any order.
In the invite-only conversations I sit in, where organisations compare notes on how their AI programs are going, 2 things are on the table in almost every one. The possibilities keep multiplying, and the return is hard to prove. Some of those organisations implemented badly and recovered, some implemented well and are reaping the benefit, and a surprising number are somewhere in the middle, spending real money and unable to say what it bought them.
The same pattern shows up in the programs I lead. A capability arrives, a use case follows, a pilot starts, and by the time the pilot reports, newer capabilities have arrived with newer use cases attached. The organisation is in constant motion, and the roadmap is being rewritten by technology rather than by the business.
TL;DR
The vortex is real. AI supplies possibilities faster than an organisation can decide which ones matter, and the deciding gets displaced by the doing.
The cost compounds. Early decisions on purpose, ownership, and design set the terms for every build that follows, and unwinding them costs more than getting them right.
Most organisations play too small. Too small has nothing to do with budget. It means using AI in pieces, at a fraction of what it can do, as an add-on rather than a capability.
Done right looks different. A grounded roadmap, a first build that makes the second cheaper, and a decision about what AI is for before a decision about which AI to buy.
What are you measuring new AI capability against?
The pull works through supply, and the supply does not run out.
Every new AI capability arrives with a plausible use case attached. The organisation that says yes to each one is not being reckless. It is responding to something useful, over and over, faster than it can assess what it already has.
Most organisations do have an AI roadmap, so the question is not whether one exists. It comes apart because the roadmap is built for a narrower future than the one the organisation is heading into, and because it sits in pockets of the business rather than across it.
An incomplete roadmap has 3 characteristics. It covers the parts of the business that moved first and leaves the rest to catch up, and it is written against today's maturity rather than the maturity the organisation is targeting.
It also treats AI as an add-on rather than a capability, so it reads as a set of initiatives to be delivered, and nothing in it describes what happens after each initiative is delivered. An add-on sits beside the business. A capability amplifies and improves what the business can already do.
I have seen this across specialised deployments in a single function and across enterprise portfolios running in parallel, and the size of the program does not protect against it. A roadmap in that condition cannot absorb new capability, so new capability starts setting the priorities instead. What the technology just made possible moves to the top, what the business needs comes second, and the organisation becomes dependent on the next release to tell it what to do.
This is how an organisation loses its footing without noticing. Each decision looks reasonable on its own, and the sequence is the problem: the possibility arrives first, and the question of whether it is the most impactful thing to do arrives second, if at all.
📍 When done right, this is what it looks like
The roadmap is written from the business problem outward. The starting question is which 2 or 3 outcomes matter most this year, and AI is assessed against those, in that order.
The roadmap is integrated across the business, not held in the functions that moved first. Every function knows where it sits in the sequence and what it is waiting on.
The roadmap is written against the targeted maturity, not the maturity in place today. It names the gap between the 2 and what closes it.
New capabilities are added to a holding list with a review date. Something arriving this month does not automatically reorder the plan. The review date is when the plan can be changed.
📍 The questions to ask when a new AI capability is put in front of your leadership team
Which business outcome on our roadmap does this move, and by how much?
Does our current foundation support this, or does this require the foundation to change first?
If we say yes to this, what are we saying no to or delaying, and is that trade worth making?
Count how many AI initiatives started in the last 12 months because a capability became available, against how many started because a business problem demanded it. That ratio tells you how far into the vortex you are.
Do it right the first time, or pay compounded interest
The first build sets the terms for all subsequent builds.
Early decisions in AI compound. The purpose you choose, the data you build on, the governance you put in place, and who owns the work are all inherited by the next build and the one after that.
Get them right, and each build makes the next one cheaper. Get them wrong, and you pay interest on the mistake with every new use case, until the organisation is spending money to work around its own foundations.
The programs I have worked on that recovered well were the ones where someone had made those 4 decisions deliberately at the start, even when the first use case was small. The ones that cost the most to unwind were the ones where the first build was treated as an experiment and then quietly became the platform.
The evidence that this happens often is now hard to dispute. Gartner reports that more than 50% of generative AI projects were abandoned after proof of concept by the end of 2025. The reasons it lists are data quality, risk controls, cost and unclear business value.
BCG's 2025 study of 1,250 companies found that 60% report no material value from their AI investment, with only 5% creating value at scale.
Those 2 sets of numbers describe the same thing from different ends. The compounded interest shows up as abandoned projects in the first and as budget spent with no return in the second, and both trace back to decisions that were rushed or skipped at the start.
The stakes are higher than a wasted budget line. The organisations getting this right are building a positioning and competitive advantage the rest will find expensive to match, and the gap is widening while the rest are still deciding.
"We had to move. Waiting for the perfect plan would have cost us more." I agree, and moving was the right call. The organisations doing well did not wait either.
What separates them is what they decided before they moved: what AI is for in this business, whether it is being built as a capability or added on to what exists, and who owns it. Those decisions are the difference between a first build that makes the second cheaper and a first build that has to be paid for twice.
📍 When done right, this is what it looks like
The first build is designed to be inherited. Data, governance, ownership and the definition of value are settled before the first use case goes live, because the second use case will run on them.
Value is defined at the point of investment. The question of what this returns, and how the organisation will know, is answered before spend, in the business case, in the organisation's own terms.
Something to consider: if the current AI initiatives were paused today, which of them would have a defined value they could already demonstrate? Anything that cannot answer that has been funded on assumption.
Too big, too small, and mostly too small
Too small has nothing to do with budget. It means using AI at a fraction of what it can do.
Almost every organisation I see is playing either too big or too small, and most are playing too small. Too big means an ambition that is unrealistic for the organisation. AI can do it, and the question is whether this organisation can, given where it sits today and the quality and integrity of the assets on which the AI would be built.
Too small is the more common pattern, and it is the one that surprised me. I expected to find it in smaller organisations with smaller budgets. I have found it just as often in large organisations running significant AI spend across multiple business units.
"Too small" describes the thinking rather than the size of the organisation, the size of the budget, or the number of people the implementation affects. It means using AI at less than 10% of its potential, in bits and pieces, for some people and some places. The organisation treats it as an add-on to what exists rather than as a capability it is building.
An add-on gets a budget line and a go-live date. A capability gets an owner, a design, a way of evolving and a place in how the organisation works.
In the invite-only conversations I sit in, the reasons come down to 3:
That is all they want. The organisation asked for a modest result, got a modest result, and considers that a lot. The program has not been asked to describe what the other 90% would look like.
Fear of a bad implementation. AI spend with no provable return has a reputation now, and leaders have seen it up close. Playing small feels safer than being the next example.
Get on the bandwagon, think later. Tick the box with the board, show that the organisation is doing AI, and work out what it is for afterwards. Of the 3, this is the one that does the most damage, because it postpones the decision everything else depends on.
The research describes the result of all 3 at scale. MIT's Project NANDA found that more than 80% of organisations have piloted general-purpose tools such as ChatGPT.
The same study found that 95% of generative AI pilots delivered no measurable impact on profit and loss. Most of those pilots improved the speed at which individuals worked while leaving enterprise results unchanged.
McKinsey's 2025 State of AI survey found that 88% of organisations use AI in at least 1 function. Only 39% of them report any effect on EBIT at all, and for most of those the effect is under 5%.
Usage is high, and Transformation & Adoption are low, which is what "too small" looks like when you add it up across an economy.
📍 When done right, this is what it looks like
The organisation can describe the 90%. Someone senior can say, in plain language, what AI would be doing in this business if it were a capability rather than an add-on, even if the plan is to get there in stages.
Small starts are deliberate, with a compounding path. Starting in 1 part of the organisation is a good way to start. The difference is whether there is a designed path from that part to the next, or whether the pilot is the plan.
Something to consider: ask the sponsor of each AI initiative what the initiative is for, in 1 sentence. If the answer is a tool name or a productivity figure, the initiative has been sized too small.
The takeaway
Avoiding AI is the wrong response to the vortex. The right one is to decide what AI is for before deciding which AI to buy, and to write the roadmap from the business outward rather than from the capability inward. The organisations that hold their footing are the ones whose roadmap is complete enough, integrated enough across the business, and written against the maturity they are targeting, so it can absorb what arrives next.
The leaders within them who can distinguish between an add-on and a capability are the ones executives come to first and the ones the organisation values when the next big decision has to be made.
Where is your organisation playing right now, too big, too small, or somewhere it can describe in 1 sentence?
Next in the series: Part 2 covers the decision most organisations skip, what you need AI to solve, and the 5 categories I use to make that call.
Find out where you are sitting today
The AI Transformation Leader Scorecard scores you across 10 areas of AI transformation leadership: AI strategy, proof of concept design, governance design, stakeholder navigation, vendor navigation, adoption and workforce, your own AI transformation skillset, your professional positioning, and AI maturity.
You get a scored read on each area, so you can see which parts of your AI transformation are solid and which parts are carrying the most risk, before the next decision is made.
https://www.futurefitleader.com/ai-transformation-leader
Go deeper on AI transformation
The AI Transformation Masterclass is the practical version of what 5 years inside AI transformation has taught me, across specialised deployments and enterprise portfolios.
It covers what AI is and is not, how to decide what AI is for in your organisation, and the use cases that hold up over time. It also covers how to meaningfully get into the AI conversation in your business, rather than at the edges.
Check out the details here: https://www.tl-institute.com/c/ai-transformation
