The Four Product Risks and Their Owners
Valuable, usable, feasible, viable — any one fails and the product fails
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 92%
Cagan's taxonomy of the four risks every solution must clear, mapped onto explicit owners: engineers own feasible, the designer owns usable, and the product manager owns valuable and viable — the two hardest. He uses the map to demolish the 'PM owns the what, not the how' myth: monetisation, privacy, security, and go-to-market are all 'how', and they are all product responsibilities.
Origin
Marty Cagan / SVPG (INSPIRED). Cagan explicitly notes other taxonomies exist and that the labels matter less than the risks themselves.
Core principles
- 01All four risks are table stakes — failing any one means a failed product.
- 02The PM owns the two hardest risks: valuable and viable.
- 03'What vs how' is a false split; the PM owns a large, integral part of the how.
- 04Owning a risk does not mean dictating craft — you don't tell engineers how to code or designers how to design.
How to run it
- 1
Name the four risks for the solution on the table
For any proposed solution, ask: is it valuable (will people buy/choose it), usable (can they figure it out), feasible (can we build it), viable (does it work for our business)? Write down the specific open question under each.
Pro tip Use whatever labels your team prefers — Cagan's point is the risks, not the vocabulary.
- 2
Assign the owner of each risk
Engineers own feasible. The designer owns usable. The product manager owns valuable and viable. Make the assignment explicit so no risk sits unowned.
Watch out If the PM is only tracking 'valuable' and treating viability as someone else's problem, the business risk is unowned.
- 3
Discharge the viable risk deliberately
Viability spans monetisation, privacy, security, legal/compliance, and go-to-market. Work each with the corresponding stakeholder, using prototypes they can see and sign off on.
Pro tip This is where the PM's business homework pays off — you cannot own viability for a business you don't understand.
Watch out These are the risks most often discovered late, when the solution is already built.
- 4
Kill or rework anything that fails a risk
Treat the four as gates, not scores. A solution that is valuable, usable and feasible but not viable is still a failed product, and vice versa.
In the wild
Cagan mocks the idea that a PM only defines the what: 'do you know how many hours a week I'd need to work if that was my only job... I'd phone it in, 15 minutes a week.' In reality the how includes how it monetises, how privacy and security are handled, and how it goes to market — all product responsibilities.
→ The risk map reframes the PM's job as co-owning the solution's hardest dimensions rather than authoring a requirements list.
Cagan is clear that owning valuable and viable does not license the PM to dictate implementation: 'you don't tell the engineers how to code, you don't tell the designer how to design' — yet all three together produce the how.
→ The team gets genuine shared ownership of the solution without the PM collapsing into a micromanager.
Common mistakes
Treating the four risks as a scorecard instead of gates
Cagan: 'all four of those risks if any one of them fails you've got a failure of a product.' A high average across three risks does not offset a fatal miss on the fourth.
Letting the PM disown viability
Viability — monetisation, privacy, security, compliance, go-to-market — is the risk nobody else on a cross-functional team is equipped to carry. When the PM treats it as 'the business's problem', it surfaces after build, when it is most expensive.
Is it for you?
Best for
Product trios deciding who is accountable for what during solution discovery, and PMs pushing back on a scoped-down 'requirements writer' definition of their role
Not ideal for
Teams with no discretion over the solution at all — the risk map is meaningless if the solution is dictated
From the transcript
“essentially a project management role but on an empowered product team where you're trying to come up with a solution that solves the problem you've…”
“all four of those risks if any one of them fails”
“just you know it probably i'd phone it in 15 minutes a week i'm done i did my part this is ridiculous”
From the episode
The nature of product
Marty Cagan, Silicon Valley Product Group