My take on the future of Product Management
A year ago, I was sitting in a planning meeting with a team of eight engineers. One PM (me), eight engineers, two designers. That was the standard. We shipped one meaningful feature every three weeks if we were moving fast.
Last month, I watched a founding team of two, one PM and one engineer, ship and validate a working MVP in four days. Same output with a fraction of the headcount and a fraction of the time. Below this story were PMs and Engineers worrying what will happen to their jobs.
That is not an anomaly. That is the new normal. And if you are a Product Manager and you have not felt the ground shift under your feet yet, you will.
Looking At The Old Model
For most of the last decade, the software team ran on a simple ratio of roughly one PM to every six to ten engineers. Marty Cagan made this a rule of thumb back in 2007, and it became industry gospel.
- Google and Microsoft hovered around 1:6 to 1:9
- Amazon’s two-pizza teams implied roughly 1:6 to 1:8
- Meta pushed toward 1:12
The logic was sound. Engineering was the bottleneck. Code was expensive and slow to write. And the PM’s job was to keep engineers busy with the right work (define, prioritise, and unblock).
In that world, the PM was, in many ways, a coordination layer. Write the PRD. Run the sprint. Manage the stakeholders. Get the design reviewed. Shepherd the spec. Rinse and repeat.
A lot of us were very good at that version of the job. I was too. But that version of the job is quietly disappearing.
What Andrew Ng Said, and Why It Matters
In a conversation on the No Priors podcast, Andrew Ng made a remark that has stuck with me since
“Things that used to take six engineers three months to build, my friends and I, we’ll just build on a weekend… Writing software, especially prototypes, is becoming cheaper. This will lead to increased demand for people who can decide what to build.” — Andrew Ng
He was not celebrating speed. He was pointing at a structural problem.
When a prototype took three weeks to build, waiting one week for user feedback felt acceptable. When a prototype takes a day, that same week feels painful. The bottleneck did not disappear. It moved.
Using a simple economics argument that I learned in my INSEAD MBA classroom while studying Prices and Markets: cars and gasoline are complements. As cars get cheaper, demand for gasoline goes up. Similarly, as engineering gets cheaper, demand for product sense goes up.
One of his own teams proposed a PM-to-engineer ratio of 1:0.5. One PM for every half an engineer. That would have sounded absurd three years ago.
But, It does not sound absurd anymore.
The PM Is The Bottleneck
Here is what is actually happening on the ground. AI coding tools such as Copilot, Cursor, Claude Code, Lovable, Bolt have made engineering dramatically faster. GitHub’s own research found developers completed tasks roughly 55% faster with Copilot. Some teams report larger gains on scaffolding and boilerplate. Execution is no longer the constraint.
The new constraint is: What do we actually build, for Whom, and Why? That is a product management question. PM is becoming the new bottleneck. I don’t see PM work becoming faster at the same speed as engineering” — Andrew Ng
Most PM workflows (user research, feedback synthesis, prioritisation, spec writing) were built for a world where engineering was slow. We have not kept pace.
Get Saurabh Bhatia’s stories in your inbox
Join Medium for free to get updates from this writer.
Marty Cagan, in his A Vision For Product Teams essay, framed the same shift from the other side. The Product Owner role which acts as the coordination layer, the ticket writer, the backlog groomer, is being absorbed. By AI. By engineers who now own more of their own discovery.
“Product owner is a role in the delivery process and that is a very easy kind of thing for an assistant to make a big dent into.” — Marty Cagan
Two of the most respected voices in product, coming at the same conclusion from different angles. The administrative shell of the PM role is being automated. What is left is the substance.
The New Skill I’m Working On
Here is the shift I have been making personally, and the one I think every PM needs to make.
In the old model, the PM wrote the spec and handed it to the engineering team. The engineering team spent three months building it. Then we tested it with users and discovered, often painfully, what we got wrong.
In the new model, the PM builds the prototype first. Not a wireframe. Not a Figma mock-up. A working, clickable, functional prototype (built with tools like Lovable, Replit, Bolt, Claude Code) validated with real users before a single line of production code is written.
This matters for two reasons.
- First, speed. You can now go from idea to testable product in a weekend. If the feedback is bad, you have lost two days, not two months. The cost of being wrong has collapsed. That changes how aggressively you should test your assumptions.
- Second, clarity. When engineers see a working prototype, the handoff is dramatically cleaner. There is no ambiguity about what “the button should feel fast” means when they can click the button themselves. PMs who can build say what they mean in the most precise language possible, i.e. working software.
“Once the barriers to entry go so low, what’s left is product sense. Can you really see and understand what people need? The tools lower the floor. Product sense is still the ceiling” — Marty Cagan
What Actually Gets Automated (And What Does Not)
Let us be precise here, because there is a lot of noise.
AI is genuinely good at writing first-draft PRDs, summarising user research, generating OKRs, creating low-fidelity wireframes, analysing usage data, drafting user stories in Jira. These tasks are real, and they consume a meaningful share of a PM’s week (roughly 50%)
AI is not good at deciding which problem is worth solving, navigating organisational politics, holding the product vision when the company’s incentives pull in the wrong direction, making strategic trade-offs that require understanding the competitive landscape and the customer relationship simultaneously.
“While AI will get there eventually, right now it isn’t good enough for the depth and judgment I’d expect from senior PMs.” — Shreyas Doshi
He observed two failure modes in the field, PMs who avoid AI entirely, and PMs who outsource their judgment to it. Neither extreme serves the role well.
The PMs gaining the most ground right now are the ones who have automated the execution layer (research synthesis, spec drafts, data pulls) and reinvested those hours into the two things that matter most: talking directly to customers and making the hard calls.
All this leads me to one direction: More PMs. I know this is counterintuitive, but the data is unambiguous.
Lenny Rachitsky’s “State of the Product Job Market in Early 2026” shows PM openings at their highest levels in over three years, with more than 7,300 roles globally and growing 14% year over year. AI PM roles specifically are, in his words, “absolutely exploding.”
This tracks with Andrew Ng’s economics argument. As engineering gets faster and cheaper, the relative scarcity shifts to the people who decide what to build. More products can be built. More product bets can be placed. More product thinking is needed to make sense of all of it.
Sharing a conversation from a friend in Duolingo. Duo released more courses in the last one year than in the previous twelve combined. This is a direct consequence of AI-accelerated content production. Every Duolingo-scale productivity unlock creates new surface area that needs a PM to own it.
The fear that AI replaces PMs confuses automation of PM tasks with automation of the PM role. They are not the same thing. The role is expanding. Its just that the tasks inside it are changing.
What This Means For You
If you are a PM today, here is the honest version of what I believe is coming.
The coordination-heavy, meeting-heavy, ticket-management version of the role will shrink. If that is most of your job description right now, you are in the category Marty Cagan described as “at big risk.” This is a structural shift, the same way mobile reshaped roles a decade ago. The version of the role that survives and grows is the one that is closest to the user, closest to the strategy, and capable of building fast to validate early.
That means picking up vibe coding, even if you are not an engineer. It means treating user validation as a daily discipline, not a quarterly exercise. It means being the person in the room who can say:
“I built a version of this last Thursday using Claude Code and here is what the users said after using it” — Future You
The bar for what “good PM work” looks like has gone up. That is not a threat. It is an opportunity for the PMs willing to evolve, i.e. for all of us.
Let’s connect to discuss more on Product Management. I’m always happy to connect.
