The eight pieces of an AI strategy

Companies come to us wanting help with their "AI strategy and implementation." At a high level I know what they mean. What surprised me at first was how often the leadership team could not say what the finished output was supposed to contain.

The ask usually traces back to a board mandate along these lines:

• Step 1: implement AI
• Step 2: ???
• Step 3: profit (or, more often, dramatically increase EBITDA)

The AI strategy is supposed to be Step 2. So here is what we think goes in such a strategy.

Note 1: If you're a smaller company just starting out - don't be intimidated, you don't need all of these pieces to get going! In fact, smaller companies can lean into their strength of agility: start with just a couple of the "roadmaps" mentioned below to get going, and then as you go, it'll become clearer which of the other pieces you need next.

(One scope note before the rest: this is about using AI to improve how your own company runs. Putting AI into the product or service you sell to customers is a product strategy question.)

What the finished thing contains

Eight pieces. Four roadmaps, which are the substance of what you are going to do, and four enablers, which decide how successfully the AI you build or implement gets adopted by your team.

Most of the strategies I have been shown contain some of the top half and none of the bottom half. That is enough to get started, but the enablers can quietly provide a strong tailwind or headwind for your efforts.

The four roadmaps

These are the actual projects that you'll do, each project being a build, an implementation, a training, etc.

• Functional roadmaps. One list per function - sales, finance, operations, support, and so on - of candidate projects, ranked roughly by impact against complexity.
• The company-priority roadmap. The handful of those that leadership needs to stay close to rather than delegate.
• Data and infrastructure. The shared plumbing that several of the functional projects would all benefit from.
• Upskilling. Getting everyone competent with the tools, running alongside the other three.

The next two sections go into how to actually put each of these together, starting with the functional roadmaps because they do most of the work.

Building the functional roadmap

Pulling together a roadmap sounds like an intimidating project that requires significant product management expertise, but it's something that any team can tackle. Here's one solid, basic approach to it.

Convene a working session per function. Get a mix of levels and seniority, and lean toward the people who are already curious about AI. You may need to open with a short tour of what AI tools can do, both in their function and in others. Then it's a brainstorm where you want volume - at this step, no idea is dumb or too big or too crazy, you want quantity, don't worry about quality.

Run some structured interviews in parallel. Ask people in that function: What do you spend your time on? Which manual processes are the most annoying? If you could wave a magic wand, what would go away? You don't need to get into the weeds on any one workflow yet; you're building hypotheses about where the impact might be.

A worry we hear a lot is that people will hold back because they think you're trying to automate their job away. I've found that happens occasionally, but most people just want the annoying parts of their job to be less annoying, and they'll tell you exactly which parts those are.

Then run down your list and give 1) rough impact estimates and 2) rough complexity estimates to each project. Managers and functional leaders can usually eyeball impact on their own, drawing on their sense of what will actually move the needle versus not. Complexity often takes a short conversation between the functional lead and somebody more technical from outside the function. These two estimates essentially give you a rough sense of ROI for each idea. You can rank your roadmap projects by ROI, but treat that ranking as an input rather than as your strict execution order, because things like knocking out dependencies first, harvesting easy wins earlier, and having uneven bandwidth across teams will all influence the ordering of projects, and that's fine.

One thing to remember throughout all this: the biggest gains rarely come from bolting AI onto the way you do something today. They come from asking what the workflow would look like if you designed it from scratch around what these tools can do now. That's a question worth asking on at least a few of your candidates.

Building the other three roadmaps

The functional roadmaps do most of the heavy lifting, and the good news is that once you can see them side by side, two of the remaining three come together more easily. The third runs alongside everything else.

The company-priority roadmap

Lay the functional roadmaps next to each other and ask a different question of the pile: of everything on these lists, which few things does the company most need to get right?

Often that's just your top-ROI items, but not always. Something can earn a place here for strategic or longer-term reasons even if the near-term math doesn't put it near the top. Pull those out into a separate, deliberately short list. If a dozen things are company priorities, none of them are.

What makes this list different from the others is the attention and the resourcing behind it. These are the ones leadership stays close to instead of handing off and reading a biweekly status update. For each of these important projects, settle three things up front: who's running it week to week, who's on the hook for whether it actually delivers, and how often it gets reviewed. The first two are frequently different people, and it saves a lot of confusion later to name both.

The data and infrastructure roadmap

This one also comes out of reading the functional roadmaps as a set, though it's worth having somebody more technical do that reading. What they're looking for is "platform-level" patterns: the same underlying need showing up behind three different teams' projects. That's your shared plumbing.

The question this roadmap answers is what you'd have to build for your company's AI to be capable of more than it is today.

Early on the answers are often unglamorous, and are things you may have been meaning to do anyway: getting data out of places it's stuck, cleaning up what comes out. Later it can turn into something more deliberate, like assembling a shared pool of company context that everything else can draw on. Some companies also end up wanting infrastructure of their own, for reasons that are specific to them, e.g. keeping tighter control of governance, managing cost at volume, or an operating quirk no vendor is going to accommodate.

