The Four Big Product Risks
If you internalize one framework from this entire domain, make it this one. Marty Cagan's four big product risks are the cleanest model I know of what a product team is actually managing, and, crucially, who owns what. Every product that fails, fails on at least one of these four. Every product decision is a bet across all four. And the reason the PM job exists at all is that someone has to hold the two risks no one else is accountable for. Cagan's framing, my conviction.
#The four risks
Before you build anything, you face four questions. Most teams answer one and ship, then discover the hard way which of the other three killed them.
| Risk | The question | Owner | Killed by |
|---|---|---|---|
| Value | Will customers want it, enough to buy, switch, or keep using it? | PM | Building something nobody needs |
| Usability | Can users figure out how to use it? | Design | A great idea no one can operate |
| Feasibility | Can we build it, with the time, skills, and tech we have? | Engineering (tech lead) | Overpromising what's buildable |
| Viability | Does it work for our business, across margin, legal, brand, sales, and partners? | PM | A product users love that the business can't sustain |
#Who owns what, and why it's the PM job
Look at the ownership column. Usability is design's. Feasibility is engineering's. Value and viability are the PM's, and that pairing is the product management job in one line. It is not arbitrary. Design has the craft to judge usability. Engineering has the expertise to judge feasibility. You do not overrule either (The Product, Design, and Engineering Venn). But value and viability require someone with the full context, meaning user insight, market, business model, and GTM, and that is the only seat with all of it. So they fall to you.
In my experience, value is the risk teams most reliably under-test. It is the hardest to assess, because you cannot ask users if they will want something they have never seen and trust the answer, and it is the most tempting to assume ("of course they'll want it"). Continuous Discovery exists almost entirely to attack value risk before you spend engineering's time on feasibility. Skipping value validation is how you build a beautifully engineered, perfectly usable product that nobody uses.
Viability is invisible until it bites: the feature that violates a regulation, torches your unit economics, confuses your brand, undercuts sales, or breaks a partner deal. A PM who only fights for the user and ignores viability is not a user champion. They are half-doing the job. This is where Business Acumen and Models and the DHM model's margin-enhancing lens live. Loving the user and protecting the business is the trade-off only you can make.
#Test risks before you build, not after
The deepest point in Cagan's framing is not the taxonomy. It is the sequencing. Address these risks in discovery, before you commit to delivery. The classic, expensive failure is treating all four as build-time problems: you spec it, build it, ship it, and only then learn it had no value or was not viable. By then you have spent your most expensive resource, engineering time, to learn what a prototype or a few interviews could have told you in a week. This is the whole logic behind separating discovery from delivery while keeping them on one team (see Product Teams vs Feature Teams).
On any meaningful initiative, before building, ask all four out loud and assign each an owner and an evidence level: do we know, or are we assuming? The risk you are assuming hardest, with the least evidence, is where your discovery should go first. This turns a vague "let's de-risk it" into a specific, ownable plan, and it dovetails with Risk Identification and Mitigation for the execution-phase risks that come after these four.
#AI adds dimensions, not new risks
For AI products, the four risks still hold, because value, usability, feasibility, and viability are timeless. But feasibility and viability acquire sharp new edges. Can the model do this reliably? That is a feasibility question with a probabilistic answer. Does the inference economics work? That is a viability question SaaS never had to ask. More in Building AI Products.
#Continue Reading
- Understanding Trade-offs for making the call across the four axes when they conflict.
- Continuous Discovery for the practice built to attack value risk before delivery.
- Product Teams vs Feature Teams for why discovery and delivery must live on one team.
- The Product, Design, and Engineering Venn for the ownership split, in picture form.
- Business Acumen and Models for the business fluency that viability risk demands.