Depth-Meets-Breadth Product Review
Run reviews to make the product better, not to interrogate — you bring breadth, the team brings depth
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 85%
A method for running product reviews so they improve the product rather than intimidate the team. You set two explicit goals (accountability/informing, and making the product better — the latter being primary), keep the room small, work from a pre-filled artifact, and show up as a prober rather than a mandate-giver because the team who lives with the problem 40-60 hours a week holds context you don't.
Origin
Brian Tolkin's approach at Opendoor, useful especially for ops-driven companies whose weekly-business-review cadence rarely lifts its head to longer-horizon product direction.
Core principles
- 01State two goals: accountability/informing, and (primarily) making the product better
- 02A review should not feel like a firing squad — fear doesn't produce better products
- 03The people closest to the problem have the best context to solve it
- 04You bring breadth (3 hours/week on the problem); the team brings depth (40-60 hours/week) — marry the two
- 05The artifacts (docs/recordings) are a durable onboarding asset for new hires
How to run it
- 1
Set the two goals explicitly at the top
Communicate that the review exists for accountability/informing an audience AND — primarily — to help the team think through the problem and make the product better.
Pro tip Naming the primary goal as 'make the product better' reframes the room away from performance evaluation.
- 2
Keep the conversation small
Keep the live conversation under ~10 people for the best discussion, even if the document has wide distribution.
Pro tip Distribute the artifact widely but keep the live room tight.
- 3
Work from a pre-filled template
The presenter pre-fills a standard template (context, problem, potential solution, risks/pre-mortem, measurement of success), bucketed by stage (ideation vs. near-launch 'speak now or forever hold your peace').
Pro tip A template is easier for people to work off and sets shared expectations — but don't be a stickler.
Watch out Don't let people just wedge existing content into the template; the value is the thinking, not the format.
- 4
Show up as a prober, not a mandate-giver
Ask questions, throw out ideas explicitly framed as 'this is an idea, not a mandate,' and supply missing context as context (not as a leading question). Push on dimensions the team may not be considering.
Pro tip Borrow Dharmesh Shah's 'flash tags' — hashtags like #FYI vs #suggestion vs #plea — so people know how strongly you mean a comment.
- 5
Set a sign-up cadence with light forcing
Offer open slots (e.g. two per week) teams sign up for as needed, and do a little 'inviting/telling' to make sure every product area cycles through, roughly quarterly.
In the wild
Opendoor runs two product-review slots a week that any product area can sign up for as needed; if a team hasn't been seen in a while, leadership does light 'all-telling' to make sure work cycles through roughly quarterly. Reviews use a pre-filled template and keep the live room under ten.
→ A review culture that surfaces longer-horizon product direction alongside the ops-driven weekly business review cadence.
Common mistakes
Letting the review become a firing squad
A scary, interrogative environment makes teams tense and is not conducive to figuring out how to make the product better.
Confusing template adherence with quality
Making the template doesn't make the content better — people wedging content into the format without the underlying thinking defeats the purpose.
Is it for you?
Best for
Product leaders, especially at ops-driven companies whose weekly-business-review cadence rarely addresses longer-horizon product direction
Not ideal for
Tiny teams where informal hallway conversation already surfaces everything, or cultures where leadership can't resist using the room to evaluate people
From the transcript
“product reviews hopefully are not feeling like firing squads that's that's a a scary environment to be in”
“the people closest to the problems also have the best context to solve that that problem”
“they think about this problem 40 50 60 hours a week and you might think about this problem three hours a week right so you…”
“try and keep it under under 10”
“context problem potential solution uh risks risk premortal and you know me measurement of success”
From the episode
Lessons from scaling Uber and Opendoor
Brian Tolkin (Head of Product at Opendoor, ex-Uber)