AI can make it much easier to build a feature. That does not make the feature worth building.

Product management consultant Rich Mironov makes that distinction in a new essay about the “barbell-shaped” product role. His argument is simple: if AI moves more of the work of writing software into the middle, product teams will need to spend more time at both ends of the process.

One end is deciding what deserves to exist. The other is proving that people will adopt it and pay for it.

What Mironov is saying

Mironov starts with a familiar failure. An AI engineer and co-founder had built interesting software, but attracted no interest from the intended buyers. The conversation had to move away from the technology and toward the basics: who the product was for, what problem it solved, and why the buyer should care.

His conclusion is blunt:

“The bar gets heavier at both ends: more judgment on what to build, more muscle on how to sell it. Engineering owns the middle.”

By “the middle,” Mironov means the work of turning a clear product decision into working software. AI coding tools can accelerate that work. They do not automatically identify a valuable problem, validate a buyer’s need, set a workable price, or create demand.

That is the barbell. Product work gets heavier at the front, where teams choose and test ideas, and at the back, where they explain, sell, and support the result. The coding layer between those points may get faster.

Why his background matters

Mironov coaches product executives and software companies. He has served as an interim product leader at multiple companies and writes Product Bytes, a long-running publication about product strategy and software businesses. His profile also says he has consulted to more than 220 technology companies.

That background does not make his forecast certain. It does explain why he is looking at the commercial consequences of AI coding rather than treating faster code generation as the whole story.

His essay is also a useful counterweight to the standard “ten times faster” claim. Faster implementation changes the economics of development. It does not remove the uncertainty before development or the work after launch.

What he gets right

The strongest part of Mironov’s argument is the mismatch between build speed and learning speed.

A builder can ask an AI coding agent for a working prototype in an afternoon. That prototype may still answer the wrong question. It may target the wrong buyer, solve a problem that is not painful enough, or make a promise the business cannot deliver.

AI makes this mismatch easier to miss because the output looks concrete. A polished screen feels like progress. It is evidence that something can be built, not evidence that someone needs it.

Mironov is also right that discovery cannot become a fully automated step. AI can group support tickets, summarize interviews, find patterns in usage data, and suggest questions for the next customer call. A builder still has to decide which signals are real, which users matter, and which trade-offs are acceptable.

Where the barbell idea is incomplete

The barbell is a useful warning, but it can make the future sound too neatly divided. Engineering judgment does not disappear when coding gets faster. Someone still has to make choices about reliability, security, data handling, maintenance, and the limits of the tools involved.

Those choices may move closer to product work for a solo builder. The same person may decide what to build, ask an agent to implement it, review the result, and watch what happens in production. “Engineering owns the middle” describes an organizational division of labor. It does not describe the reality of every AI-native builder.

The other risk is treating go-to-market as a final stage. If a product’s pricing, onboarding, and distribution are considered only after the code is ready, the team may discover too late that the product cannot support a viable business. Customer and commercial questions should shape the idea before the first build, not just prepare the launch afterward.

What this means for builders

The practical lesson is not to slow down. It is to spend the saved time on the questions AI cannot answer for you.

Before asking an agent to build, write down:

  • Who has the problem today?
  • What do they do instead?
  • What would improve if the problem disappeared?
  • Who can approve a purchase or change a workflow?
  • What evidence would make you stop building?

Then use AI where it helps. Ask it to turn interview notes into themes, compare competing workflows, draft a prototype, generate test cases, or identify gaps in a product brief. Treat those outputs as working material, not as customer evidence.

After the first version ships, measure behavior rather than compliments. A user saying the product is interesting is not the same as a user returning, inviting a teammate, or paying to keep it.

Mironov’s barbell is best read as a correction to the idea that AI makes product judgment less important. It makes weak judgment more expensive because builders can turn a bad idea into a convincing product much sooner.

The faster the build loop becomes, the more deliberately you need to protect the problem-selection and customer-learning loops around it.

End of article