AI Multiplied Your Engineers. Your PMs Are Drowning.

TL;DR

AI coding tools have 2–3x multiplied effective engineering capacity, but PM and design headcount hasn't moved. The team ratio is broken.
The result isn't that PMs are unnecessary. It's that they're overloaded: more decisions and more coordination surface, same number of humans doing it.
A simple heuristic is emerging at the frontier: if a project takes less than two weeks of engineering time, the engineer owns it end-to-end. PM shifts to advisory. Over two weeks, PM is accountable.

AI coding tools have multiplied engineering output by 2–3x without any change in PM or design headcount. The result: product teams that can build far more than they can decide, coordinate, or validate.

A year ago, a product team of five engineers, one PM, and one designer shipped at a pace everyone understood. The PM could stay across all the work. The designer could review every surface. Standups made sense.

That team now produces the output of 12–15 engineers. Same PM. Same designer.

AI coding tools did exactly what they promised. Engineers ship faster, handle more concurrent workstreams, and automate the repetitive parts of implementation. Claude Code, Cursor, Copilot, and their equivalents turned senior engineers into small teams and turned small teams into departments.

Nobody adjusted the other side of the ratio.

How did AI break the PM-to-engineer ratio?

Most organisations haven't noticed the ratio problem because productivity gains showed up gradually. One engineer finishes a task in two days instead of five. Another picks up a second workstream. A third starts prototyping a feature that wasn't even on the roadmap.

Each of those is good news in isolation. In aggregate, they create a coordination crisis.

The PM who used to track five active workstreams now has twelve. The designer who reviewed every screen before launch is now three sprints behind. Decisions that used to flow through a single PM bottleneck start getting made without one, because waiting for product input has become the slowest part of the process.

I've watched this pattern develop across multiple product organisations. AI-assisted development workflows land, engineering velocity increases within weeks, and nobody adjusts the other side of the equation. The number of people responsible for deciding what to build, validating whether it's right, and coordinating across legal, compliance, and go-to-market stays exactly the same. The product function becomes the constraint. Nobody is underperforming. The math changed underneath them.

Three symptoms show up consistently:

Engineers waiting for decisions. Tasks that require product input sit idle because the PM is spread across too many workstreams to respond quickly.
Features shipping without adequate context. Engineers make reasonable assumptions about user needs because no one is available to provide the right framing. The assumptions are often wrong.
Scope creeping upward. When build cost drops, the natural instinct is to build more. Without a PM actively pruning scope, everything that's technically feasible gets built. The roadmap expands by default.

None of these look like a crisis in any individual sprint. Over a quarter, they compound into a team that's shipping a lot and validating very little.

Why won't upskilling PMs fix the ratio?

The instinct in the industry right now is to tell PMs to upskill. Learn to code. Ship your own features. Become a product builder.

That advice is correct for individuals, and I've written extensively about why. But it misses the structural problem entirely.

If a PM learns to code and ships the 21st feature themselves, the team now has 16 engineers' worth of output and 0.5 PMs' worth of product judgment, because the PM spent their day coding instead of making decisions. The leverage is negative.

The higher-leverage move: help your engineers become better PMs themselves.

Not every engineer wants this or is suited for it. But the ones who already think in terms of user problems, trade-offs, and business impact are now extraordinarily valuable. They can own the full cycle on smaller projects without PM oversight.

Product-minded engineers have always been valuable. In an AI-amplified team, they become unicorns who stack skills across domains. Their output multiplied alongside everyone else's. The difference is that their output includes judgment, not just code.

How does the two-week ownership heuristic work?

A practical framework is emerging for how to allocate PM accountability in AI-amplified teams. The threshold is project duration.

Under two weeks of engineering time: the engineer owns it end-to-end. They talk to the relevant stakeholders (security, legal, design, go-to-market). They make the scope calls. They ship it. The PM is available in an advisory capacity but is not the accountable party.

Over two weeks: PM is accountable. The project is complex enough that cross-functional coordination, user research, and scope management justify dedicated product leadership.

