Guide

A product can be technically impressive and still fail. Marty Cagan frames that failure as four questions. Almost every dead product fails at least one of them. The useful move is to name which risk is largest on this bet, then spend a few days compressing that risk before a multi-week build.

Concept

Value is whether people will choose this. Usability is whether they can figure it out. Feasibility is whether you can build and run it. Viability is whether it works for the business.

The big idea

  1. Value risk — Will customers choose this over their current workaround? Do they care enough? This is usually the largest risk, and the one engineers underweight because it feels non-technical.
  2. Usability risk — Can people figure out how to use it? A valuable idea with a confusing flow still fails.
  3. Feasibility risk — Can we build it with the skills, time, data and infrastructure we have? Can we operate it at acceptable cost and reliability? This is engineering's home ground — and includes "can the model actually do this?" for AI features.
  4. Viability risk — Does this work for the business: legal, brand, sales motion, margin, compliance, channel conflict? Something users love can still be a bad business.

A smoke alarm is a useful picture. Value is whether people want to know about fires. Usability is whether they can hear it and act. Feasibility is whether you can build a reliable sensor. Viability is whether you can sell it without burning the house down in a lawsuit. The analogy breaks when risks trade off: a highly viable enterprise contract can raise feasibility cost for everyone else.

Walking through it

Spending a sprint on discovery before coding feels slow when stakeholders want a date. Skipping discovery feels fast until you spend three sprints building the wrong thing.

Default: spend a few days compressing the riskiest assumption with interviews, prototypes or a fake door. Full multi-week research projects are for high-stakes bets. Weekly contact covers the rest — see continuous discovery.

No single role owns all four. The product trio owns the combination. Engineers who only speak to feasibility become order-takers. PMs who ignore feasibility invent impossible roadmaps. Designers who ignore viability ship beautiful products that sales cannot sell.

Common mistakes

  • Treating feasibility as the only risk. "We can build it" is not the same as "anyone wants it."
  • Jumping to a six-week build to resolve value risk. Interviews, a fake door or a concierge test are cheaper.
  • Ignoring viability until legal or sales shows up. Channel conflict and margin show up late and kill shipped work.

Check yourself

  1. Users love a prototype, design is clear and engineering can ship in two weeks. Which risk is still open?

Viability: legal, brand, margin, sales motion or compliance may still make it a bad business.

  1. A stakeholder wants a date before anyone has talked to a customer. What should you compress first?

Value risk — the usual largest unknown, and the one a date will not resolve.

Key takeaways

  • The four risks are value, usability, feasibility and viability.
  • Name the biggest risk on this bet, then spend days — not sprints — reducing it.
  • Engineering owns feasibility but must engage the other three, or the team builds the wrong thing well.

Further learning

Marty Cagan's SVPG articles are the free backbone of this framing — discovery, empowered teams and strategy without ceremony.

SVPG articles (Marty Cagan)A partnership dedicated to teaching best practices to product teams and product leadersSilicon Valley Product Group

Next: how PM, design and engineering share those risks in the product trio.