Why Your AI Roadmap Should Start With a Strategy Map, Not a Use-Case List

Most organisations approach AI planning backwards. They start with a list of what AI can do in their sector and work forwards, hoping relevance will follow. It rarely does. This paper argues for the reverse: start from the strategy map the organisation already has, or should build, and let the AI roadmap fall out of it. An AI opportunity is only ever right or wrong relative to a specific strategy, never in the abstract, and a roadmap earns a board’s confidence when it is governed by one named boundary from the outset, not by a risk appendix attached afterwards.
The list that answers the wrong question
Ask most organisations for their AI roadmap, and you get a list. AI for customer service. AI for fraud detection. AI for predictive maintenance. AI for underwriting. Every item is true in general and useless in particular, because it describes what AI can do in the sector, not what this organisation has decided to do. A list like this is easy to produce, easy to present, and very often ignored within a year, because nobody on the board can say which line moves which number, or who is accountable when it does not.
The list is not wrong because AI cannot do those things. It is wrong because it answers a question nobody asked. The question a board actually needs answered is not “what could AI do in our sector”; it is “where does AI make our specific strategy work better, and where must it never be allowed to touch”. A use-case list, however well researched, cannot answer that question, because it was never built from the organisation’s own strategic choices in the first place.
Two companies, one sector, opposite strategies
Here is the test I put to clients. Take two organisations in the same sector, competing for the same customers, and give them opposite strategies. One wins on being the cheapest, fastest, most automated option available. The other wins on scarcity, its culture, and the visible presence of a human expert at every point the customer touches the brand. Now hand both organisations the same AI capability: a model that can price, recommend or serve a customer without a person in the loop. For the first organisation, that capability is close to the whole point of the strategy. For the second, deploying it at the wrong touchpoint quietly destroys the thing the customer is actually paying for: personalised expertise.
A generic use-case list cannot tell these two organisations apart, because it was written before either of them existed. It has no way of knowing what is appropriate to support a specific strategy. This is the whole argument in one example: an AI opportunity is not intrinsically good or bad, useful or wasteful. It is only ever good or bad relative to your organisation’s specific strategy, and you cannot judge it without that strategy being in front of you.
Start from the map you already have
The alternative is to start from the organisation’s strategy map rather than a capability list. By strategy map I mean whatever a particular organisation uses to make its strategy explicit and shared: a strategy choice cascade setting out where it will play and how it intends to win, a canvas of how it creates and captures value, a picture of what it treats as differentiating versus commodity, and an honest account of whether its operating model can actually deliver on the claim it is making to customers. The specific tools matter less than the discipline: write the strategy down so employees understand it, and in language specific enough that a competitor reading it could disagree. If that map does not exist yet, build it first, even in outline. An AI roadmap built before the strategy map exists is not a roadmap. It is a wishlist with a technology label on it.
Once that map exists, the AI question changes shape. It stops being “what could AI do here”, a question with hundreds of equally plausible answers, and becomes “where, on our own map, could AI sense something earlier, or optimise a decision we already make”, a question with a handful of answers you can actually defend. Every real opportunity ties to a named box on the map: a metric in the winning aspiration, a control in the management system, a stream in how value actually gets delivered. Anything that cannot be tied to a box on the map is not yet an opportunity. It is still a category.
Name the boundary before you name a single opportunity
The second discipline is sequencing, and it is the one most roadmaps get backwards. The usual order is: generate a list of exciting opportunities, then attach a governance section afterwards to make the list acceptable. That order guarantees the governance section reads as a caveat, because by the time it is written, the opportunities are already chosen and the incentive is to explain them away rather than to constrain them.
Reverse the order instead. Before a single opportunity is written down, name the one thing about the way this organisation wins that AI must never be allowed to quietly undermine. Call it the governing tension, or the AI boundary. It comes directly out of the organisation’s own strategy: its how-to-win statement, its brand promise, or the control at the centre of its management system. It is not a generic AI-risk checklist copied from another engagement, and the test for whether it is specific enough is simple: could a competitor’s AI roadmap use the same sentence unchanged? If yes, it probably needs sharpening.
Three brief, illustrative examples show how differently this boundary lands depending on the strategy behind it. For a regulated insurer whose whole promise rests on fair, explainable pricing, the boundary is regulatory fairness: AI may recalibrate risk continuously, but it must never erode the fairness of a renewal decision a customer can query. For a luxury goods house whose value depends on scarcity and the visible presence of human craft, the boundary is authenticity: AI can inspect materials and forecast demand, but it must stay invisible at every point a client actually touches the product. For a heavy equipment manufacturer selling autonomous machinery into safety-critical sites, the boundary is trust in the human override: AI can detect a failure pattern earlier than any person could, but the decision to widen what the machine can do alone always escalates to a named person. Same underlying claim in every case: that AI is a sensing and optimisation layer, not a decision-maker in its own right, and three completely different lines drawn around what that layer may touch.
A six-step method: from map to governed roadmap
Put those two disciplines together, map first, boundary before opportunities, and a six-step method emerges. I use this with clients to turn a completed strategy map into a roadmap a board will actually fund.
Step | Move | What it does |
1 | Start from the completed map | Ground the whole exercise in the strategy map that already exists, or build it in outline first. No map, no roadmap. |
2 | Name the boundary (s) | Before any opportunity is written down, name the one thing, or things, about how this organisation wins that AI must never quietly undermine. |
3 | Walk the map for sensing and optimisation | Go through every box and value stream and ask only two questions: could AI sense a signal earlier here, or optimise a decision we already make? |
4 | Tie each opportunity to a number | Force every surviving idea to name the specific metric on the map it moves, the operational change required, and who owns that metric today. |
5 | Filter through the boundary | Test every opportunity against the named boundary. Redesign it so it cannot cross the line, or drop it. The boundary is a guardrail, not a footnote. |
6 | Sequence by readiness and proximity | Start where the underlying AI capability is already live or governed, and where the metric it moves is already on the board's own scorecard. |
The pattern holds regardless of sector. In every engagement I have run this on, the first phase of the roadmap never turns out to be the opportunity with the largest headline number. It is the one closest to a capability the organisation already trusts, moving a metric someone already watches. That is what makes it fundable: nobody on the board has to take a leap of faith on both the technology and the number at the same time.
Why this produces roadmaps that survive board scrutiny
A use-case list survives a first read and rarely a second one, because nothing in it can be defended under questioning. Ask which strategy an item serves, which metric it moves, or what it is not allowed to touch, and the list has no answer, because it was never built to have one.
A roadmap built the other way round survives that questioning, because every item on it already carries the answers. It ties to a named box on the organisation’s own strategy map. It is filtered through a boundary specific to how that organisation wins, stated in its own words before any opportunity existed to argue for. And it is sequenced by proximity to what the organisation can already deliver, not by which idea sounds most impressive in the room. That is a roadmap a chief executive can defend to a board, a regulator, or a customer, in that order, because it was never separable from the strategy in the first place. It is not a technology plan with governance attached. It is the strategy, extended.
From map to alignment: the harder half of the work
Naming the boundary and tying each opportunity to a number is the analytical half. The harder half is getting a board, a regulator and a customer to accept the line you have drawn, in that order, because a roadmap only survives if the people who fund and govern it stay aligned behind it. That is a discipline in its own right, and it is exactly what my Strategic Stakeholder Engagement for Organisational Transformation course with Informa Connect Academy is built to develop: how to read the power structures and informal networks a strategy really moves through, build coalitions across competing interests, and communicate a decision so stakeholders interpret and act on it as intended. The map tells you where AI belongs; stakeholder alignment is what gets the roadmap funded, governed, and adopted once it leaves the room.
If your organisation already has a strategy map and wants help turning it into a governed AI roadmap using this method, or needs help building the map first, I would be glad to talk it through.
Jonathan Ward
Course Director at
Informa Connect Academy
Email: meenquiries@informa.com