Project-Chosen Leads and the Mutt Hire
PM is a role on a project, not a department — and you staff it with multi-disciplinary makers, not title-holders.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 88%
The Browser Company has no PM org. Product management is treated as a set of verbs that any good hire can perform, so the lead of each project is chosen for that project: an infrastructure engineer leads a performance project; someone from the membership team leads a member-serving project. This works only because they hire 'mutts' — deliberately multi-disciplinary people whose identity is 'I make things and I'll do whatever the verb requires', not 'I am a PM'.
Origin
Josh Miller — himself a former Facebook PM who says he loves product management. He offers the framework with an unusual level of self-doubt, citing Evan Spiegel at Snapchat as a founder who was indignant that he'd never hire PMs and whose organization now has many, and noting Stripe as another company that waited a long time because its designers and engineers were exceptional. He predicts he will 'come crawling back to your podcast in a couple of years' to admit Lenny was right.
Core principles
- 01Unpack the verbs a PM actually does. Miller's claim is that those verbs are within reach of anyone he would hire.
- 02The lead should be picked for the project, not because of the org they sit in.
- 03The unwavering commitment is not 'no PMs' — it is hiring multi-disciplinary makers. Even if they later hire for the PM role, they want people who see themselves as makers with many tools.
- 04'Mutts' (Miller's endearing term): e.g. Rebecca — data scientist at Quora, a PhD from MIT in behavioural psychology, then a software engineer at Stripe — who now effectively plays a PM role while leading the data team.
- 05The mindset test: 'I make things and I will do what I need to do to make what I want to make, whatever that verb is, whatever that discipline is.'
- 06Assume you don't know: try the prototype and assume it is not going to work. Miller openly says designers are already telling him the PM verbs are eating the time they need to think, dream and design.
How to run it
- 1
Decompose the PM role into verbs
Instead of asking whether you need PMs, list what a PM actually does on your projects — the writing, prioritizing, coordinating, deciding. Ask honestly whether the people you hire can do those verbs.
- 2
Assign the lead per project by fit
Pick the lead based on what the project actually is. A performance project should obviously be led by an infrastructure engineer. A project that is fundamentally about serving members in a specific way should be led by someone from the membership team, because the software is in service of the member relationship.
- 3
Hire mutts, not titles
Screen for multi-disciplinary practice and, more importantly, a multi-disciplinary approach to work — people whose self-concept is 'I make things; tell me how I contribute to making it'.
Pro tip Look for résumés that don't parse cleanly into one lane. That illegibility is the signal, not a red flag.
- 4
Watch for the strain and pre-commit to changing your mind
Track whether the makers are losing their craft time to coordination. Miller already hears from designers that the PM verbs are consuming the hours they need for thinking, dreaming, design and user research — and he expects the model to evolve.
Pro tip If you do add the discipline, evolve it out of a team that already has the adjacent skill — Miller's guess is a technical-PM/data hybrid grown out of Rebecca's data team.
Watch out Lenny's warning from repeated observation: engineers and designers who volunteer to cover PM work eventually hate it and want their craft back; and the anti-PM reflex is usually a reaction to bad PMs, not to the role. A great PM makes everything better, everyone happier, and things move faster.
In the wild
Rebecca was a data scientist at Quora, holds a PhD from MIT in something like behavioural psychology, and was a software engineer at Stripe. At The Browser Company she leads the data team and effectively plays a PM role on multiplayer product work — hired for her maker mindset rather than a lane.
→ The company gets PM function without a PM org, and Miller expects that if they ever formalize the discipline it will grow out of Rebecca's team as a technical-PM/data hybrid.
Miller recalls Evan Spiegel being adamant that Snapchat would never hire PMs — everyone would be a designer. Snapchat now has many PMs, and Miller assumes that was for a very good reason. He cites it as evidence he is probably wrong.
→ He frames the no-PM structure explicitly as a prototype, holding it alongside the value 'assume you don't know: try a prototype and then assume it's not going to work'.
Common mistakes
Believing you'll never need the discipline
Miller names his own likely error. Snapchat and Stripe both eventually hired PMs; the anti-PM stance is a stage, not a permanent truth, and pretending otherwise leaves your makers drowning in coordination.
Mistaking bad PMs for the PM role
Lenny's on-air correction: the PMs who show up and add process and complexity are simply bad PMs. A great one makes everything better and faster, so 'no PMs' may be solving for a hiring failure.
Ignoring career-path gravity
As you scale, hybrid roles become hard to sustain because people need a legible path. Structuring around project-chosen leads without any answer to 'what's my career path' will eventually force the org into lanes anyway.
Is it for you?
Best for
Small craft-driven teams of unusually senior, multi-disciplinary makers who want the PM function performed without creating a PM department.
Not ideal for
Scaling organizations that need career ladders and functional depth, or teams whose engineers and designers are already stretched and resent coordination work.
From the transcript
“membership team the storytelling team and others and even product management we don't have PMS at the company but I'm my you know my title…”
“I think the thing that will become that will be unwavering is we like to hire mutts and I haven't yet”
“have the mindset of I make things and I will do what I need to do to make what I want to make whatever that…”
“this goes back to the assume you don't know the assume you don't know is try a prototype and then assume it's not gonna work”
From the episode
Competing with giants: An inside look at how The Browser Company builds product
Josh Miller (CEO)