Four Big Risks Assessment
Every product idea faces the same four risks. Rate where your evidence stands on each — and find the one most likely to sink it, plus what to do about it first.
Stress-test your idea
Marty Cagan's four big risks are the questions a product has to survive before it's worth building. Rate your current evidence on each — honestly — and the tool flags the biggest gap and the cheapest way to close it.
The four questions a product must survive
Teams love to debate solutions before they've checked whether the idea is worth building at all. The four risks force the real questions to the surface — and the order to tackle them: usually value first, because it's the one that kills the most products.
Value: will people choose it? · Usability: can they use it? · Feasibility: can we build it? · Viability: does it work for the business?
The honest caveat: this is a self-assessment — it's only as good as how honestly you rate your evidence. "Strong validation" should mean real data from real users, not a confident hunch.
What each risk actually asks — and what counts as evidence
Rating yourself is only useful if you and your team mean the same thing by "we have evidence." Here is the bar for each risk, what weak evidence looks like in practice, and the cheapest way to close the gap.
Value risk — will people choose it? The question is not whether the idea is good; it is whether people will pick it over what they do today, including doing nothing. Real evidence looks like observed behaviour: users switching, paying, coming back unprompted, or abandoning a workaround they had built themselves. Weak evidence looks like stakeholder conviction, a competitor shipping something similar, or users saying they would "definitely use that." The cheapest test is usually a fake-door or landing-page test, or putting a rough prototype in front of eight target users and watching what they do rather than asking what they think.
Usability risk — can they figure it out? The bar is whether someone in your target segment can complete the core task unaided, on their first try, without you in the room explaining. Real evidence is a recorded session where five users attempt the task and you count completions and hesitations. Weak evidence is "the design looks clean" or internal demos where everyone already knows how it works. The cheapest test is a usability test on a clickable prototype — you do not need working code, and five users surface the majority of serious problems.
Feasibility risk — can we actually build it? This covers technology, data, skills, dependencies and time. Real evidence is an engineer who has spent a day on a spike and can now describe the approach and the unknowns. Weak evidence is "should be fine" from someone who has not looked, or an estimate given in a planning meeting under time pressure. The cheapest test is a timeboxed technical spike before the work is committed, not after.
Viability risk — does it work for the rest of the business? This is the one teams skip. It covers sales, marketing, finance, legal, privacy, security, support and brand. Real evidence is that each affected function has seen the idea and said what it would need. Weak evidence is nobody having asked, which is not the same as nobody objecting. The cheapest test is a thirty-minute conversation with each function while the idea is still cheap to change.
Five ways this assessment gets used badly
Rating optimistically to protect a decision already made. If the idea is already on the roadmap and the assessment is run to justify it, every score drifts upward. The tool has no way to catch this — only you do. Run it before the commitment, not after.
Treating the four risks as sequential gates. They are not a stage-gate process. You address them in parallel, weighted by which one would kill the idea fastest. Value usually deserves the most attention because it kills the most products, but a feature with an obvious value case and a serious privacy problem should start with viability.
Confusing "we discussed it" with evidence. A meeting where the team agreed something is likely is not validation. The distinction that matters is between what people said and what people did.
Rating alone. The most useful version of this is each function rating independently and then comparing. Where engineering and product disagree sharply about feasibility, that gap is the finding — more useful than any average.
Running it once. Evidence changes as you learn. A risk rated weak in week one should look different after discovery. If it never moves, the discovery work is not answering the question you set out to answer.
Common questions
When should I run this? Before an idea is committed to a roadmap or a sprint — when changing course is still cheap. Running it on work already in progress still surfaces useful gaps, but the response is usually damage control rather than a decision.
Who should rate the risks? Ideally the product trio: product, design and engineering, plus whoever owns the commercial side. Each rates independently first. Averaging away disagreement destroys the most valuable signal the exercise produces.
What does a low score mean — that we should stop? No. It means you know where your evidence is thinnest, which tells you what discovery work to do next. A weak rating on value is not a verdict on the idea; it is an instruction to go find out.
Where does this framework come from? The four big risks are Marty Cagan's framing, set out in Inspired and used widely in product discovery practice. The full write-up, with worked examples, is in the Four Big Risks guide.
Does anything I type here get stored? No. Everything runs in your browser and nothing is sent anywhere.
The full framework, with examples.
The Four Big Risks guide breaks down each risk and how to de-risk it — one of 156 frameworks on PM Mapped.
Read the guide → Browse all 156 →