SVPG's Four Product Risks: Value, Usability, Feasibility & Viability (Marty Cagan)

This is one of RoadmapOne ’s articles on Objective Tagging methodologies .

Marty Cagan’s four big product risks are the four categories of uncertainty every product team must address before committing to build: Value — will customers buy it or users choose to use it; Usability — can users figure out how to use it; Feasibility — can engineers build it with the available time, skills, and tech; and Business Viability — does it work for legal, finance, sales, marketing, and brand. Discovery exists to kill all four before delivery starts.

Marty Cagan’s Silicon Valley Product Group (SVPG) hammered home a brutal truth: most product ideas fail, and they fail for surprisingly predictable reasons. Dissecting anecdotes from Netscape to Netflix, Cagan distilled four product risks every team must crush before launch:

1. Value: Will anyone buy or choose to use it?
2. Usability: Can users figure out how?
3. Feasibility: Can engineering build it with acceptable resources?
4. Business Viability: Does it fit legal, financial, and brand constraints?

By tagging each roadmap item with its primary risk addressed, teams spotlight blind spots, allocate discovery work intentionally, and narrate trade-offs to execs without falling into technical detail quicksand.

This connects directly to how teams set OKRs . A key result is a hypothesis about how to achieve an objective—and Cagan’s four risks are the categories where that hypothesis can be wrong. Tagging your OKRs by primary product risk forces discovery effort to land where uncertainty is highest, instead of defaulting to feasibility work because that’s what engineering teams find comfortable. A “Value” risk on a key result demands customer interviews; a “Feasibility” risk demands a technical spike. The tag tells you which discovery activity actually de-risks the commitment.

Sign up (free) to tag objectives by product risk

Why Traditional Backlogs Hide Risk

Backlogs list work to be done, not uncertainty to be killed. A giant “Payments Refactor” ticket reads the same whether it’s a crisp sprint of Kotlin refactoring or a month-long compliance maze. SVPG tagging surfaces the uncertainty delta so leadership can price it.

Implementing Risk Tags

Step 1 – Create a Tag Group

Labelled “SVPG Risk”, with the four risk types. RoadmapOne ships with a default tag category for these risks.

Step 2 – Assign During Discovery

Every product opportunity canvas or PRD must name the dominant unanswered risk. If multiple risks loom, split the epic. Don’t forget that RoadmapOne enables visibility of Discovery activities in your roadmap —risk tags make discovery focus explicit.

Practical Examples

Notice how artefacts, not code, prove the risk resolved—aligning perfectly with dual-track agile.

Case Study: HRTech Vendor “TalentTree”

Problem: Six months building a candidate-ranking AI, only to discover HR managers distrusted the black box (Value + Business Viability risks).

Fix: Instituted SVPG tagging. A subsequent “Explainable AI dashboard” epic carried a Value risk tag; discovery interviews validated need in three weeks before code. Result: 40 % reduction in wasted sprint capacity, credibility restored with the board.

Linking Tags to Funding

Rather than block budgeting by project, allocate a risk-mitigation fund. Example: 15 % of quarterly dev hours reserved for Feasibility spikes tagged “SVPG: Feasibility.” Finance sees a direct hedge against schedule slip. This works best when integrated with capacity-based planning that shows exactly where that 15% sits.

Anti-Patterns

• Retro-Tagging for Optics – Slapping tags post-development erases learning history. Tag at ideation.
• Ignoring Business Viability – Start-ups postpone legal review until a cease-and-desist arrives. Make it a first-class tag.

Track risk reduction across your roadmap—free sign-up

Takeaways

• Risk tagging turns discovery from a fuzzy luxury into a quantifiable line item.
• Boards gain confidence because uncertainty is surfaced early, mitigated visibly, and costed explicitly.
• By automating the tag workflow in RoadmapOne, PMs replace hand-waving with a crisp “Here’s how we burned down 70 % Value risk this quarter.”

Frequently asked questions

What are the 4 product risks of SVPG?

Marty Cagan and Silicon Valley Product Group identify four product risks every team must address before a product will succeed: Value risk (will customers buy it or users choose to use it?), Usability risk (can users figure out how to use it?), Feasibility risk (can engineering build it with the time, skills, and technology available?), and Business Viability risk (does it work for the broader business — legal, sales, finance, marketing, brand?).

What are the four risks?

In product management, the four risks are Marty Cagan’s framework for the four kinds of uncertainty every product idea must survive: Value (will anyone want it?), Usability (can users figure out how to use it?), Feasibility (can engineers build it?), and Business Viability (does the rest of the business — legal, finance, sales, marketing, brand — support it?). When people ask about “the four risks” in a roadmap or discovery context, this is almost always what they mean.

What are the big 4 product risks?

The “big four” product risks in Cagan’s SVPG taxonomy are Value, Usability, Feasibility, and Business Viability. They’re called “big” because they are the four risk categories that actually kill products — not the micro-risks of individual features. De-risking an idea means deliberately attacking all four before you commit engineering capacity, usually through a mix of prototyping, customer interviews, technical spikes, and stakeholder review.

What are the types of risk in product development?

In Marty Cagan’s framework, the four types of risk in product development are: Value risk (nobody will buy or use it), Usability risk (the product is too confusing or slow to use), Feasibility risk (engineering can’t build it with the tools, skills, or time available), and Business Viability risk (even if it ships and works, legal, finance, sales, marketing, or brand constraints make it a non-starter). Product discovery exists to address all four before committing delivery capacity.

Which of Marty Cagan’s four big risks should product teams aim to eliminate with discovery?

Product discovery should de-risk all four of Cagan’s risks — Value, Usability, Feasibility, and Business Viability — not just one. In practice, most teams over-index on Feasibility (because engineers are comfortable with technical spikes) and neglect Value and Business Viability. The discipline is to pick the dominant risk for each objective, use the right discovery technique (customer interviews for Value, prototypes for Usability, spikes for Feasibility, stakeholder review for Business Viability), and only commit engineering time once the dominant risk is down to an acceptable level.

What is Marty Cagan’s theory of product risk?

Cagan’s theory is that most product failures come from one of four knowable, addressable risks — Value, Usability, Feasibility, and Business Viability — and that a team’s job is to de-risk each one before they build. Delivery is trivial compared to getting the product right; most organisations invert that, treating building as the hard part and discovery as overhead. The SVPG product operating model reframes discovery as the job and delivery as the output.

What is an example of a usability risk?

A classic usability risk is shipping a feature that users can technically use but never figure out — buried navigation, opaque error messages, confusing labels, or workflows that don’t match how users think about the task. A common example is a self-service migration wizard that requires the user to understand the data model behind it: engineering signs off because every step works in isolation, but real users abandon mid-flow. The discovery technique that catches usability risk is moderated prototype testing — putting a clickable Figma in front of five real users and watching where they get stuck. If three of five fail the same step, that’s the usability risk evidence you need before writing production code.

Approx. 1 520 words

For more on Objective Tagging methodologies, see our comprehensive guide .