The Four Big Risks
Before building, address four risks: value (will they use or buy it), usability (can they work it out), feasibility (can we build it) and business viability (does it work for the business).
“Tackle the big risks early – especially value risk and business risk”
To an executive
Products fail because nobody wants them, nobody can use them, they cannot be built, or they do not work for the business. Check all four before paying to build.
To an engineer
Feasibility is your risk to own, and it belongs in discovery, not after the spec. Prototype the hard parts early so the solution can change while it is still cheap.
The idea
Marty Cagan, of the Silicon Valley Product Group, argues that strong product teams tackle four big risks before they build, in discovery, rather than finding out after release. In his 2017 article "The Four Big Risks" he names them:
- Value risk: will customers buy it, or will users choose to use it?
- Usability risk: can users figure out how to use it?
- Feasibility risk: can our engineers build what we need with the time, skills and technology we have?
- Business viability risk: does the solution work for the various parts of our business?
Cagan assigns ownership: the product manager is accountable for value and viability, the product designer for usability, and the lead engineer for feasibility. The team works on all four together, using prototypes and quick tests rather than specifications, so that ideas are shaped by what is learned.
Why it works
Each risk kills products differently. A product can be valuable but unusable, or loved but impossible to run at a profit. Naming all four stops a team from proving one and assuming the rest.
Early answers are cheap. A feasibility spike or a usability test in week two costs days; finding the same problem after launch costs a rewrite.
Feasibility shapes the solution. When engineers and architects join discovery, they often propose a different, cheaper way to deliver the same value, something that never happens if they only receive a finished spec. This is where architects matter most.
Where it applies
- Discovery and early design, where an architect's feasibility input can still change the idea.
- Design reviews, checking that all four risks were addressed, not only the technical one.
- Vendor and platform choices, where feasibility includes integration, data and operations, and viability includes licensing, compliance and cost to run.
- Enterprise investment decisions, asking for evidence on each risk before large funding.
How to apply
- Name the riskiest assumption for each of the four. Some will be trivial; say so and move on.
- Bring feasibility in early. Ask the lead engineer or architect to spike the hard parts: new technology, scale, latency, data access, integration with legacy.
- Test value and usability with prototypes, not production code, and with real users.
- Walk viability through the business. Check with legal, security, finance, operations, sales and support, whoever could block or bear the cost.
- Decide with evidence. Proceed, change the solution or stop, and record which risk drove the decision.
Example scenario
A bank's product team proposed real-time spending insights in its mobile app. Customer tests showed strong interest, and the design prototype tested well. The plan went to delivery with the feasibility question reduced to an estimate.
At the architecture review the solution architect asked about all four risks. Feasibility was the gap: card transactions reached the core system in nightly batches, so "real-time" meant a new event feed from the card processor. A two-week spike showed this was possible but needed a contract change, which raised viability questions for procurement and data protection. The team narrowed the first release to insights updated within the hour from an existing feed, kept the full real-time version on the roadmap, and avoided a six-month dependency nobody had priced.
Questions to ask
- Which of the four risks is highest for this idea, and what have we done to reduce it before building?
- Has an engineer or architect looked at feasibility early enough to change the solution, not just estimate it?
- Who in the business, such as legal, finance, security or operations, could stop this, and have they seen it?
When not to use it
- Small, reversible changes, where shipping and watching is cheaper than a structured risk review.
- Mandated work, where value and viability are decided by regulation and only usability and feasibility remain open.
How it misleads you
The four risks can become a checklist ticked off in a meeting rather than evidence gathered. Strict ownership can also split the team: the architect cares only about feasibility while value goes untested. Cagan's point is that the whole team works on all four together, early, using prototypes rather than documents.
Further reading
Last reviewed · Suggest an improvement