Build to Learn: How AI Is Changing Product Strategy

Earlier this year, we asked our product team to rethink how they would work if they were building a product studio from scratch today. The interesting part wasn't how much they would change. It was how much would stay the same. The fundamentals still matter: understanding users, defining problems, prioritising opportunities. What's changed is where teams spend their time and how quickly they move from an idea to something real.

One of the clearest shifts is in the work around the product process. Requirements, feedback synthesis, meeting notes and updates still matter, but the manual effort involved in producing them has reduced significantly. When we asked the team how many people had written a requirement completely from a blank page in the previous six months, the answer was none. Not one.

Instead, teams are increasingly starting with a working draft, using AI to accelerate the process and spending more time on the parts that require judgement: understanding the problem, shaping the experience and deciding what is worth building. That shift changes the relationship between thinking and making. Where a feature once meant conversations and approvals before anything was tangible, teams can now create a rough working version early and learn from how people actually respond.

The old assumption was that building was expensive, so teams needed to validate as much as possible before they started. As the cost of creating a first version falls, there are more situations where the faster path is to build, test and learn. This doesn't mean teams should build everything. It means the economics of learning have changed. Rather than spending weeks debating whether an idea deserves to exist, teams can often answer that question by putting a simple version in front of real users.‍

Behaviour over stated preference

‍For questions about user behaviour, this changes the way teams can learn. If we want to know whether customers will use a new self-service feature, for example, we can increasingly test that behaviour through a controlled release rather than relying on what people say they might do. When the question is about behaviour, real usage often tells us more than predictions about future behaviour.

That does not make research less important. Understanding why people behave as they do, what problems they are solving and whether they would pay for something still requires proper investigation. Some decisions should never be tested directly with users, however easy experimentation becomes.

The difference is that building something to learn from is no longer as expensive as it once was. In many cases, the question is no longer "should we build this to test it?" but "what would we learn if we did?"

‍The harder job is deciding what not to build

‍This is one of the biggest changes AI brings to product development. It shortens the distance between an idea, a real user interaction and a decision. But as that distance gets shorter, choosing the right direction becomes even more important.

The risk was never simply that teams could not build quickly enough. The bigger risk is building the wrong thing efficiently and AI makes that easier to do faster than before. The constraint has shifted from construction to judgement.

When it becomes easier to add features, the challenge is knowing which ones are worth building. Great products aren't defined by how much they contain, but by how well they solve a meaningful problem.

‍Where roles blur and where they shouldn't

‍AI is also changing how product teams work together. Product managers can explore ideas and create early versions without always waiting for a full development cycle. Designers can test concepts through working experiences rather than static screens. Engineers can validate approaches earlier in the process.

But this does not mean everyone becomes responsible for everything. Great products still depend on specialist knowledge and judgement. The goal isn't to remove expertise, but to let every discipline contribute more.

The principle we follow is simple: keep the controls that protect the outcome, and automate the work that creates process overhead but not the work that requires judgement. For example, we kept our delivery audit because the decisions behind it matter. We just let AI support the parts that were always mechanical rather than judgement-based. AI is very good at reducing administrative effort. The value comes from spending that time on decisions that need judgement.

‍What this means in practice

‍AI has not changed what good product strategy requires. Teams still need to understand problems, prioritise opportunities and make difficult decisions about what not to pursue. What has changed is the cost of learning.

Testing ideas against real behaviour is becoming faster and more accessible, giving teams the opportunity to make better decisions earlier. But the advantage does not come from building more things. It comes from learning faster, asking better questions and focusing effort on the opportunities that matter most.