When Building Gets Cheap, Product Judgment Gets Expensive

For a long time, a product manager could have an excellent idea and still never see it exist. The backlog was full. The design team was stretched. A small interaction required a dependency nobody could prioritize. What reached the customer was not always the best idea. It was the idea that survived the delivery system.

Claude Code and similar tools change that negotiation. A product person can increasingly turn a hypothesis into a working interface, compare alternative flows and inspect actual behavior without waiting for every first experiment to enter the engineering queue. The opportunity is enormous. So is the chance to confuse movement with progress.

The real upgrade is a wider possibility space

Think about the difference between describing a feature and putting a usable version in someone’s hands. A document can conceal disagreement. A prototype exposes it. Does the customer understand the state? Can they undo the action? Does the workflow hold together when something fails? These questions become much easier to discuss when there is something concrete to try.

Anthropic’s 2025 analysis of coding interactions classified 79% of Claude Code conversations as automation and found substantial web-development and user-interface activity. That is evidence of how the tool was being used—not a stopwatch proving faster delivery, and not a measure of customer value. Its significance for product work is the newly accessible operating surface.

Instead of asking for one dashboard and accepting the first reasonable implementation, a product manager can explore an exception queue, a timeline and a task-focused workspace. The advantage is not three polished screens. It is discovering which structure helps a particular person make a particular decision.

“Basically free” is the wrong denominator

The marginal effort of generating another variation can feel close to zero. But attention, subscriptions, inference, research, integration, accessibility and maintenance are not free. Nor is explaining why an attractive feature should not exist. A cheap prototype can create an expensive commitment if stakeholders mistake it for production readiness.

In the model above, reducing build time eventually produces diminishing returns because validation remains. That is not an argument against faster tools. It is an argument for reinvesting the saved effort in the part that converts a plausible interface into a useful product.

A historical counterexample matters here. METR’s early-2025 randomized study of 16 experienced open-source developers across 246 tasks found that access to then-current AI tools made completion 19% slower. The setting was mature repositories and experienced contributors, not a greenfield PM prototype. It should not be generalized to current tools. It does establish why “AI always saves time” is an unsafe planning assumption.

Specificity is the product manager’s unfair advantage

A generic prompt produces the median version of a familiar product: cards, charts, a search box and an optimistic success state. Real product work begins where that template stops. A dispatcher must rearrange a shift without losing coverage. A buyer needs to recover a failed payment without paying twice. An operator needs to know which exception is urgent, not merely how many exceptions exist.

The strong product manager supplies context the model cannot responsibly invent: the user’s constraint, the costly mistake, the state transition, the acceptable trade-off and the reason one action matters more than another. “Make it intuitive” is a preference. “Keep the customer’s entered values after a validation failure and announce the error to assistive technology” is an executable requirement.

A prototype is a question, not a promise

Before generating anything, write one sentence: “We believe this person cannot complete this task because of this friction.” Then name the observation that could prove you wrong. If the experiment cannot change your mind, it is a presentation disguised as research.

GOV.UK’s moderated usability guidance gives the appropriate discipline: observe participants attempting realistic tasks. Do not explain the interface until they succeed. Their hesitation is information. Their workaround is information. Their polite approval is not the same thing as independent completion.

Separate three gates. First, desirability: is this a meaningful problem? Second, usability: can people complete the task? Third, feasibility and safety: does the implementation behave correctly under representative conditions? A fast prototype may support the second conversation while proving almost nothing about the first or third.

The new execution loop

1. Frame: select one consequential user problem and an explicit non-goal.
2. Explore: build materially different approaches, not cosmetic variations.
3. Observe: test realistic tasks with the people affected.
4. Harden: verify errors, permissions, accessibility, data boundaries and recovery.
5. Decide: ship, revise or stop based on evidence—not the effort already spent.

Claude Code documents an agentic loop that gathers context, acts and verifies. The product leader’s loop must surround it: choose the question, define acceptance, supply constraints and make the release decision. Engineering expertise becomes especially valuable when the prototype touches security, money, system boundaries or long-lived architecture.

This elevates product work, not product titles

Someone who only coordinates artifacts may lose a familiar advantage when artifacts become easier to produce. Someone who understands users, prioritizes sharply and learns from reality can become substantially more capable. But that person need not have “product manager” in their title. A designer, engineer, support specialist or founder can demonstrate the same judgment.

The uncomfortable part is also the exciting part: fewer implementation excuses means more visible product choices. We can finally inspect the experience you meant—not just the specification you wrote. The differentiator is what you notice, what you decline to build and what you can prove improves the user’s situation.

More possibility does not reduce the need for product judgment. It makes the quality of that judgment impossible to hide.