Exception: some projects under two weeks are still complex enough to need PM involvement. Anything touching compliance, pricing, or multi-team dependencies probably needs a PM regardless of duration.

This isn't a universal rule. It's a heuristic, and like all heuristics it breaks at the edges. What makes it useful is that it creates an explicit conversation about ownership that most teams aren't having. The default today is that the PM owns everything, which means the PM owns nothing well enough.

I'd extend the heuristic with a second dimension: reversibility. If a decision is easy to reverse (a UI change, a copy update, a feature flag), let the engineer own it regardless of duration. If a decision is hard to reverse (a pricing change, a data model, a public API), PM involvement is worth the coordination cost.

What should product organisations do about the PM squeeze?

The structural fix isn't complicated. It's politically uncomfortable, because it requires admitting that the team composition that worked six months ago doesn't work now.

Hire more PMs. This is the obvious answer and the one most organisations resist because PM headcount is already seen as overhead. That framing was always wrong, and it's now dangerous. If your engineering team effectively tripled in output, your PM layer needs to grow. Not by 3x, because the two-week heuristic reduces the PM surface area on smaller projects, but by more than zero.

Hire product-minded engineers deliberately. Stop treating product sense as a nice-to-have in engineering hires. Screen for it. Value it in compensation. Give product-minded engineers explicit PM responsibility on qualifying projects. The companies doing this well are finding that these hires are the single highest-leverage addition to an AI-amplified team.

Change the operating model, not just the tools. Most teams responded to AI coding tools by keeping the same team structure and enjoying the extra velocity. That works for a quarter, maybe two. Then the PM squeeze catches up. The team that actually captures the productivity gain is the one that redesigns how decisions get made, not just how code gets written.

Protect PM time ruthlessly. If your PM is spending 40% of their time in status meetings, Slack threads, and Jira hygiene, that's 40% of your scarcest resource being consumed by work that doesn't require product judgment. Automate the administrative layer. Use AI for the coordination work so PMs can focus on the judgment work.

Don't forget the design squeeze. Everything above applies to design capacity too. The designer who reviewed every screen before launch is now three sprints behind the engineering team. The same two-week heuristic works here: for smaller projects, engineers with decent design instincts (and a design system to work within) can own the visual decisions. For larger projects, design review remains essential. The fix is the same: grow the capacity, not just the output.

The bottleneck moved. Most orgs haven't.

The conversation about AI's impact on product teams has focused almost entirely on what happens to individual roles. Will PMs learn to code? Will designers use AI tools? Will engineers replace PMs entirely?

Those questions are interesting. They're also the wrong frame.

The immediate structural problem is simpler: engineering throughput multiplied. PM and design capacity didn't. The ratio that made teams functional for two decades is now producing teams where the loudest signal is how much they ship and the quietest signal is whether any of it was the right thing to build.

Product-minded engineers, clear ownership heuristics, and honest headcount conversations are the fix. None of them require a philosophical debate about the future of the PM role.

The PM role isn't dying. It's drowning. There's a difference, and the fix is straightforward once you see it.

Frequently Asked Questions

Doesn't this just mean we need fewer PMs, not more?

No. The total surface area of product decisions hasn't shrunk. It's expanded, because faster engineering means more features, more experiments, and more things that need judgment. The PM squeeze isn't about PMs doing less valuable work. It's about there being more work than the current PM headcount can absorb.

What about PMs who can code? Doesn't that solve the ratio?

Partially. A PM who can prototype and validate ideas independently is more effective. But if they spend most of their time coding, they're not doing the coordination, stakeholder alignment, and judgment work that nobody else on the team is doing. The ratio problem is about team capacity, not individual versatility.

Is the two-week rule too simple?

Yes, deliberately. The value isn't in the specific threshold. It's in forcing an explicit conversation about who owns what. Most teams operate with an implicit assumption that the PM owns everything, which falls apart when engineering throughput triples.