1 / 3 The New Bottleneck Is Knowing What NOT to Build

It is a classical question in product design, UX and user research. We investigate users, test ideas, analyse behaviour and study the market to understand what deserves to become a product.

That question is still important. But it changes as the product matures.

In the early phase, you are trying to decide what to build. Once the product gains traction, you increasingly need to decide what NOT to build.

AI makes both questions more important. It allows us to test more ideas, create more prototypes and build working software faster than before. But it also means that ideas and features can enter a product faster than most organisations can properly evaluate them.

The shortage is no longer necessarily ideas. It is no longer necessarily development capacity either.

The shortage is direction.

The question changes as the product matures

You can roughly divide the product journey into two phases. In the early phase, the main question is:

What should we build?

A startup might build several ideas, release them quickly and see what catches on. Throw things at the wall and see what sticks.

AI makes that approach far more powerful. You can create several prototypes, run A/B tests and use fake-door tests to see how users respond to possible features or products before building them properly.

You are not building the full feature yet. You are testing whether the interest is real.

In a larger product organisation, you would probably begin with more research. Interviews, journey maps, behavioural data and prototype testing can create a stronger foundation before development begins. You might observe users, understand their workflows and test different hypotheses before deciding which direction to follow.

Research does not remove uncertainty, but it gives you a better foundation than sitting in a meeting room and imagining what users probably need.

Both approaches are trying to answer the same question:

What deserves to exist?

But once the product gains traction, the problem changes. Customers, employees, stakeholders and AI can quickly produce thousands of plausible ideas. The backlog is no longer difficult to fill.

At that point, the challenge becomes:

What should we not build?

Then the backlog starts pulling

Once a product begins working, requests start arriving from every direction. Customers ask for features. Sales wants something that could close a large account. Support sees recurring problems. Designers and developers see improvements. Leaders watch competitors. And AI can generate another hundred ideas before lunch.

Generating ideas is easy. Rejecting them is hard.

We naturally look at a product and think:

It would be cool if it could also do this.

Then another idea appears. And another. Most of these ideas are not necessarily bad. They may solve real problems. They may create value. They may even create revenue.

The problem is that they can be pointing towards different products. One request may move the product towards large enterprise customers. Another may move it towards private homeowners. One feature may strengthen an open platform. Another may protect a closed subscription model. One idea may cater to technical superusers. Another may prioritise simplicity for people who do not want to configure anything.

Product direction can be an arrow or a cone

We often draw product direction as a straight arrow. The product is here, and the destination is over there. That is the clearest version of strategy. You know who the product is for, what type of company you are building and what the product should eventually become.

But direction is rarely that precise. Sometimes it is better represented as a cone pointing out in front of the product. The product sits at the narrow point. The open end represents the range of possible destinations that still fit the intended direction.

A narrow cone means the company has a fairly clear idea of where it is going. You may not know the exact features yet, but the possible choices still point towards roughly the same future.

A wider cone means more ambiguity. Perhaps the company is still unsure about its audience. Perhaps it has not decided whether it is building an open or closed platform. Perhaps it does not know whether it wants to remain a software company or become a service organisation.

The cone does not represent time expanding into the future. It represents uncertainty. The wider it becomes, the less clear the direction is.

The backlog surrounds the product

There is another way to picture the problem. Imagine the product in the middle of a circle. Around it sits the backlog. Every feature, request and idea is represented by a dot somewhere on that circle.

The cone points towards the desired product direction. It marks the part of the backlog that broadly moves the product towards the future you have chosen. Some dots sit clearly inside the cone. Others sit close to its edges and may still fit. Some sit completely outside it and point towards another product, audience or business model.

This is why every backlog item contains a small piece of direction. One feature may only create a slight pull. But all the features you choose together eventually add up to the real direction of the product.

You may have a theoretical direction described in the product vision. But the practical direction is created by what the team actually takes from the backlog and builds. If most of the selected features sit outside the cone, the product will move outside the intended direction—even if the strategy document still says otherwise.

The product manager’s job is therefore not only to judge the value of each task. It is also to understand which direction each task is pointing and what all the selected tasks will add up to when combined.

You will not arrive in Paris by travelling north

As a metaphor, imagine that your product represents a starting point on a map, and your product direction represents where you want to go. Let us place that starting point in Denmark. One vision takes the product north towards Oslo: focused, Scandinavian and relatively minimal. Another takes it south towards Paris: broader, more expressive and built around a different type of experience.

Neither destination is objectively better. But you need to know which one you are travelling towards.

You will not arrive in Paris by continuously going north. You can drive faster. You can find better roads. You can report that the team has covered another 500 kilometres. You are still moving away from Paris.

This is where organisations confuse development progress with product progress. Tickets are completed. Releases go out. The roadmap moves. Management sees visible activity. But nobody can clearly explain what all that activity is turning the product into.

This becomes even harder because a feature that pulls the product in the wrong direction does not necessarily look unsuccessful. People may use it. Revenue may increase. The KPI might even go up.

That is where the next problem begins. A feature can perform perfectly well on its own while slowly weakening the product around it.