2 / 3 Good Ideas Can Still Move the Product in the Wrong Direction

A strategically wrong feature does not always look like a failure. People may use it. A new product line may attract customers, and revenue may increase inside that isolated part of the business. Looked at on its own, the KPI appears healthy.

That is one of the reasons product direction is so difficult to protect. Bad ideas are often easy to reject—the dangerous ones are the good ideas.

The wrong feature can still improve the KPI

A feature can show positive growth in analytics while pulling the wider product portfolio in the wrong direction. The same thing can happen at company level.

LEGO is one of the clearest examples. Around the late 1990s and early 2000s, LEGO expanded into theme parks, clothes, watches, bags, media, games and several other areas that moved further away from the plastic building system. Some of these ideas gained traction and introduced the brand to new audiences—individual products or business areas may have looked successful when viewed separately.

But the entire body of LEGO began to tilt. The portfolio became more complex, costs increased, and the core story became harder to see. The company had expanded in so many directions that it came close to collapse.

The turnaround involved cutting off dead branches and narrowing the company around the core the founders had set: the plastic brick and the building system around it. You can optimise every branch while the whole tree is beginning to fall over.

This is why isolated KPI growth is not enough to prove that a feature or product direction is right. You also need to understand what the initiative is doing to the identity, complexity and direction of the complete portfolio.

The things you reject are rarely stupid

A customer request may solve a genuine problem. An integration might be technically straightforward. A feature may create revenue. A competitor may already offer it. The easiest decision is rejecting something obviously bad—the harder decision is rejecting something useful because it belongs to another product.

Before Trello was acquired by Atlassian, one of its clearest qualities was that it was not Jira. Trello was visual and relatively simple—you could understand it quickly. Every advanced workflow, reporting feature or configuration option might have helped someone, but each addition also risked moving Trello towards the complexity it was positioned against.

The question was therefore not only: Would this feature be useful? It was also: Would this make Trello more like Jira?

That second question protects the identity of the product. A feature can be valuable and still weaken the reason people originally chose you.

Being able to do everything is not a position

Products are a little like people in job interviews. One candidate says:

I can do everything.

Another says:

I have spent ten years becoming extremely good at this specific problem.

The second candidate is often easier to place and easier to trust. Products work the same way.

A product can accumulate more capabilities while becoming harder to understand. Its positioning weakens, its main audience becomes less visible, and the interface begins serving edge cases. Its strongest story gets buried underneath useful additions.

This does not happen because somebody deliberately decided to destroy the product. It happens because every request had a reasonable argument behind it.

Your audience defines what not to build

Direction is also about who you choose to serve. “Homeowners” may sound like a target audience, but it still covers a wide group of people. A service aimed at elderly homeowners may need large buttons, clear language and very few visible choices, while a product for younger and more technical users may support more configuration, integrations and automation.

Some users want complete control over every alert; others just want to know whether somebody is standing outside the house. Some people want the camera connected to a complete smart-home system; others want one application that hides all the technology. Every feature changes the experience for everyone.

An advanced permission system may help one unusual household, but it introduces new concepts and controls that thousands of ordinary users now need to understand. A highly configurable alert system might be perfect for superusers while making onboarding worse for everyone else.

When a feature request appears, it is not enough to ask whether someone wants it. You also need to ask: who does that person represent? Does the feature strengthen the product for the audience we chose, or does it pull us towards another audience? What else will we eventually need to build if we accept that direction—and what becomes harder for everybody else?

A product that continuously adjusts itself to every possible audience can eventually end up with no clear primary user.

The build trap becomes worse with AI

Many Agile and Scrum environments contain an assumption that the development team should always be busy. There should always be another ticket waiting at the top of the backlog, developers should continue pulling work, and releases should continue going out. If the team stops, it can look like somebody is failing to manage the process—so the easiest response is to find more things to build.

I have seen this several times: the product direction is unclear, but stopping the team feels more dangerous than building the wrong thing. The wrong product manager keeps the machine running because completed tickets are easy to show to management. It is much harder to stand up and say:

We need to stop. We do not know which direction this product is moving in.

That may look like a lack of progress, even when it is the most responsible decision available.

AI makes this build trap much worse. Previously, the question might have been:

Is this feature important enough to spend three months building?

Now it becomes:

Why not build it? It will only take a few days.

Soon it will simply be:

The agent can build it today.

When implementation appears cheap, the whole feature begins to look cheap. But generated code is only the beginning. The feature still has to be tested, maintained, supported and documented. It affects the interface, introduces accessibility and security considerations, and customers begin depending on it. It influences future architecture, and removing it may be much harder than adding it.

The code might take one day to generate. The product may own the decision for ten years.

We naturally improve products by adding things

There is a human tendency known as addition bias. When we try to improve something, we instinctively think about what we can add—a feature, a setting, another product tier, a new audience. We are less likely to ask what could be removed, simplified or left alone.

You can see this immediately when using AI. Ask an AI how a product could be improved, and it can produce a list of 20 features. Ask it to continue, and it will create another 20—all of them sounding surprisingly reasonable.

I see the same pattern with coding agents. Once they begin building, they often notice adjacent opportunities and start solving problems I never asked them to solve. They over-engineer, add flexibility, prepare for scale the product does not have, and create options for theoretical users who may never exist.

I often have to ask the agent to go up into the helicopter and look at the product again—not the code, not the current ticket, the product. What are we actually trying to make?

Products rarely become bloated because of one obviously terrible decision. They become bloated through hundreds of additions that all made sense at the time. And every one of those additions contains more than functionality—it contains a little piece of a future company.

That becomes much easier to see when we stop talking abstractly and follow one product through the different directions it could take.