Stop Making AI the Strategy

I have seen some version of this movie throughout my career.

An executive attends a conference or trade show and comes back energized by a technology everyone seems to be talking about. There is a new platform, methodology, architecture, or capability that promises to change the industry, and suddenly the organization needs a strategy for it. Meetings are scheduled. Teams are asked how they plan to use it. Roadmaps acquire new initiatives. Before long, people across the company are searching for opportunities to demonstrate that they are embracing the future.

Some of those technologies became important. Others found useful but narrower roles. Quite a few faded from the conversation when the next shiny object arrived.

I want to be very clear that I do not put artificial intelligence in that last category. AI is different. I believe it represents one of the most consequential changes to software and knowledge work that I have experienced in more than three decades in technology. The capabilities will continue to improve, the economics will continue to change, and AI will become increasingly embedded in our products and in the way organizations operate. This isn't going away.

What feels familiar is our response to it.

The same enthusiasm that once sent executives home from conferences asking where we could use the latest technology is now producing mandates to "do something with AI." Boards want to know the AI strategy. Product leaders are asked where AI appears on the roadmap. Departments launch pilots. Vendors demonstrate agents and copilots. Innovation teams hold hackathons and produce impressive prototypes. Everyone understandably wants to make sure they are not left behind.

The problem begins when adopting the technology becomes the objective.

When the Technology Becomes the Strategy

There is an old saying that when all you have is a hammer, everything looks like a nail. AI may be the most capable hammer we have ever been given, but that still does not mean everything is a nail.

When an organization begins by asking where it can use AI, it has already constrained the solution before it has fully understood the problem. The question assumes that AI belongs somewhere in the answer. Teams then begin searching for problems that fit the technology rather than understanding important problems and determining the best way to solve them.

That can produce a tremendous amount of activity without producing much meaningful change.

A customer experience does not necessarily improve because a chatbot has been added to it. A product does not become more valuable because it has a copilot. A business process does not become strategically important because an agent can perform it. In some cases, these will be excellent solutions. In others, we may simply be applying sophisticated technology to something that wasn't particularly valuable in the first place.

The starting point should be the outcome.

What are we trying to change? What is preventing that outcome today? What do we believe would change it? How cheaply and quickly can we test those beliefs?

Only then should we determine what to build, if anything.

The answer might involve generative AI or an agent. It might require traditional software development. It might be a combination of the two. Or the best answer may turn out not to be a technology solution at all. Better onboarding, clearer documentation, a redesigned process, or removing an unnecessary step might produce more value than anything we could build.

The objective isn't to find a place for AI. It is to produce the outcome.

Faster Is Useful. Different Is More Interesting.

Much of the first wave of AI adoption has understandably focused on productivity. Developers can write code faster. Product managers can synthesize research faster. Marketers can produce content faster. Support teams can resolve certain issues faster. Organizations can perform work that previously consumed hours in a fraction of the time.

There is real value in that. I use AI this way myself, and the productivity gains can be extraordinary.

But there is a danger in measuring the opportunity primarily by how much faster we can perform the work we already do. Doing so quietly assumes that the existing process is the right process and that our goal should be to accelerate it.

Sometimes that is exactly what we should do. Sometimes we are simply making an obsolete process more efficient.

The more interesting question is what we would design if we were starting today.

Consider one of the original promises of Agile: small, empowered, cross-functional teams forming around important work and taking responsibility for delivering an outcome. The idea was compelling, but the reality inside many organizations never fully matched the promise. Specialized skills, technical architectures, organizational boundaries, dependencies, and handoffs made truly autonomous teams difficult to achieve. A seemingly straightforward customer problem could require coordination among front-end engineers, back-end engineers, data specialists, infrastructure teams, designers, product managers, and others before anything meaningful reached a customer.

AI is beginning to change some of those constraints. As the technology increasingly abstracts portions of the underlying technical stack and allows people to operate effectively across domains that once demanded deeper specialization, the boundaries around what a small team can accomplish begin to move.

The interesting opportunity isn't merely that every specialist can complete their part of the existing process faster. We can begin asking whether the process, team structure, and division of responsibility should exist in their current forms at all.

That is transformation. And it starts by reconsidering the work, not by adding AI to it.

The Constraints Have Changed

AI also changes the economics behind many decisions organizations have historically made.

There are things we have known would be valuable for years but could not justify economically. Highly individualized customer experiences are an obvious example. So is analyzing enormous volumes of qualitative customer feedback, rapidly prototyping multiple solutions to a problem, or building software for narrowly defined workflows that would never have justified a traditional development investment.

As the cost of creating, analyzing, experimenting, and personalizing falls, some of those old assumptions deserve another look.

I have written about this before, so I won't belabor the point here. What matters strategically is that AI doesn't simply give us another set of capabilities. It changes some of the constraints under which previous strategies, processes, and organizational structures were designed.

That should cause us to revisit the design, not merely bolt a new capability onto it.

AI-First Is the Wrong Goal

There is a temptation right now to describe companies, products, and strategies as AI-first. I understand what the phrase is trying to communicate, but I think it points organizations in the wrong direction.

I would rather be outcome-first.

Start with something meaningful that needs to change. Understand the problem well enough to form hypotheses about what might change it. Find the fastest reasonable way to test those hypotheses. Create something real when doing so will generate better evidence. Learn from what happens. Then use that evidence to decide what comes next.

AI dramatically expands the set of things we can try within that process. It allows us to explore more possibilities, build experiments faster, analyze evidence at a scale that was previously difficult, and sometimes solve problems in ways that would have seemed unrealistic only a few years ago.

But it doesn't relieve us of the responsibility to understand the problem.

In fact, as building becomes easier, that responsibility becomes more important. When the cost of creating something falls dramatically, the temptation to create the wrong thing rises with it. A team can now produce an impressive prototype before anyone has stopped to ask whether the underlying problem is worth solving.

Speed is only an advantage when it helps us learn what matters.

Eventually, the AI Strategy Should Disappear

For many organizations, having an explicit AI strategy makes sense right now. Leadership teams need to understand the technology. Organizations need appropriate governance. Employees need new capabilities. Companies need space to experiment with rapidly evolving models, tools, and ways of working. Ignoring AI because we don't want to chase a trend would be every bit as misguided as adopting it indiscriminately.

But I don't believe a separate AI strategy should be the permanent destination.

As AI becomes embedded throughout products and operations, it should increasingly disappear into product strategy, business strategy, customer experience, and the operating model itself. We should reach a point where asking for the AI strategy sounds a little like asking for the company's internet strategy. The technology will matter enormously, but it will matter because of what it enables.

That is also why I believe the larger conversation about AI eventually becomes a conversation about how organizations operate. If the cost of experimentation changes, if small teams can accomplish more, if evidence can be gathered and synthesized faster, and if previously uneconomical solutions become practical, then the way we decide, build, organize, and learn should change with it.

That is a much more interesting challenge than finding another place to put a chatbot.

AI deserves the attention it is receiving. Leaders should be experimenting aggressively, learning what the technology can do, and questioning assumptions that may no longer be true. But adopting AI is not an outcome, and the number of AI initiatives underway is not a particularly meaningful measure of transformation.

The technology is extraordinary. The opportunity is even bigger than the technology itself.

The question isn't where we can use AI. It is what we should do differently now that we can.