Before a single engineer is committed, four risks must be retired: will they value it, can they use it, can we build it, does it work for the business? Marty Cagan's discovery checklist.
The Four Big Risks, from Marty Cagan and the Silicon Valley Product Group, is the discovery checklist every responsible PM runs before committing engineering resources to a new initiative. It names the four categories of risk that must be addressed before building: value, usability, feasibility, and viability.
The framework's power is that it makes the question “what could make this fail?” concrete and exhaustive. Most failed features didn't fail for mysterious reasons — they failed on one of these four risks, and the team simply never checked. Discovery's job is to retire whichever of the four are unaddressed, in order of how likely each is to kill the idea.
Value risk — will users choose to use or buy it?
Usability risk — can they figure out how to use it?
Feasibility risk — can we actually build it, with our tech and time?
Business viability risk — does it work for our business (legal, financial, brand, sales)?
Teams reliably over-test the risk they find easiest to check (usually usability) and ignore the one most likely to kill the idea (usually value).
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Building before checking value | A usable, feasible feature that nobody wants — the most common failure. | Value risk is named and tested first, before resources are committed. |
| Discovering infeasibility late | Engineering hits a wall mid-build that a feasibility check would have caught. | Feasibility is assessed with engineering before commitment, not during. |
| Ignoring viability | A great product that's illegal, unsellable, or off-brand. | Viability forces legal, financial, and go-to-market reality into discovery. |
| Testing only the easy risk | Polishing usability while value goes unvalidated. | All four are checked, so the dangerous gap can't hide. |
For the specific idea, write down what could go wrong in each category. Concrete risks, not generic ones — “will enterprise buyers approve this?” not just “viability.”
Not all four are equally threatening for every initiative. For a novel concept, value risk dominates; for a known need with hard tech, feasibility does. Tackle the deadliest first.
Each risk has a fitting test: value via demand experiments and interviews, usability via prototypes, feasibility via an engineering spike, viability via stakeholder review. Match test to risk.
A risk is “retired” when you have evidence it won't sink the idea. Only when the dangerous risks are retired does the initiative earn engineering commitment.
Risks shift as the concept changes. A pivot can reintroduce a value risk you'd retired — re-run the relevant checks rather than assuming past clearance holds.
A team was excited about a feature and rushed to refine its interface — effectively testing only usability. They'd skipped the question of whether anyone actually wanted it. The polished feature shipped and went unused.
Re-run through the Four Big Risks, the obvious gap was value risk — the riskiest of the four for a brand-new concept and the one they'd never tested. A cheap demand experiment up front would have revealed the lack of interest in days, before any engineering. The usability polish they'd obsessed over was effort spent on the safest risk while the deadliest went unchecked.
The deliverable is the four risks named for this initiative, ranked by threat, each with a test and a status (open / retired).
| Risk | The question | Typical test |
|---|---|---|
| Value | Will they use or buy it? | Demand experiments, interviews |
| Usability | Can they use it? | Prototype + usability testing |
| Feasibility | Can we build it? | Engineering spike / review |
| Viability | Does it work for the business? | Legal, finance, GTM review |
Almost every failed feature failed on one of these four risks — and almost always the team never checked that one. The framework's value is leaving nowhere for the deadly risk to hide.
The discipline is ranking honestly. Teams gravitate to the risk they know how to test — usually usability, because prototypes are tangible and satisfying — while value and viability, which are harder and scarier, go unexamined. But for most new initiatives, value is the risk most likely to kill it. A PM who ranks the four by lethality and tackles the deadliest first spends discovery where it actually protects the build, rather than polishing the risk that was never going to fail.
The easiest risk to check isn't the deadliest. Validate value first for new ideas.
A product can be loved and usable yet illegal, unsellable, or off-brand. Check business reality.
Discovering you can't build it mid-sprint is expensive. Involve engineering early.
Rank them — the deadliest risk for this idea deserves the first, cheapest test.
The four risks are the top-level categories; assumption mapping (Tool 14) breaks each into the specific beliefs to test.
Retiring the four risks is the core work of the discovery loop (Tool 02) before delivery commits.
Each risk maps to a method — fake doors and lean experiments for value, prototypes for usability, spikes for feasibility.
This is the deeper version of Dual-Track's three gate questions from Module 1 — value/usability/feasibility plus viability.
Take a feature you've seen ship and underperform. For each of the four risks, ask: was it actually checked before building? Which one was skipped?
Then rank them as they should have been ranked: which risk was most likely to kill that feature, and was that the one that got tested?
Almost always, the skipped risk was value or viability — and almost always, it was the deadliest. That pattern is the entire case for the framework.
PM Mapped is the complete product-management course — 156 tools, 6 modules, 25 AI deep-dives. Join the waitlist to get in first.
Join the waitlist →Browse all 156 →