Of the four roadmaps, this is the one that companies without internal tech talent often unknowingly skip; even without it, you can still do a lot of valuable AI work, but you might find yourself hitting a ceiling or recreating the wheel between different projects.

The upskilling roadmap

This one runs sideways across the company rather than focusing on a function. The aim is to spread the ability to work with AI to everyone, not just the people who were going to find it on their own.

You can build it in parallel with everything above, and here's the reassuring part: it looks broadly similar from company to company, so you're not inventing it from scratch the way you are with the functional roadmaps. Usually it means broad access to the general tools (Claude, ChatGPT), training on chat and something more agentic like Cowork or Codex, and an introduction to connectors and skills. Aim to get everyone to at least L2 on the adoption ladder; getting to L3 and a shared skills library generally takes a hand from a tech team or an outside partner.

Even though it runs in parallel, the timing should still be informed by the functional roadmaps. If operations is going to start executing on their functional roadmap in Q2, that's when operations should be trained, not six months earlier.

Aim to do this across the whole company, though which tools you train on (e.g. Claude Chat vs Cowork) and how deep you go on those tools can vary depending on function.

Don't wait for the roadmap to be finished

Building a roadmap doesn't mean you have to wait for it. While it's coming together, grab two or three obvious, low-hanging-fruit wins and hand them to whoever at your company already builds things for themselves.

The point isn't really the time saved, it's the case studies. Words like "automation" and "efficiency" sound good in a meeting but often team members don't tangibly understand what you mean; a concrete example from inside your own company is something people can picture. You'll also flush out the infrastructure speedbumps worth fixing before everyone else piles in, which is much cheaper to learn now than later.

The four enablers

These are the ones that tend to get left out. Each of them deserves its own piece, so here they are at a high level:

• Change management. This is where AI projects most often stall. It tends to be under-appreciated at smaller companies, where people assume a smaller team makes it easier, and our experience has been the opposite. It's worth having a healthy wariness of change management: it often is harder than you expect. Plan for it deliberately, and give each project a named owner. If your company hasn't run big workflow changes before, expect to try a few tactics before you find what works for your team.
• Culture. Especially at older companies, bigger companies, or companies in slower-moving industries, you may need to shift the culture toward one that treats the current way of working as changeable rather than settled. This is easier said than done! One thing seems very clear when we look across companies: leadership has to use these tools themselves, and do it publicly. A leader who pushes everyone else to adopt AI while not touching it gets seen through almost immediately, and the whole effort loses credibility with them.
• Security and governance. Experimentation benefits from being liberal with data access, and for many companies that just isn't reasonable. So treat these as dials to tune rather than boxes to check, and decide deliberately how open or conservative you want to be. (And it's worth asking whether a company-wide AI push is a chance to turn that dial a notch or two more open.) Then build the setup so your team can experiment safely within those bounds.
• The story. The narrative leadership tells the company about where this is all going and why. It sounds simple, but it's deceptively hard to do well. "We're implementing AI" isn't a story. It needs to be specific to why this company is doing this and what it hopes to get out of it, and ideally it doesn't just revolve around increasing EBITDA - as lovely as that sounds to investors, it isn't the most motivating thing for everyone else. Everyone needs a why they can hold onto and repeat in their own words.

A few more things that belong in the document

These are closer to hygiene and are hopefully obvious, but they go missing often enough to be worth listing:

1. Some way to measure whether initiatives actually delivered the ROI you projected. And if one didn't, why not, and is it worth iterating on?
2. A review cadence for the roadmaps and for the strategy overall, because what's possible shifts every few months. All four roadmaps are living documents rather than one-time artifacts.
3. Budget and resourcing, which should feed back into how you rank things. What gets funded centrally versus out of each function's own budget?
4. Real input from a few middle managers and some of the subject-matter experts closest to the work, because that's where the best functional-roadmap ideas actually live. (An outside partner can help here too, though I'm biased on that one!)

What you get out of it

It's worth closing on the two ways a company-wide AI transformation push tends to go wrong, because the eight pieces are shaped to avoid both.

At one end is "let a thousand flowers bloom": hand everyone the tools, tell them to go find efficiencies, and trust that the good automations will out-compete the bad ones on their own. In practice there's no coordination, nobody knows what anyone else is building, the same automation gets reinvented five times, and the potential wins that do appear tend to stay stuck on the laptops of whoever built them.

At the other end is one centralized, strictly stack-ranked roadmap that you work through in order, one initiative at a time. Now you have coordination, but at the pace things are changing, a single queue is far too slow. It also concentrates your risk, since one of the first couple of projects failing is a much bigger blow to the whole effort.

The eight pieces are how you strike the right balance. You get enough central direction that the work adds up to something, and enough parallelism that your company can move with deliberate speed.

You know your company best, and a lot of this is work you can do in-house. However, if you'd like a helping hand, send us a note, we're happy to chat.