Lenny's PodcastThis CPO regrets that product management exists | Tom Verrilli (CPO of Whatnot)
CHAPTERS
- 0:00 – 3:19
Why “too many PMs” can infantilize engineers and designers
Tom opens with the idea that product management became over-normalized via staffing ratios (e.g., 6 engineers + 1 PM). He argues this can reduce ownership and decision-making reps for engineers and designers, turning PMs into babysitters rather than leverage.
- •PM hiring often follows a default “pod ratio,” not actual need
- •Excess PM coverage can reduce autonomy for engineering/design
- •Great PMs are memorable because many PMs add limited value
- •Not every domain (e.g., infra/notifications) needs a dedicated PM
- 3:19 – 8:21
“We regret that product management exists”: the real meaning (and why it’s a forcing function)
Tom explains the provocative phrase as a reminder to justify PM roles rather than assume them. His ideal is teams where engineers/designers have enough user and business context to make product decisions—PMs should be added only when specialization is truly required.
- •Product management is a modern specialization, not a timeless necessity
- •PM is a learned trade (muscle built by reps), not just a credential
- •Specialization helps, but over-specialization weakens other functions’ product muscles
- •The goal isn’t “no PMs,” it’s “PMs where there’s specific need”
- 8:21 – 15:19
When specialization makes sense: avoiding “PM work” as bureaucratic overhead
Lenny raises the practical concern that engineers/designers may not want PM chores (docs, meetings, alignment). Tom agrees specialization is valuable in some contexts—especially where customer listening, ambiguity reduction, and decision-making craft matters—but insists culture must support shared ownership.
- •Some roles (infra, scale) legitimately prefer to avoid product minutiae
- •Customer problem discovery is a real skill that not all engineers naturally have
- •Culture must allow engineers/designers to be DRIs on product work
- •PMs should be allocated to problems/projects, not automatically to teams
- 15:19 – 17:28
How Whatnot structures the PM org: ~20 PMs, rotating across priorities
Tom describes Whatnot’s lean PM team (just over 20) and how they’re organized loosely by buyer, seller, and trust/risk. Planning is run top-down every six months, then DRIs are assigned; PMs are frequently reallocated to the highest-priority gaps rather than fixed pods.
- •Whatnot has ~21–22 PMs despite large GMV scale
- •Loose groupings: buyer, seller, and trust/risk
- •6‑month planning sets outcomes/critical projects, then assigns DRIs
- •PMs move regularly; ownership follows priorities, not org charts
- 17:28 – 19:41
31,832 applicants, one hire: what Whatnot screens for (and what’s “trending down”)
Tom breaks down what he now values most in PM hiring—and what he actively filters out. He’s skeptical of “stakeholder management” and politics-heavy PMing, and looks for PMs who can connect macro systems thinking with fast, specific execution and defensible decision-making.
- •“Alignment/stakeholder management” can signal politics as a core skill
- •Whatnot emphasizes case studies to test real thinking, not presentation
- •Looks for macro + micro: systems view plus impatience to validate quickly
- •Prefers builders/decision-makers over caretakers in high-inertia orgs
- 19:41 – 22:10
Building systems thinking: ‘What if it’s green? What if it’s red?’
Tom shares a practical way to develop systems thinking: always play out decision trees and second-order effects before shipping. He emphasizes ‘know then go’—do the mental work to anticipate scale and risks, then move fast with confidence.
- •Ask: “What do we do if results are green vs. red?”
- •Pre-think scale: “What breaks at 1,000x usage?”
- •‘Know then go’: anticipate risks, then execute anyway
- •Systems thinking reduces fear-driven slowdown (legal, finance, other teams)
- 22:10 – 25:52
The shift back to senior ICs doing real IC work (the “Messi” argument)
Tom argues the industry mistakenly promoted the best PMs into management-heavy roles and away from impact. At Whatnot, even managers spend the vast majority of time doing IC work, because senior judgment plus hands-on context leads to faster, better decisions and less organizational politics.
- •Promotion often removed top PM talent from doing the work
- •At Whatnot, PM managers still spend ~90% time as ICs
- •Senior ICs can cover broader surface area with better judgment
- •Putting one owner across competing goals reduces politics and thrash
- 25:52 – 35:22
What “IC PM work” really means: tickets, data, codebase literacy, specs, shipping
Tom clarifies IC work isn’t necessarily writing production code—though he has done it—but being deeply connected to ground truth. The emphasis is on direct engagement with customer problems, data, and how systems actually work, enabling quick, high-quality decisions.
- •IC PM work includes support tickets and direct customer problem exposure
- •PMs should pull/understand data themselves, not outsource the thinking
- •Use AI to query/understand the codebase and estimate effort
- •Specs, standups, execution loops are core IC responsibilities
- 35:22 – 41:01
AI at Whatnot: data science leverage, faster debugging, real-time product feedback loops
Tom highlights AI’s biggest productivity unlock as self-serve analysis that used to take weeks of DS time. He also describes AI-enabled regression detection and an unusually tight loop: watching users live while simultaneously inspecting code behavior to distinguish bugs from comprehension gaps.
- •Biggest unlock: data analysis (Hex threads) faster and more nuanced
- •PMs do more analysis with fewer DS interactions than before
- •AI helps spot regressions/interaction effects faster, enabling faster shipping
- •Live + AI: observe users and inspect code behavior in real time
- 41:01 – 42:48
The “data scientist problem” and what strong orgs do instead
Lenny notes DSs are increasingly asked to validate questionable analysis produced by non-DSs. Tom agrees but points to the root cause: weak data foundations (data engineering, labeling, taxonomy), and stresses that AI doesn’t remove responsibility for correctness—it increases leverage for those with judgment.
- •DS time shifts from doing analysis to auditing others’ analysis
- •Root cause often: underinvestment in data engineering/labeling
- •Best DSs move upstream to improve data systems and attribution
- •AI output still requires accountable, skilled interpretation
- 42:48 – 46:28
Roles trending up/down and the product team of the future (more freedom at the edges)
Tom predicts fewer specialists may be needed for the same output, but that doesn’t necessarily mean fewer hires overall—teams can build more faster. He expects growth in “EM-light / tech lead” roles for small incubations, and a future where formal teams exist for high-conviction bets while everyone can opportunistically improve the product.
- •“Fewer for the same output” can still mean building more overall
- •Trending up: small-team tech leads / EM-light roles for incubations
- •Formal pods reserved for high-conviction projects with clear paths
- •More ‘free space’ for any function to fix/ship improvements
- 46:28 – 49:23
Core PM skills are most durable in an AI world (but ‘PM theater’ is fading)
Tom agrees that as building becomes cheaper, the durable advantage is deciding what to build and aligning customer, business, and tech realities. He argues the industry rewarded storytelling and alignment too much, creating a class of PMs strong at theater but weaker at hands-on product judgment—case studies expose this gap quickly.
- •Durable leverage: customer understanding + business sense + technical translation
- •AI amplifies judgment; it doesn’t replace it
- •PM theater (frameworks/storytelling) has less place to hide now
- •Case studies reveal who can defend decisions with specificity
- 49:23 – 53:32
How to get the most from hires: ‘verify then trust’ and founders clearing the day to find truth
Tom rejects a simplistic ‘hire great people and get out of their way’ interpretation. He advocates leaders working alongside teams to learn micro details that inform macro decisions, and cites Whatnot’s founder behavior—pausing reviews to clear the day and dive into tickets, data, and code until the truth is understood.
- •Prefer ‘verify then trust’ over blind delegation
- •Leaders must understand micro details to make good macro calls
- •Founders set tone by deep-diving immediately when something feels off
- •Planning aligns priorities; deep work ensures execution quality
- 53:32 – 1:06:36
Founder–CPO dynamics, pushing back effectively, and ‘play the accordion’ (strategy ↔ iteration)
Tom shares how he avoids duplicating founders’ involvement (‘two dads problem’) and frames the CPO role as translating founder vision into execution without competing for ownership. He then explains ‘play the accordion’—continuously zooming out for direction and zooming in to ship and learn—illustrated by marketplace trade-offs like listings vs. search/discovery.
- •If founders own an area, Tom often steps out to avoid conflicting direction
- •Pushing back: start with curiosity, ask if minds are made up, use data when possible
- •If it’s just opinions, founder/CEO opinion wins—don’t fight for ego
- •‘Play the accordion’: alternate between strategic zoom-out and fast V1/V2 shipping
- 1:06:36 – 1:24:57
Agentic commerce vs. live commerce, Twitter lessons, failures, and closing lightning round
Tom argues agentic commerce will dominate high-intent, repetitive purchases, but live commerce serves low-intent, social discovery shopping—closer to the mall experience at internet scale. He reflects on Twitter’s chaos (and PMF/network effects), shares a failure lesson about misleading averages, then closes with books, favorites, and a memorable Whatnot purchase: a live lobster.
- •Agentic commerce fits high-intent/utilitarian purchases; live commerce fits social/low-intent discovery
- •Live commerce can be economically viable with small audiences due to commerce economics
- •Twitter: PMF and network effects can survive organizational dysfunction; delays often signal weak leadership
- •Failure lesson: averages hide critical minority use cases; anecdotes can reveal truth
