When Building Gets Cheap, Products Get Harder to Understand

The current product conversation is full of apparent abundance. Teams can build faster, features can be copied quickly, nontechnical experts can participate in model development, and AI can take on work that previously required specialist skills. At the same time, companies are testing cheaper plans, looking for ways to monetise third-party AI products and restricting usage when operating costs become difficult to sustain.

I see one constraint becoming more important across all of this: can customers still understand what the product is for?

Customers do not experience a roadmap. They see a set of buttons, plans, prompts and promises, then try to form a mental model. Every new capability changes that model. A conversation recap feature can sound useful, but it also raises questions. Is this a recording product now? When is it active? Where does the recap live? Can I trust it as a record? Does it replace my notes or merely supplement them?

Those questions are part of the product. They are not copywriting to be handled after development.

When building was expensive, engineering capacity created a natural filter. Weak ideas often died because they could not justify several months of work. That filter was imperfect, but it forced some prioritisation. If a usable version can now be produced in days, the organisation can ship more ideas before it has properly decided what they mean.

This is where I think product leaders need to change the roadmap conversation. The relevant question is no longer only whether we can build something or even whether a customer says they would use it. We should ask whether adding it makes the product easier or harder to explain.

Imagine a business application that already helps managers review performance. The team can add an AI summary, a chat interface, recommended actions and an automated weekly email. Each feature may perform well in isolation. Together, however, they create four competing places where a manager can ask the same basic question. The customer has to learn which answer is authoritative, which one can trigger an action and which one is merely informational.

The engineering work may be cheap. The comprehension cost is not.

That cost appears across the company. Sales needs a longer explanation. Customer success has to clarify overlapping workflows. Support receives questions that look like usability problems but are actually product-definition problems. Marketing struggles to describe the difference between plans. The product team then adds onboarding and tooltips to repair confusion created by the portfolio itself.

I have seen teams respond to this by measuring feature adoption. That can make the situation worse. If four overlapping entry points each have some usage, every team can defend its own feature. Local adoption does not prove that the overall product remains coherent.

I would rather define the role of a new capability before approving it. Which existing behaviour should it replace? Which user decision should become simpler? Where should the customer go first? If the feature succeeds, what part of the current experience becomes unnecessary? A team that cannot answer those questions is not ready to ship, even if it already has a working prototype.

This also affects pricing. Customers should not need to understand our model architecture, token consumption or internal supplier agreements to choose a plan. Packaging should correspond to a recognisable job or level of value. When a new capability forces a pricing table to become a matrix of exceptions, that is often evidence that the product itself lacks a clear boundary.

Product strategy has always involved saying what a product will and will not do. Faster production makes that discipline more important, not less. The best roadmap may now contain fewer additions than the team is capable of delivering.

I would judge a product organisation partly by whether customers can accurately explain its product without help. If that explanation keeps getting longer while building keeps getting faster, the team is not creating more value. It is transferring its unresolved decisions to the customer.