The Four Product Risks
Value, usability, feasibility, viability — and the PM owns the first and the last
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 90%
Any solution a team considers building carries four distinct risks: will people buy or choose it (value), can they use it (usability), can we build it (feasibility), and does it work for our business (viability). The framework's teeth are in the ownership split — the product manager is accountable for value and viability, the designer for usability, the engineer for feasibility — and in Idiodi's insistence that value is the most important risk and the one teams most reliably skip.
Origin
The four-risk taxonomy is Silicon Valley Product Group's, popularised by Marty Cagan in INSPIRED and EMPOWERED. Idiodi, an SVPG partner, adds the argument that value risk is the systematically overlooked one and that roadmap-driven operating models make it impossible to address at all.
Core principles
- 01Product work is a team sport: three disciplines, four risks, one solution.
- 02Value risk is the most important and the most overlooked.
- 03If a team is handed a roadmap of features to deliver, value has been assumed rather than answered — and you don't actually need a product manager.
- 04The PM is treated as the quarterback not because they're smarter, but because they answer the question of whether we should be working on this at all.
- 05Nobody wants to work on something nobody wanted in the first place.
How to run it
- 1
Name the problem, not the feature
Before assessing risk, restate the work as a problem to be solved for a customer, in a way that also works for the business. A feature request is not a problem statement.
- 2
Answer value risk first — will they buy, choose, or use it?
Establish evidence that customers will actually pay for, select, and use the solution. Behavioural evidence only: what people say differs from what they do. This is the PM's primary job.
Pro tip Idiodi's answer to value risk is the reference-customer technique: solve it for real people until they'll recommend it.
Watch out A high usability-test score is not value evidence. Being able to use a product says nothing about whether anyone will buy or choose it.
- 3
Answer viability risk — will our business support it?
Check the solution against legal, finance, sales, marketing, compliance and business-model constraints. Also the PM's job, and best done early by involving those functions during discovery rather than at launch.
Pro tip Bringing marketing, sales, legal and finance into the reference-customer work retires viability risk early and cheaply.
- 4
Delegate usability to design and feasibility to engineering
Can customers figure out how to use it (designer), and can we build it with the skills and time we have (engineer). The PM does not own these but must ensure they are answered in parallel, not sequentially.
Pro tip When the designer and engineer are in the room while the problem is being defined, they solve usability and feasibility without a requirements document.
Watch out Handing an engineer a spec after value has been assumed produces a working build of something nobody wanted.
In the wild
Idiodi describes the common bad pattern of a company saying 'we ran a test with 300 users and 90% loved it', then shipping. That test only addressed usability. He pushes back: being able to use it doesn't mean they'll buy it, choose it, or actually use it.
→ The team ships a usable feature that generates no revenue, engagement or loyalty, and blames the product manager — correctly, because value was their risk to answer.
When teams are given roadmaps of projects and features to build and deliver, the value question is pre-answered by whoever wrote the roadmap. The PM cannot ask 'should we build this, is there a better option, will people buy it'.
→ Idiodi's blunt conclusion: in that operating model you don't actually need a product manager, which explains much of the industry's dislike of the role.
Common mistakes
Assuming value because a leader asked for it
If the boss told you to build it, value gets silently assumed. That assumption is the single largest source of wasted product effort, and it disqualifies the PM role from having any purpose.
Sequencing the risks
Answering feasibility first (can we build it?) and value last inverts the cost curve. The four risks are meant to be attacked in parallel by the trio during discovery.
Treating a checked roadmap box as an outcome
Shipping the item is not solving the problem. The outcome is the 'certificate of appreciation' — revenue, engagement, loyalty, a reference — that customers give back.
Is it for you?
Best for
Product managers and product leaders auditing why a team keeps shipping features that don't move outcomes, and executives deciding whether their operating model even makes a PM role meaningful.
Not ideal for
Pure delivery or platform teams with a mandated scope, where value and viability genuinely are decided elsewhere.
From the transcript
“I kind of call out the product manager competency is really to try to drive the the first and the last one which is value…”
“value value is probably it is the most important and the most overlooked”
“just because somebody can use your product doesn't mean that they will buy it just because they can use it doesn't mean they will choose…”
“teams are often given road maps of projects and features to go build and deliver if that's the case you actually really don't need a…”
“nobody wants to work on something nobody wented in the first place and your job is to ensure that we are working on something people…”
From the episode
The essence of product management
Christian Idiodi (SVPG)