An issue I see organizations running into with AI transformation is that they mistakenly think AI transformation is one thing.

In fact, most of the conversations around transformation seem to collapse three different kinds of work into one vague mandate: “We need to do something with AI.”

But AI transformation is not one thing. It has three parts:

1. Strategy: What should change, and why?

2. Implementation: How will people, teams, workflows, and governance change around it?

3. Product Development: What should we build, buy, borrow, or integrate to make the change scalable?

For a transformation to be successful, all three of these parts must be present. Strategy without implementation is theory. Implementation without strategy is random AI activity. Product development without strategy and implementation is expensive software in search of a problem.

The companies that make real progress are the ones that understand this from the start. They know what they are trying to change. They understand that the organization needs to work differently. And they know that technology can help, but only if they have first created the conditions that allow the technology to help.

The work can overlap, but the logic has to move in order. Strategy defines the change. Implementation makes the change real. Product development makes the change scalable.

Strategy Defines the Change

Strategy is where the organization decides what AI is actually for. Not in general, but specifically. Which parts of the business should become faster? Which decisions should become better? Which workflows should change? Which capabilities should the company build? Which risks need to be managed? Which opportunities are worth pursuing first?

Without that clarity, every AI conversation becomes a conversation about tools instead of a conversation about the business. The strategy phase is about foresight. It's about thinking through what you want the organization to become and why. It's also where leaders have to make choices because not everything should be automated and not every use case is worth pursuing. The point of strategy is to create enough clarity that the organization can focus its energy on the changes that actually matter.

The Middle Part Is Usually What Gets Skipped

The most common mistake I see is jumping straight from strategy to product development. I can see why this feels like a reasonable action to take. After all, the promise of AI technology can at first seem like a panacea to everything that is ailing the organization.

But if the organization has not defined and then changed around the strategy, the product you build has very little to attach to. The data isn’t ready and the workflows are unclear. Governance is vague. Worse, the people closest to the work may not understand why the change matters, what role they are supposed to play, or how AI is supposed to help them do their jobs differently.

This is, fundamentally, not a technology problem. It's an implementation problem, which is maybe the least glamorous part of AI transformation, but probably the most important. That’s because this is where the strategy becomes behavior. It’s where leadership alignment turns into operating rhythms, policies, training, working groups, decision rights, use-case discipline, and feedback loops. It’s where the organization begins to develop the corporate hygiene required for AI to become useful at scale.

Without that middle layer, AI adoption becomes a collection of disconnected experiments. As I've written before, some of these experiments may be useful and some may even be impressive. But they do not add up to transformation because the organization itself has not changed.

Product Comes Last For a Reason

This doesn’t mean product development is unimportant. In many cases, product development is where the transformation becomes durable. A custom dashboard, an internal agent, a workflow automation, a knowledge system, or a new customer-facing tool can all create enormous value. But those products should emerge from a clear understanding of what the organization is trying to change and how the work needs to operate differently. If not, the company risks building the wrong thing.

That risk is higher now, too, because AI has made software easier to create. It’s possible to prototype an internal tool in days. But just because something can be built does not mean it should be built. The better question is: what has the strategy and implementation work taught us that now deserves to become a system?
Answering that question is how you build a better way of working that is repeatable, scalable, and easier to sustain.

Ultimately, this is why “doing something with AI” is not a strategy. It’s only the beginning of a much more important set of questions: What should change, what has to change around it, and what should be built only after those answers are clear?

That’s the real work of AI transformation. Not choosing a frontier model. Not launching a pilot. Not building something because it is suddenly possible to build it.

The work of AI transformation is deciding what should change, changing the organization around that decision, and then building the systems that make the new way of working scalable.