When Output Gets Cheap, Product Teams Must Measure Removal

The technology industry is spending heavily to make AI output more abundant. More compute, larger platforms and increasingly capable agents all push in the same direction: generating code, analysis, designs and product ideas becomes cheaper.

Inside a product organization, that sounds like an obvious productivity gain. In practice, cheap output can create expensive organizations.

A team that can produce twice as many prototypes does not automatically learn twice as fast. Engineers who generate more code still have to integrate, secure and maintain it. Product managers who produce more analysis still need colleagues to read it and make a decision. A larger set of metrics can make a dashboard less useful rather than more informative.

This is why reports that AI is not yet saving teams much time should not be surprising. The time required to create an artifact is only one part of the work. Output then enters a system of reviews, dependencies, meetings, release processes and operational responsibilities. Speeding up the first step can simply move the queue.

I see a familiar product management mistake here. When capacity appears to increase, leaders fill it with more scope. The roadmap gets longer, more experiments run at once and every stakeholder gets another variation of the feature they requested. Activity rises, but focus falls.

The same problem appears in team processes. It is easy to add a metric, a recurring meeting, another approval or a new template. Removing one is harder because removal requires a clear decision about what no longer matters. AI makes adding things even easier, while the organizational ability to absorb those things remains limited.

Product leaders should therefore start measuring removal as deliberately as delivery. I do not mean introducing a simplistic target for deleted tickets or lines of code. That would be gamed before the first monthly review. I mean making subtraction visible in normal product conversations.

In a roadmap review, I want to know which initiatives were stopped because the evidence was weak. In an experiment review, I want to see which variants were rejected rather than how many were launched. In a product health review, I want to know which metrics, workflows and integrations were retired. In planning, I want teams to explain what they will no longer maintain if a new capability is added.

This matters even more when teams introduce AI agents. An agent may remove steps from the user experience while adding permissions, data flows, external services and failure modes behind it. If the team only counts the visible automation, it will miss the internal complexity. Security incidents across the industry keep reminding us that every additional connection and retained capability has a cost, even when the interface looks simple.

Subtraction also improves autonomy. Teams cannot make meaningful decisions when they are carrying years of inherited priorities. If everything remains important, autonomy means choosing the order in which to disappoint people. A healthy team needs permission to close experiments, delete obsolete metrics and challenge work that no longer supports the outcome.

I would add three questions to every product review. What did we learn that allows us to stop something? What complexity did this release remove? What new obligation are we creating for the team that will operate it?

Those questions create a useful counterweight to cheap production. They force the conversation away from how much was generated and towards whether the product system became clearer, safer and easier to run.

AI will continue to make output cheaper. That does not make judgment cheaper. The product organizations that benefit most will not be the ones producing the most artifacts. They will be the ones that get better at deciding what should survive.