PM to engineer ratio: why a CPO regrets product management – and still hires PMs
Marc GasserSoftware Entrepreneur · GTM & MarketingConnects AI with revenue operations and builds autonomous GTM systems for predictable growth.
TL;DR
- The classic pod ratio – one PM and one designer per six engineers – is an HR convention from the scaling era, not a product principle. Whatnot CPO Tom Verrilli staffs PMs where there is a specific need instead: “You hire one where there's really specific need.”
- Product management is a trade, not a title: a skill that grows through repetition. Put a PM in front of every team and you untrain the decision muscle of engineers and designers – Verrilli calls it “infantilize”.
- AI shifts the maths: one senior PM with data access and code context now replaces the coordination output of several junior PMs. The precondition is context for everyone – otherwise fewer PMs just means less product work.
Key findings
- 31,832 people applied to be a PM at Whatnot in two years; one person was hired. Not meant as deterrence but as diagnosis: the PM title is common, the core skill is rare.
- Whatnot maps PMs to problems, not teams: every six months, leadership defines what needs to be true and assigns one DRI per item – engineers and designers included. Teams sometimes run a year without a PM even though product work happens.
- The hiring anti-pattern: candidates whose speciality is “driving alignment” and stakeholder management. In demand: macro and micro thinking plus impatience to validate assumptions quickly.
- Senior people stay in IC work: Verrilli's PM managers spend over 90 per cent of their time hands-on, he himself around 50 per cent – “you can't make good macro decisions without the micro.”
Why does a CPO say he regrets product management?
Because the phrasing forces the team to justify every PM position. At Whatnot, the PM to engineer ratio follows no fixed formula: “We regret that product management exists” doesn't mean abolishing PMs – it means not hiring one just because the org chart has an empty box.1
Tom Verrilli leads the product team at Whatnot, the live-shopping platform considered the fastest-growing US marketplace business; before that he spent seven years at Twitch, most recently as chief product officer, and was director of product growth at Twitter. Talking to Lenny Rachitsky, he explains the credo like this: “You don't hire a PM just for the sake of hiring one. You hire one where there's really specific need.”1
He published the accompanying number himself: in two years, 31,832 people applied to be a product manager at Whatnot. One person was hired. The team counts just over 20 PMs – small measured against the merchandise volume the platform moves. This article takes the provocation seriously and asks what a DACH org chart can adopt from it.1
Where the pod ratio comes from – and why it never was a product principle
The pod ratio emerged as a scaling reflex, not a design decision. Verrilli's reconstruction: product management originally didn't exist – founders talked directly to engineering and design. Only the growth speed of internet businesses forced delegation, and at some point “this HR ratio of a pod popped into being”: six engineers, one designer, one PM, one engineering manager.1
The consequence on products with billions of daily users: a lot of engineers, hence a lot of PMs – including where there is little to decide. “You probably don't need a PM for notifications infrastructure,” Verrilli says. And more sharply: too many PMs “infantilize the engineers and the designers who are perfectly capable of making good decisions, but just never had to because there was always a PM to babysit them.”1
The ratio also generated its own work. More layers mean more alignment meetings, more reviews, more layers of translation – systems beget systems. Anyone who has watched a squad model fail under its own coordination load knows the mechanism.1
PM is a trade, not a title: the muscle argument
According to Verrilli, the only solid argument for PM as a specialist role is also its risk: “It's a trade, not a qualification. It's something you get good at by doing. It's a muscle.” Muscles grow through repetition – and atrophy when someone else does the reps.1
That is why the pod logic cuts twice: it spreads the scarce core skill across too many positions while taking away the engineers' and designers' opportunity to train the decision muscle themselves. What remains is a role profile Verrilli recognises instantly in interviews: candidates “whose specialty wasn't technical, it was politics.”1
In the conversation, Lenny Rachitsky points to Marty Cagan's term for it: product theatre – the activity looks like product work but consists of meetings, documents and framings for leadership. Verrilli's hiring practice draws the consequence: every candidate works a case study with real data and defends their position verbally. “How quickly the thinking decays from folks who are good at the theater but not the specifics is kind of really telling.”1
How to map PMs to problems instead of teams
The core of the Whatnot model is a different allocation mechanism: PMs don't belong to a team, they belong to a problem. Every six months, leadership defines what needs to be true – outcomes and critical projects – and assigns one directly responsible individual (DRI) per item. Only then is it decided who the right person is.1
Translated for a DACH org chart, that means: First: plan problems, not boxes – the planning list names results (“what needs to be true”), not team assignments. Second: allow non-PM DRIs – an engineer or designer can lead an initiative but goes through the same product reviews as everyone. Third: accept PM-free phases – a team can run for months without a PM as long as the product context is there. Fourth: rotate PMs regularly. Verrilli's reasoning: “You're going to work out more muscle groups by moving around on the things you work on.”1
To keep this from tipping into arbitrariness, Whatnot holds two disciplines against it. “Verify then trust”: leadership doesn't delegate blindly but periodically sits in the details – the CEO will clear his calendar to walk through tickets, code and data line by line with the team. And “know then go”: think through all the scaling and risk questions once, then move anyway. Product work remains work; it just no longer gets stapled to a role automatically.1
Does this initiative need a dedicated PM?
A DRI from engineering or design with good product context is enough. The product work remains mandatory – it just no longer hangs on a role.
Answer the six questions for one concrete initiative – not for a team. The result shows whether you need a PM, a sparring partner or, above all, context.
Why your best people should do IC work
The second shift concerns the career ladder. “We took all of our A players and then promoted them out of doing things,” Verrilli says about the old world. At Whatnot, even the PM managers spend over 90 per cent of their time on IC work, the CPO himself around half.1
The argument is efficiency, not nostalgia: an experienced product leader with fifteen years of instinct decides faster and sees more of the board – “why wouldn't you want Messi playing for your team rather than trying to have the academy coming along all the time?” Whoever holds several areas at once aligns them as a side effect and saves the months of negotiation between competing teams.1
Verrilli also answers the compensation question calmly: add up the pay of an entire PM pyramid and you can pay three exceptional ICs at VP level instead. The movement is real – the conversation cites the list of CTOs of major tech firms who joined Anthropic as individual contributors. For those affected it means: IC work is no longer a demotion, it is where the impact happens.1
The precondition nobody talks about: context for everyone
The whole model rests on one assumption: engineers and designers only make good product decisions when they have the context for them – customer signals, business goals, code reality. Verrilli says it explicitly: it would be “way better if engineering and design had the context that they needed to just make great decisions”. And he names the reason this is now within reach: “It's easier to kind of like converse directly with the codebase and talk to engineers than it ever has been.”1
Exactly this precondition is Teklens's job: the Context Engine reads Jira, Confluence and your real code and gives everyone on the team the context of your best PM – priorities with reasoning, specs proven against the code, answers to “what was ever decided about this?”. The sentence that always travels with this category belongs here: Teklens doesn't replace your PMs. It takes over the work that keeps them away from the product – so the few, senior PMs work where Verrilli puts them: on the hardest problems. Whether that holds for your org chart is fastest to settle in 30 minutes with a founder.
The strongest argument: the numbers behind the regret
Finally, the evidence the model hangs on. Whatnot, as the fastest-growing US marketplace business, moves billions in merchandise volume – with just over 20 PMs, loosely organised into three groups (buyer, seller, trust & risk) and regularly redistributed onto problems. The organisation that would be understaffed by any pod formula ships faster than the formula would have allowed.1
And the 31,832 applications with one hire are not an arrogance anecdote but a diagnosis of the market: the title has inflated, the core skill has not. Verrilli keeps hiring – two people in one day shortly before the conversation – but against need, not against a ratio.1
That closes the arc to the opening question. “We regret that product management exists” is not a rejection of product management – it is the sharpest available phrasing for tying the role back to its purpose. The pod ratio answered the question of how many PMs per engineer. The better question was always: where does this product currently need the skill of making decisions – and who has the context for it?
Frequently asked questions
Does “We regret that product management exists” mean we should let PMs go?
No. Verrilli himself employs just over 20 PMs and keeps hiring. The phrasing shifts the burden of proof: every PM position needs a concrete problem, not an empty line in the org chart. Existing PMs move onto the hardest initiatives instead of permanent coordination.
Does the model work outside consumer marketplaces?
The mechanics – mapping PMs to problems, DRIs from every function, senior ICs – are industry-independent. The ratio itself is not: regulated B2B environments with compliance gates and enterprise stakeholders justify more dedicated product work. Verrilli doesn't see the dividing line at consumer versus enterprise anyway, but at the culture of the organisation.
What about engineers who don't want to do PM work?
Legitimate – specialisation works both ways, says Verrilli: an infrastructure lead may opt out of alignment work. Then the initiative gets a PM. What matters is that the allocation follows need, not automatism.
How does leadership avoid losing touch when layers disappear?
Through “verify then trust”: periodically getting into the details yourself – tickets, data, code – instead of only consuming reviews. Verrilli's observation: without the micro level there are no good macro decisions. AI tooling makes that depth possible in minutes today instead of weeks.
When is a dedicated PM worth it again?
When a problem has persistently high decision density: unclear problem space, many domains, high stakes, dense customer contact. Then PM as a specialisation is exactly what Verrilli describes: concentrated product work on what has to go really well.
Recommendations
- List initiatives, not teams. Walk through the running initiatives and mark where product decisions are actually pending. PM demand comes from problems, not headcount boxes.
- Phrase half-year goals as “what needs to be true”. Outcomes and critical projects, one DRI each – engineer, designer or PM. Whoever is DRI goes through the same product reviews as everyone else.
- Test hiring for substance, not theatre. A case study with real data, the position defended verbally. That separates more sharply than any interview story about “driving alignment”.
- Keep senior people in IC work. Reserve a fixed IC share for directors and VPs and reward it in compensation – otherwise you promote your best people out of their impact.
- Build the context first, then the new ratio. Engineers and designers can only decide what they can see. Only once customer signals, goals and code knowledge are accessible can you concentrate PM positions on problems.
- Measure the transition by decisions, not by mood. If decisions without escalation rise and waiting time for PM capacity falls, the new distribution works. If not: check the context before refilling positions.
Scope & caveats
- All figures and quotes in this piece come from a single conversation: Lenny's Podcast with Tom Verrilli (2026). They are self-reports by an involved CPO, not independently verified; quotes are taken from the transcript and minimally smoothed for readability.
- Whatnot is a consumer live-commerce marketplace with product-minded founder CEOs and a culture tuned to this model. Verrilli himself stresses it won't fit everywhere – and advises: “assume that at least half of what I've said is wrong.”
- In the DACH B2B mid-market, with a grown codebase and regulation, compliance gates, enterprise stakeholders and customer access can justify a higher PM share than at Whatnot. The direction of the argument stands; the target ratio depends on context.
- The Teklens statements describe product capabilities, not measured customer results; pilot metrics are still pending.
Sources
Every external figure and quote in this piece – linked so you can verify it.
- 1.Lenny's Podcast, «This CPO regrets that product management exists» – Tom Verrilli (Whatnot), 2026 ↗ – All quotes and figures in this piece come from this episode; original quotes kept in English.
The takeaway
Whether your PM to engineer ratio is right isn't decided in the org chart but in the build phase – where decisions meet code. Distribute the product work to where context and need come together; the cycle of discover, define, build and operate shows you where that is.
Keep reading in the PM Lab
Related deep dives – from the same pillar and the adjacent phases.
Matching use cases from the library
From the article straight into practice: these use cases put the concepts to work with Teklens.
No new piece without you.
New articles, new interactive tools, new evidence – in your inbox first. And when you reply, we reply: you write directly with the authors, not with a no-reply.
No spam, no sharing, unsubscribe any time.