Tom Verrilli’s line — “we regret that product management exists” — is deliberately provocative. It works because it says out loud what many engineers, designers, founders, and executives have quietly felt: product management can become a standing tax on teams that already know what they are doing.

Despite agreeing wholeheartedly with the sentiment, I think Tom is using “regret” as a rhetorical device to create useful discomfort and that is: a lot of what passes for product management is not product management. This isn’t actually an AI realisation - Marty Cagan has long pointed towards PM Theatre as a drag on business and a dis-justice to the function, but AI does sharpen things.

That does not mean product is dead in a modern AI native business. It means the excuse for low-value product work is inexcusable.

Product management should not be an org-chart reflex

One of Verrilli’s strongest points is that product managers should not be assigned as a default function of team topology.

A squad exists, therefore it needs a PM. This is clearly a non sequitur.

Engineering is more capable than ever. In a great many areas, engineers do not need a permanent product handler sitting between them and reality. They need context, principles to guide them, decision rights, strategic clarity, and access to customers and data. Those principles are key I think, but in many instances they don’t need to come from an embedded PM, they can come from Product leadership, or Engineering Architecture.

If the work is clear, the domain is known, the technical path obvious, and the team has the context to make good decisions, adding more product managers may not increase product quality. It may increase coordination cost, fragment ownership, and create the appearance of strategic attention without the substance of it.

I think the question is - what role does judgement play here and who is best to provide it. The answer in many cases isn’t Product.

A suggested taxonomy

Here is where I part company with the language of regret. I’ve a taxonomy here of three local environment types:

• Type 1: Areas where principles and an operating model work just fine.
• Type 2: Areas that look like type 1 but are sensitive to minor errors over the long term with no self-correcting mechanism.
• Type 3: Areas where strategic coherence matters on a daily basis.

For type 1, Product Leadership paired with Engineering leadership can establish the guardrails and the north star and everything works just fine without a dedicated PM. Arguably they work better and faster.

For type 2, the same appears to be the case as type 1 in the short term, but here the consequences of minor compounding errors over time is your business ends up in a completely different and unintended place in a medium time horizon and the cost of correction is significant cap-ex and opportunity cost. The answer here is either make it a type 1 environment or have Product influence present. Note that ≠ an embedded PM.

For type 3, its clear. PMs are essential. As an example, a critical part of the customer journey or key revenue raising space where rapid strategising, hypothesis and opportunity testing and high frequency judgement calls are the norm.

Not a settled matter

This question can be revisited frequently. Priorities change, the competitive environment changes, public policy changes, technology changes. To use Verrilli again, I love his accordion analogy.

When ambiguity is high, trade-offs are complex, incentives are misaligned, or the business needs a coherent theory of where to go, product can expand. A strong PM can knit together customer reality, commercial pressure, technical constraints, data, design, and strategy into a direction the organisation can act on.

When the problem is understood, the team is close to the customer, and execution is the constraint, product should contract. The PM should not cling to the centre of the work just because the org chart says they belong there.

I don’t regret Product Management existing

The product function should knit disparate functions behind a why, at levels that make sense for a given time and business. This sounds soft, until it is absent. We can’t A/B test a single org, but we can see differences between businesses which are Product Led and those that are not - more sharply than ever.

Without it, organisations often still move, but motion is not direction. Motion might even feel like success depending on the business environment, but when the environment becomes tough, you can’t attribute success to motion.

• What are we really trying to make true?
• What customer or market reality are we betting on?
• What constraint matters most right now?
• What does the future look like?

In the age of AI, these questions become more important because the cost of producing plausible work is collapsing.

So no, I don’t regret product management. I regret product management used as org-chart furniture. I regret PMs deployed where principles, context, and engineering judgement work well on their own. I regret the theatre of roadmaps, alignment, and plausible artefacts pretending to be strategy. But I don’t regret the function that helps an organisation understand what it is trying to make true. In the age of AI, that function matters more, not less - because when plausible work becomes cheap, judgement becomes the scarce thing.