Need-Based Product Management
Deploy PMs against critical problems instead of staffing every engineering team
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 96%
This model replaces the default assumption that every engineering team needs a permanent product manager. Leadership first defines the outcomes and critical projects that must be delivered, assigns a directly responsible individual, and then determines whether specialized product management is actually required. PMs move between problems according to urgency and fit, while engineers and designers can lead initiatives if they complete the same discovery, review, and decision work. The mechanism preserves product-management capacity for ambiguous or high-leverage challenges while giving other disciplines the repetitions needed to develop judgment. It also reduces permanent coordination structures that can encourage teams to outsource decisions to a PM. Success depends on explicit priorities, contextual transparency, rigorous product review, and a culture in which ownership is independent of job title.
Origin
Extracted from Lenny's Podcast, where Tom Verrilli described how Whatnot organizes a small PM group around changing company priorities rather than fixed engineering pods.
Core principles
- 01Treat product management as a trade rather than a mandatory layer
- 02Give engineers and designers enough context to make product decisions
- 03Hire a PM only when a problem requires specialized product leadership
- 04Assign PMs to outcomes and projects rather than permanent team slots
- 05Build product judgment through repeated practice
How to run it
- 1
Define What Must Become True
At each planning horizon, specify the outcomes and critical projects the company must deliver. Keep the list focused enough to force meaningful trade-offs.
- 2
Assign Accountable Owners
Name a DRI for every priority, regardless of whether that person is a PM, engineer, or designer. Make ownership of the result explicit.
- 3
Test the Need for Specialization
Ask whether the initiative requires dedicated skill in customer discovery, ambiguity reduction, financial modeling, recommendations, or another product discipline. Add a PM only where that need is specific.
- 4
Match Skills to Problems
Allocate PMs according to the nature of each priority and the PM's strongest capabilities. Reassign them as company needs change.
- 5
Preserve the Product Standard
Require every DRI to perform discovery, define success, pass product review, and make the necessary decisions. Ownership without the work is not empowerment.
In the wild
Whatnot's leaders define what must become true over the next six months, identify accountable DRIs, and then inspect the list for important work without an owner. A PM may be assigned to such a problem based on the capabilities it requires, even when that PM is not permanently attached to the affected engineering teams.
→ Scarce product talent follows company priorities instead of an inherited staffing ratio.
An engineering group responsible for mature notification infrastructure may already understand its users, constraints, and desired outcomes. Rather than installing a PM by default, the company lets the engineers make product decisions while retaining access to specialist help when a genuinely ambiguous problem appears.
→ Engineers develop decision-making judgment while PM capacity remains available for higher-leverage work.
Common mistakes
Removing PMs Without Transferring the Work
Engineers and designers still need to perform discovery, review, documentation, and decision-making. Eliminating the role does not eliminate its necessary work.
Treating No PM as an Ideology
The model calls for deliberate specialization where needed, not the universal rejection of product managers.
Keeping Permanent Team Attachments
If every PM remains tied to one team indefinitely, the organization cannot direct its strongest product skills toward its changing priorities.
Is it for you?
Best for
It is best for high-agency organizations whose engineers and designers have direct access to customer, business, and technical context.
Not ideal for
It is not ideal for organizations that lack clear priorities, capable cross-functional leaders, or a culture that supports non-PM product ownership.
From the transcript
“you don't hire a PM just for the sake of hiring one, you hire one where there's really specific need.”
“rather than mapping PMs to teams where you kind of assume that the PM will always do that, we tend to map them to kind…”
“And then we sit down and we go through that list and say, who's who's the DRI?”
From the episode
This CPO regrets that product management exists