At Meta, I found something surprising: PMs used to brag about how many engineers they worked with, like gym rats comparing their bench press.
I remember one conversation vividly. It started with the idea that the typical 1:5 PM-to-engineer ratio makes sense for the average PM, but the best PMs can handle much more. One PM bragged that he was working with 10 engineers and barely breaking a sweat. Someone else jumped in: “No, no, no. The best PM I ever worked with had 30 engineers.”
This got me wondering.
Was the PM supporting 30 engineers really three times smarter, better, or faster than the PM supporting 10?
At TripAdvisor, we stayed pretty close to the 1:5 PM-to-engineer ratio. Many of the PMs on my team then are now VPs and CPOs. It certainly was not a talent issue.
That debate has since moved beyond ratios. The question is no longer: How many engineers can a PM support? It is:
Do we even need PMs at all?
Build products customers can’t live without
The free Product Competency Toolkit dives deep into the 12 competencies that turn good product builders into remarkable ones. Updated entirely for the AI era, it explains how each competency is evolving — whether you want to improve your own craft, coach your team, or help your entire organization level up.
It’s for anyone building products across product, design, engineering, marketing, leadership, or a venture of their own.
The death of product management is greatly exaggerated
Claire Vo put the argument bluntly: “Product Management Is Dead.” AI, she argued, can draft documents, process feedback, prioritize features, and generate wireframes. The traditional product trio is giving way to smaller teams of “AI-powered triple threats” who work across product, design, and engineering.
Brian Chesky created a similar stir when he said Airbnb had “got rid of the classic product management function.”
Then Tom Verrilli, Whatnot’s chief product officer, went further: “We regret that product management exists.”
The line sounds like an obituary. His actual argument is more interesting. Whatnot refuses to hire a PM simply because an engineering team exists. It adds one when there is a specific need. Verrilli believes engineers and designers should have enough customer and business context to make good product decisions themselves. Otherwise, a large PM function can “infantilize” capable partners by shielding them from that work.
Similarly, Brian Chesky’s view is more nuanced. Airbnb did not get rid of product work. It combined product management with product marketing, elevated design, and asked product managers to understand not only how to develop a product, but how to explain it.
The product role is shifting. That part is true. As AI takes on more coordination, documentation, and synthesis, the PM as project coordinator, requirements writer, and professional meeting attendee will fade.
What remains is the work that always mattered: judgment, strategy, and a deep understanding of customers. AI raises the stakes for all three. A team moving at 100 miles an hour needs stronger steering than one moving at 10. As building accelerates, knowing where you’re going becomes more important — not less.
A team moving at 100 miles an hour needs stronger steering than one moving at 10.
But that work does not have to live inside a traditionally defined PM role — and increasingly won’t. In the strongest product cultures, founders, designers, engineers, researchers, marketers, and others play an important part.
Which brings us back to the ratio question: When one PM supports 30 engineers, what’s really going on?
The PM-to-engineer ratio tells you where the work lives
A PM-to-engineer ratio does not measure the PM’s talent, bandwidth, or importance.
It measures the organization around the PM.
A PM supporting 30 engineers might work in an organization where the founder sets a clear strategy, designers stay close to customers, engineers help define the product, researchers surface unmet needs, and marketers understand how the product will reach the market.
Or that PM might be an exhausted ticket writer supporting 30 engineers who build whatever sales, executives, or the loudest customer requests.
The ratio is identical. The product cultures are opposites.
The least and most product-centric companies can both end up with fewer PMs — for very different reasons.
The least product-centric companies see PMs as overhead. In the name of efficiency, they cut headcount, whittling away at the role while encouraging everyone to build and ship. The visible work survives because it must. Tickets still need to be written. Questions still need answers. Releases still need coordination.
The job collapses to execution.
The important but less urgent work slips away:
Nobody talks to customers.
Nobody owns the vision.
Nobody connects features to business outcomes.
Nobody protects the quality bar.
The team focuses on building, not deciding what to build.
The most product-centric companies arrive at fewer PMs from the opposite direction. Product thinking is not trapped inside the PM function. Founders, designers, engineers, researchers, marketers, and other partners share the work. Their contributions amplify each PM rather than leave the PM stretched thin.
These companies have not eliminated product management. They have built a culture around it.
The 12 activities that cannot disappear
I originally created the Product Competency Toolkit as an individual development model. PMs use it to understand their strengths and gaps. Managers use it to coach people, evaluate teams, and make better hiring decisions.
But the framework can be read another way. The 12 competencies are not merely the skills of a strong PM. They are the work a strong product organization must do.
The system covers Product Execution, Customer Insight, Product Strategy, and Influencing People.
There is a lot to master — and inherent tension in the work. Product builders must be empathetic and analytical, qualitative and quantitative. They need fastidious attention to detail and the ability to think in broad abstractions. The best are creative innovators and rigorous optimizers.
Join the Top 1% Builder Series
The Top 1% Builder Series is a free 12-part live workshop series (one week per competency) with Ravi for product managers, leaders, founders, designers, engineers, and builders who want to ship products customers love — with AI amplifying the judgment they already have. Live attendance is free. Replays and slides are available to paid Top 1% Builder Club members.
Product management is a team sport
Product management is consequential work, too broad for any one person to master. Remarkable products are built by teams. Each person contributes from a different vantage point, bringing the expertise, insight, and relationships needed to make the product better.
Engineering contributes to Product Definition, Delivery, and Quality. Design and research contribute to Voice of the Customer and User Experience Design. Data science brings Fluency with Data. Sales, marketing, operations, and finance help connect strategy to business outcomes. Team Leadership and Managing Up draw on everyone.
These people are not peripheral stakeholders for a PM to “manage.” They are part of the product system.
This is why strong product companies can run with very different ratios. A PM does not need to spend hours combing through data when the team has an excellent data scientist. A designer who is deeply connected to customers may shoulder more of the discovery work. An engineer can shape the product through prototypes, technical judgment, and a clear understanding of the user.
Lots of people can contribute, but someone still needs to own the outcome. Each activity needs the right people involved and a way to make sure the work happens consistently. Otherwise “everyone owns it” becomes another way to say nobody does.
Strong product organizations make this division of labor explicit. Weak ones copy the org chart, but miss the point.
When building gets cheaper, judgment gets more valuable
AI changes both the speed of product development and who can participate in it. It can generate code, synthesize research, create prototypes, and draft specifications. An engineer, designer, marketer, or founder can now bring a working prototype to the table instead of an opinion.
When building was expensive, capacity imposed discipline. Teams had to choose carefully because every direction consumed scarce engineering time. As that constraint weakens, teams can explore more ideas and produce more versions faster.
AI shifts the bottleneck from building products to judging what deserves to ship.
The challenge is no longer generating another option. It is knowing which option solves a meaningful customer problem, fits the strategy, meets the quality bar, and deserves to reach customers. Empathy, judgment, strategy, alignment, culture, and taste are not secondary to building. They determine whether faster building creates progress or noise.
The idea that everyone should be rolling up their sleeves and building is exactly the wrong one. We don’t need every PM putting a little extra pressure on the gas pedal. We actually need PMs and product orgs spending more time figuring out where we should be going — and probably less time building.
For teams that have been constrained by build capacity for as long as they can remember, the idea that not everyone should contribute to that build capacity is disorienting. But it is absolutely the thing that will separate the companies building what their customers want from companies that are just force-feeding their customers new features to clear their backlog.
Is your product culture shrinking?
The least and most product-centric companies can arrive at the same conclusion — fewer PMs — for entirely different reasons.
After rounds of layoffs, I worry many companies are watching their product culture shrink. The remaining PMs do not have enough bandwidth to do the full job, and the rest of the organization is not picking up the work.
The 12 product management competencies can help diagnose the problem and decide how to solve it.
Take the 12 competencies and ask:
Who is accountable for each one?
Who contributes?
What evidence shows that the work is happening?
Where does it slow down or disappear?
What closes the gap: sharper priorities, clear ownership, more people, or stronger partners?
Be honest. Do not write “Product owns strategy” if nobody can explain the strategy. Do not write “Engineering owns quality” if bugs are piling up. Do not write “Everyone talks to customers” if nobody actually does.
The goal is not to return to a particular PM:eng ratio. It is to make sure the work to create remarkable products still gets done.
You can eliminate the PM role. You can flatten the team. You can distribute the responsibilities. But the work remains.
Product managers may be optional — but only if the rest of your company is ready to do the work.
Product management is not.