Insights

AI Strategy Shouldn’t End With a Plan. It Should End With a Product

Team working on an AI product strategy and building a working product

Strategy has traditionally happened before the building starts. Teams research the market, understand users, define the opportunity and decide what should be built, before handing the outcome over to design and engineering to turn into something real.

That separation has always had limitations, but AI makes it increasingly difficult to justify. The technology is changing quickly, new capabilities can fundamentally alter what a product could be and something that sounds compelling in a workshop can behave very differently once people actually use it. There is only so much you can learn without building.

That is why we think building should be part of strategy, rather than simply the thing that happens once strategy is finished.

You learn differently when something is real

There are plenty of things you can establish without writing a line of code. You can understand the market, talk to customers, identify problems worth solving and develop hypotheses about where AI could create value. All of that matters, but eventually those hypotheses need to meet reality.

With AI products in particular, many of the most important questions only become visible when there is something people can actually use. A concept might make complete sense when described, but feel confusing when somebody interacts with it. An AI capability might perform impressively in isolation, but become less useful once it has to deal with the ambiguity and edge cases of a real customer journey. A workflow that looks efficient on paper might reveal a point where human judgement is essential.

Building gives you access to those questions much earlier. Instead of trying to predict how the product will behave and how people will use it, you can put something real in front of them and find out.

Technical feasibility isn’t the same as product validation

It has become remarkably easy to demonstrate what AI can do. Models can generate convincing outputs, interpret complex information, work across huge volumes of data and perform tasks that would have looked implausible only a few years ago.

But demonstrating a capability is different from validating a product. The important question is rarely just whether you can get AI to perform a particular task under the right conditions. It is whether that capability can become part of a product that solves a sufficiently valuable problem, works reliably enough in the real world and fits naturally into the way people behave.

That means testing more than the technology. You need to understand how people respond to the experience, what they trust the AI to do, where they want control and what happens when the output is uncertain or wrong. You also need to know how the product fits with existing systems and data and whether the value it creates is significant enough to justify further investment.

These aren’t questions that sit neatly on one side of a line between strategy and delivery. They are part of deciding whether the opportunity is worth pursuing in the first place.

Build to answer the important questions

The point of building during strategy isn’t to build everything. It is to build enough of the right thing to answer the questions that matter most.

If the biggest uncertainty is whether customers will trust an AI recommendation, build the experience that lets you test that interaction. If the value depends on turning specialist knowledge into something more widely available, build enough of the product to see whether that knowledge can actually be captured and used effectively. If the opportunity relies on changing a complicated customer journey, give people the new journey and see what they do with it.

Rather than being the eventual output of a long sequence of assumptions and decisions, the product becomes one of the ways those assumptions are tested and those decisions are made. Each iteration gives you more evidence. Some assumptions will prove right, others will change and occasionally the thing you thought you were going to build will turn out not to be the most valuable opportunity at all.

Finding that out during strategy is considerably more useful than discovering it after months of delivery.

The output should still be real

There is an important distinction between building to learn and building something disposable. Moving quickly doesn’t mean the output has to be a demonstration that gets thrown away once it has answered a technical question.

We think the better ambition is to emerge from strategy with an actual product: focused in scope, designed around a real problem, tested with real users and built to continue into the next stage of its development.

We recently built a working product for a client in the time we would normally have spent on a strategy phase. The response from people who saw it reinforced something important: the output of strategy shouldn’t need to be explained or imagined. It should be something people can react to.

That changes what happens at the end of the strategy phase. The organisation isn’t simply looking at a roadmap describing what could be built, or a demonstration showing what the technology can do. It has evidence about the opportunity, evidence from users and something real that has already begun to prove where the value lies.

If the evidence says the opportunity isn’t strong enough, that is useful too. The purpose of strategy isn’t to justify a project that has already been decided upon. It is to reduce the uncertainty around whether the organisation should continue investing, change direction or stop.

From AI ambition to something real

AI creates an enormous number of possible things to build, which makes choosing the right ones more important, not less. The organisations that get the most from it won’t necessarily be those that generate the most ideas or experiment with the most technology, but those that can identify where there is genuine value and learn quickly enough to concentrate investment there.

For us, AI-native strategy means bringing strategy and building much closer together. Research, commercial thinking and product thinking still matter, but they become more powerful when combined with the ability to make something, put it in front of people and use what happens next to inform the strategy.

Because when the question is whether an AI product deserves to exist, there comes a point where talking about it stops producing useful answers.

You have to build it to find out.

spread the word, spread the word, spread the word, spread the word,
spread the word, spread the word, spread the word, spread the word,
Team working on an AI product strategy and building a working product
AI

AI Strategy Shouldn’t End With a Plan. It Should End With a Product

Exploring what an AI-native business could look like when built around what AI makes possible.
AI

If you were building your business today, would it be AI-native?

Illustration representing AI software delivery, measuring outcomes, validation and engineering performance rather than development output alone.
AI

True Velocity: Measuring the Real Impact of AI on Software Delivery

Illustration representing AI-native product development, combining AI capabilities with traditional software through deliberate product design.
AI

Adding AI Features Doesn’t Make a Product AI-Native

Illustration representing AI software development, engineering expertise, context engineering and accountable decision-making.
AI

Own the Answer: Why AI Software Development Needs Engineering Expertise

AI Strategy Shouldn’t End With a Plan. It Should End With a Product

Team working on an AI product strategy and building a working product
AI

AI Strategy Shouldn’t End With a Plan. It Should End With a Product

If you were building your business today, would it be AI-native?

Exploring what an AI-native business could look like when built around what AI makes possible.
AI

If you were building your business today, would it be AI-native?

True Velocity: Measuring the Real Impact of AI on Software Delivery

Illustration representing AI software delivery, measuring outcomes, validation and engineering performance rather than development output alone.
AI

True Velocity: Measuring the Real Impact of AI on Software Delivery

Adding AI Features Doesn’t Make a Product AI-Native

Illustration representing AI-native product development, combining AI capabilities with traditional software through deliberate product design.
AI

Adding AI Features Doesn’t Make a Product AI-Native

Own the Answer: Why AI Software Development Needs Engineering Expertise

Illustration representing AI software development, engineering expertise, context engineering and accountable decision-making.
AI

Own the Answer: Why AI Software Development Needs Engineering Expertise

AI Strategy Shouldn’t End With a Plan. It Should End With a Product

Team working on an AI product strategy and building a working product

If you were building your business today, would it be AI-native?

Exploring what an AI-native business could look like when built around what AI makes possible.

True Velocity: Measuring the Real Impact of AI on Software Delivery

Illustration representing AI software delivery, measuring outcomes, validation and engineering performance rather than development output alone.

Adding AI Features Doesn’t Make a Product AI-Native

Illustration representing AI-native product development, combining AI capabilities with traditional software through deliberate product design.

Own the Answer: Why AI Software Development Needs Engineering Expertise

Illustration representing AI software development, engineering expertise, context engineering and accountable decision-making.