The PM Owns the Why
Don't spec the what — distribute the why so hundreds of local decisions come out right.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 93%
Yamashita holds product managers uniquely responsible for the why of a product — not the idea, not the what, not the how. Ideas can come from anyone (customers most of all) and the what and how are shared across the company, but if everyone understands why the team is doing something, designers and engineers can make hundreds of local decisions correctly without the PM in the room. He extends the engineering '5 Whys' one step further than usual: past 'why does the customer want this feature' to 'why do they have that problem in the first place.'
Origin
Yamashita learned this by moving from Microsoft — where the PM wrote perfect specs down to a table for every error-handling case — to YouTube, where he owned an entire iOS app and could not possibly specify everything. The 5 Whys itself is a Toyota Production System technique (Sakichi Toyoda); Figma's engineering team runs it in retros and postmortems, and Yamashita ports it to product discovery.
Core principles
- 01The PM does not have to be the person with the idea — that answer is usually 'no.'
- 02Specifying everything does not scale; distributing the why does.
- 03A shared why is what lets local decisions you never see be good decisions.
- 04The first why gets you the problem; the second why gets you the opportunity.
- 05Retros are the environment that surfaces problems — without one, they go unaddressed forever.
How to run it
- 1
Stop trying to specify everything
Accept that on a real-sized team you cannot write a table for every error state. Designers and engineers will make their own choices; your job is to make sure those choices are good ones.
Watch out Spec-perfectionist cultures feel rigorous but cap the team at the PM's bandwidth.
- 2
Make the why legible to everyone
Ensure every person on the team can state why this project exists and what problem it solves. That shared understanding is the mechanism by which decisions made without you still land correctly.
Pro tip Test it by stopping a random engineer in the hallway and asking what problem the team is solving.
- 3
Ask why the customer wants the feature
When a customer requests a feature, do not take it at face value. Back out the underlying problem the feature is a proposed solution to.
Watch out Implementing requests verbatim ships someone else's guess at a solution.
- 4
Take one more why — why do they have this problem at all?
Go one level past the problem statement and ask what condition created the problem in the first place. Fixing the underlying condition is where the larger product impact lives.
Pro tip This is the same move as engineering's 5 Whys root-cause hunt, applied to customer demand rather than to incidents.
- 5
Institutionalize the retro
Run 5 Whys in postmortems when something goes wrong, and keep a broader retro culture so improvements have a venue. If you don't create the environment for the conversation, the issues never get addressed.
In the wild
At Microsoft, Yamashita wrote specs for a small feature crew that specified exactly how everything worked — an error-handling situation got a table defining every case. At YouTube he suddenly owned an entire iOS app with a big team, where the culture was 'the designers can figure it out.'
→ He concluded that broadcasting the why was the only way to scale decision quality, because he could not be present for the local calls.
Figma's engineering team runs an actual 5 Whys in retros and postmortems when something goes wrong — chaining why did this happen, and why did that happen, until they hit root cause.
→ Yamashita ported the chain into product work: customer asks for X, why do they want X, and then why do they have that problem at all — surfacing bigger product opportunities than the original request.
Common mistakes
Believing the PM must be the idea person
Yamashita is explicit that the PM does not have to be the source of ideas — customers generate plenty. Fighting for idea ownership crowds out the actual job, which is owning the why.
Stopping at the first why
Backing out the problem behind a feature request is only step one. Without the second why — why the customer has that problem at all — you keep patching symptoms and never fix the condition producing them.
Is it for you?
Best for
PMs whose teams have outgrown the spec-everything model and who need designers and engineers making good calls without them.
Not ideal for
Highly regulated or safety-critical surfaces where exact behavior genuinely must be specified case-by-case.
From the transcript
“I do think the why is something that I really always hold the PM uniquely responsible for”
“how do you make sure that a great decisions made and if everyone has an understanding of why we're doing this what problem we're solving”
“our engineering team at figma whenever we do at retro or postmortem you know we do this thing called five wise right”
“customer is asking for a feature but then he would say okay why are they asking for it and kind of back out the problem…”
From the episode
An inside look at how Figma builds product
Yuhki Yamashita (CPO of Figma)