I keep hearing the same line in different forms:
AI is changing the product-manager-to-engineer ratio.
The old rule of thumb was something like one product manager to six, eight, maybe ten engineers. Marty Cagan wrote in 2007 that organisations should generally think about one product manager for every six to ten engineers. That sounds about right as a historical centre of gravity, even though every company varied by product, maturity, platform complexity, and culture.
Now the AI-era discussion is much more dramatic.
Some people are talking about one PM to four engineers. Some are talking about one to two. Some are talking about one to one. There are even reports from Andrew Ng's recent comments that teams are considering ratios as extreme as one product manager to half an engineer, meaning product people outnumber developers.
I think the ratio discussion is real.
But I also think it hides the bigger story.
This is not really a ratio problem. It is a retraining problem.
The old PM sat on top of a technical network
In the traditional model, a product manager did not always need deep technical understanding.
Sometimes they did. In very technical products, platform products, security products, infrastructure products, or founder-led teams, the PM often had to be deeply technical. But in many organisations, the PM could survive by understanding the customer, the market, the business priority, the roadmap, and the stakeholder conversation.
When a technical question appeared, they had a network around them.
They could turn to the tech lead.
They could turn to the architect.
They could turn to the security person.
They could turn to infrastructure, QA, data, compliance, design, delivery, or operations.
The product manager was often sitting above a distributed intelligence system. The engineering organisation held a huge amount of technical truth. The PM did not need to carry all of it in their own head because the organisation carried it for them.
That worked when engineering throughput was the bottleneck.
It works less well when AI compresses the team.
AI compresses the team
If two engineers can now do the work that previously needed eight, the organisation changes shape.
If one senior engineer can prototype an end-to-end product with agents, the organisation changes shape.
If small teams can build, test, package, deploy, and iterate far faster than before, the handoffs become more expensive. The alignment meetings become more expensive. The loss of context becomes more expensive.
The product manager is no longer just feeding work into a large development machine.
The product manager is increasingly standing inside the execution system.
That changes what the role requires.
Engineering is not just code
This is the bit that gets missed.
When people say AI can write code, some people hear: engineering is now easy.
No.
Code is only one surface of engineering.
Engineering includes architecture, authentication, security, networking, deployment, observability, monitoring, testing, source control, data governance, performance, scaling, incident response, backup, recovery, privacy, interfaces, permissions, dependency management, and the judgement to know when a system is about to become fragile.
Just authentication is a world.
Just Git is a world.
Just SSH, servers, cron jobs, DNS, certificates, TCP/IP, containers, secrets, queues, rate limits, and rollback plans are worlds.
A PM may understand those things conceptually. They may know enough to ask sensible questions. They may know enough to take the answer back to a stakeholder meeting.
But that is different from knowing what good looks like.
It is different from knowing the task shape.
It is different from knowing when the AI-generated thing is plausible but unsafe.
It is different from seeing a design and thinking: that will work in the demo, then fall over in production.
The retraining is asymmetric
This is why I suspect the new product manager may often be an engineer who has reskilled.
Not always.
There will be excellent product managers who become deeply technical. There will be commercial product leaders who learn enough architecture, security, and AI orchestration to remain extremely valuable. There will be domains where customer judgement, regulatory judgement, pricing judgement, or go-to-market judgement matters more than implementation detail.
But the retraining problem is asymmetric.
A senior engineer with ten years of broad experience already carries a huge amount of tacit system knowledge. They know the smell of a bad integration. They know why the test that passes locally may fail in production. They know why a permission model that looks simple can become dangerous. They know why a prototype is not a product.
That engineer can learn product management skills.
They can learn discovery.
They can learn customer conversations.
They can learn market framing, prioritisation, stakeholder language, roadmap discipline, commercial trade-offs, and product storytelling.
Some will hate it. Some will be brilliant at it.
But for the right engineer, that may be a shorter bridge than asking a non-technical product manager to absorb ten years of engineering intuition in a few months.
The weak PM role gets squeezed
I do not think great product managers disappear.
I think weak product management gets exposed.
The PM who only coordinates meetings, writes tickets, collects requirements, maintains a roadmap, and asks engineering to translate everything will struggle.
That role depended on the old organisation shape.
In the AI-assisted organisation, there is less room for translation without judgement.
The valuable PM is different.
They can define the problem precisely.
They can understand the customer and the business model.
They can reason about technical constraints.
They can direct agents without being fooled by the first plausible output.
They can ask engineers better questions because they know the ground beneath the question.
They can tell the difference between a product demo and a product system.
The new role is closer to product engineering
This is why the phrase product engineer keeps appearing.
I do not mean a developer who ignores users.
I mean someone who can hold the customer problem and the system shape in the same mind.
Someone who can talk to a customer in the morning, sketch the workflow at lunch, direct an agent to build a prototype in the afternoon, review the architecture before dinner, and know what needs a security specialist before anything goes live.
That person is not just a PM.
They are not just an engineer.
They are a product-minded engineer, or an engineering-grade product person, operating with AI as part of the team.
That is a very different profession.
What PMs should do now
If I were a product manager looking at this shift, I would not panic.
But I would start moving.
I would learn enough engineering to understand system shape, not just vocabulary.
I would learn Git properly.
I would learn how web applications are deployed.
I would learn authentication and permissions.
I would learn APIs, logs, monitoring, testing, and failure modes.
I would learn how to work locally with an agentic coding harness so I could create, inspect, and challenge real artefacts rather than only talk about them.
Most importantly, I would learn what good looks like.
Not so I could replace engineers.
So I could remain useful in a world where the distance between product decision and shipped system is collapsing.
What engineers should do now
If I were a senior engineer, I would look at product management with fresh eyes.
Not as admin.
Not as meetings.
As leverage.
The engineer who can understand customers, business constraints, risk, commercial value, and narrative will be extraordinarily valuable.
AI makes implementation faster. That increases the value of deciding well.
If you can do both, you become hard to replace.
The company question
Companies will have to decide who they keep and who they retrain.
That decision should not be based on titles.
It should be based on capability.
Can this person understand the customer?
Can this person understand the system?
Can this person direct AI without being dazzled by speed?
Can this person evaluate risk?
Can this person decide what good looks like?
Can this person bring others with them?
The future product manager may not be the person who owned the roadmap.
It may be the person who can stand at the crossing point between customer need, business value, architecture, security, and AI execution.
In many companies, that person may turn out to be an engineer who reskilled.
And if you are a product manager, that is not a threat.
It is the map.
Sources and notes
Marty Cagan's 2007 SVPG note Roles and Ratios gives the classic one PM to six-to-ten engineers reference point. Recent AI-era ratio discussion is more speculative and should be treated as signal, not settled operating law. Forbes and Allstacks have both reported Andrew Ng's product-management-bottleneck framing and the more extreme one-PM-to-half-an-engineer anecdote. Anthropic's public Product Engineer, Applied AI role is one example of the product/engineering boundary becoming more blended in practice.