Naming and Operationalizing SVPG’s Four Product Risk Areas

Status: Source research report. See risk-areas-model.md for the selected model. This report is retained for its comparisons, sources, and alternative terminology.

Executive summary#

Across product management, design, Lean Startup, and innovation consulting, there is broad agreement on the substance behind SVPG’s four areas: teams need evidence that a solution creates customer value, can be used successfully, can be built, and makes sense for the organization. There is much less agreement on what those areas should be called. SVPG and Marty Cagan explicitly call them a product risk taxonomy: value risk, usability risk, feasibility risk, and business viability risk. IDEO, Nielsen Norman Group, and McKinsey generally use desirability, feasibility, and viability as lenses or conditions, with usability folded into desirability. Teresa Torres moves one level down and works with assumptions in five categories: desirability, viability, feasibility, usability, and ethical. Roman Pichler uses product success factors and strategy risks: desirability, feasibility, viability, and ethicality. Lean Startup centers on leap-of-faith assumptions, hypotheses, experiments, and validated learning, without maintaining a four-part taxonomy. ¹²³⁴⁵

The recommendation is to call SVPG’s four headings Product Risk Dimensions: Value, Usability, Feasibility, Viability. This keeps compatibility with SVPG while making the abstraction level explicit. Under each dimension, write specific risks, identify the assumptions creating those risks, run tests or experiments, and record evidence. This resolves the linguistic problem with statements such as “Value is a risk”: value is better treated as the dimension in which concrete risks exist. This interpretation is also consistent with ISO 31000’s more formal definition of risk as the “effect of uncertainty on objectives.” ⁶¹

For a discovery board, use:

Product Risk Dimensions Value · Usability · Feasibility · Viability

Risk: What uncertain failure could prevent the outcome? Assumption: What must be true for the solution to succeed? Test: What is the cheapest credible way to challenge that assumption? Evidence: What was observed, and what decision follows?

This combines what is strongest in SVPG and Teresa Torres: SVPG provides a compact coverage taxonomy, while Torres provides a more precise unit of testing. Torres explicitly argues that a broad label such as viability risk does not by itself tell a team what to test; enumerating the underlying assumptions does. ²⁷

A second recommendation is to consider Ethics/Safety as a fifth explicit dimension when potential harm deserves independent attention. Torres uses ethical assumptions, Pichler uses ethicality as one of four success factors, and practitioners have extended Cagan’s model to five product risks by adding ethics. SVPG acknowledges ethics but generally places it within business viability, while also recognizing the argument for breaking it out when teams might otherwise neglect it. ⁸²³⁹

How practitioners name and operationalize the areas#

The main difference between the frameworks is not whether customer, user, technical, and business questions matter. It is what object the framework asks the team to manage: SVPG manages risk categories; Torres manages assumptions; Lean Startup manages hypotheses and learning; IDEO and consultancies use evaluation lenses; Google Design Sprints organize around assumptions and questions; Pragmatic Institute organizes around product-management activities. ^12541011

Two patterns dominate this comparison.

First, SVPG is one of the few prominent frameworks that deliberately keeps Value and Usability separate. IDEO, NN/g, McKinsey and similar design-oriented frameworks usually put both under Desirability. Cagan says this separation became important to him particularly in B2B products, where the person deciding whether to buy a product and the person required to use it can be different people with different criteria. ¹

Second, several practitioners have shifted attention from naming broad categories to identifying the specific belief that could be wrong. Torres is the clearest example: an assumption is a belief that must hold for an idea to succeed, and the team should surface many such assumptions, rank them by risk, and test the important ones. Google Design Sprints similarly decomposes assumptions and converts them into sprint questions, while Lean Startup expresses uncertain beliefs as measurable hypotheses. ²¹⁰⁵

Alternative taxonomies and why they differ#

Desirability, feasibility, viability#

The closest widespread alternative to SVPG is:

Desirability · Feasibility · Viability

IDEO explicitly frames design thinking around what is desirable for people, feasible with technology, and viable for organizations. NN/g uses essentially the same DVF model, and McKinsey uses customer desirability, technical feasibility, and business viability in innovation work. ⁴¹⁸²²

The mapping is approximately:

This consolidation is intentional. NN/g, for example, defines desirability in terms of user value and says a desirable product must be useful and usable. SVPG’s explanation of the competing taxonomies likewise says IDEO’s desirability combines customer value and usability. ¹⁸¹

The three-lens model has a clear advantage: it is compact and works well as an innovation or concept-evaluation model. The tradeoff is loss of diagnostic precision. A concept can solve a valuable problem while still having an unusable workflow. That distinction becomes especially useful in B2B, internal tools and other settings where buyers, administrators, approvers and end users are different people. This latter argument is also Cagan’s stated rationale for retaining separate Value and Usability categories. ¹

Five assumption categories#

Teresa Torres’ taxonomy is structurally close to SVPG but changes both the labels and the object being classified:

Desirability assumptions · Viability assumptions · Feasibility assumptions · Usability assumptions · Ethical assumptions

Here, an item on the team’s board is not normally “the viability risk.” The team asks what specifically has to be true about economics, behavior, technology, workflow or harm for an idea to work. ²

This distinction is operationally important. Torres explicitly argues that describing a solution as having “viability risk” leaves the test ambiguous; enumerating viability assumptions gives the team something concrete to evaluate. Her workflow uses story maps to expose desirability, usability and feasibility assumptions, traces an Opportunity Solution Tree to find viability assumptions, intentionally explores potential harm, and then prioritizes assumptions for testing. ²⁷

The distinction can be summarized this way:

SVPG: “Has every important kind of product risk been covered?”

Torres: “What exactly is being assumed, and which assumption should be tested next?”

Those are complementary questions, not competing ones. This is an analytical synthesis of the two methods. ¹²

Desirability, feasibility, viability, ethicality#

Roman Pichler’s framework is:

Desirability · Feasibility · Viability · Ethicality

He calls them product success factors, while in strategy-discovery work he talks about strategy risks within the same four areas. His validation loop starts with the most important uncertainty, applies an appropriate research method such as interviews, observation, a throwaway prototype or business-model analysis, uses the resulting evidence to change or retain the strategy, and repeats until the remaining significant risks have been addressed. ³¹⁴

Its conceptual difference from SVPG is revealing:

The choice reflects the level at which the framework is being used. Pichler is often validating product strategy; Cagan’s taxonomy is heavily used during solution discovery. At a strategy level, ethics may deserve a separate gate while detailed interaction usability can sit lower in the decomposition. ³¹⁴¹

Value and growth hypotheses#

Lean Startup takes a different route. Its core categories are not four product properties. It asks teams to identify risky assumptions, express important ones as hypotheses, build the smallest useful experiment or MVP, measure real behavior, and generate validated learning. Its named high-level hypotheses are particularly value hypotheses and growth hypotheses. ⁵

That means there is no clean one-to-one mapping:

• Value is directly represented by the value hypothesis.
• Viability is partly covered through value, growth, adoption and business-model economics.
• Usability can be a hypothesis that affects customer behavior, but it is not a canonical top-level Lean Startup category.
• Feasibility can likewise be tested through experiments or prototypes, but core Lean Startup terminology does not elevate it to a named sibling of value and growth. ¹⁶⁵

Lean Startup is therefore better understood as a learning architecture than as a completeness checklist.

Corporate innovation variants#

BCG X shows why taxonomies change with context. Its “Four Lenses for Validation” are Desirability, Viability, Feasibility, and Strategic Fit. The extra question is whether a venture has synergies or advantages within the sponsoring company. ²⁴

That suggests a useful general principle: the fourth or fifth category often exposes the failure mode that a particular organization is most prone to overlook. SVPG separated business viability because customer value could crowd it out. Torres and Pichler expose ethics because harm can disappear inside an overly broad business category. BCG exposes strategic fit because corporate venture ideas can look attractive in isolation while making little sense for the parent company. This is an inference from how the respective authors explain their taxonomies. ¹²³²⁴

A compact comparison makes the pattern clearer:

The practical lesson is that there are two independent design choices in any taxonomy:

1. Coverage: Which classes of failure deserve an explicit category?
2. Unit of work: Are the managed objects lenses, risks, assumptions, hypotheses, questions, or experiments?

Much of the apparent disagreement between practitioners disappears once those two choices are separated. ¹²⁵²⁴

Recommended naming conventions#

Recommended default: Product Risk Dimensions#

The recommended default for most product teams is:

Product Risk Dimensions Value · Usability · Feasibility · Viability

This is more precise than simply naming a section “Four Risks.”

The reason is semantic as well as practical. ISO 31000 defines risk as the effect of uncertainty on objectives. Under that meaning, “Value” by itself is a subject or dimension; even “value risk” is still a category label. A concrete risk would say what might happen and why the product objective would suffer. SVPG itself calls its model a risk taxonomy, meaning a classification system for types of risk, which supports treating the four labels as categories or dimensions rather than four individual risk records. ⁶¹

For example:

Dimension: Value Risk: Target finance teams may see too little improvement over their spreadsheet workflow to switch, preventing adoption.

The second sentence is a risk that can be investigated. “Value” indicates where to look.

Pros: faithful to SVPG; preserves the useful Value/Usability distinction; works equally well for B2B and B2C; separates taxonomy from concrete risk statements; gives design, engineering and business teams a shared coverage checklist. ¹

Cons: the word risk can make discovery sound like defensive risk management; people may still write vague entries such as “high value risk” instead of spelling out what could fail.

Good alternative for discovery workshops: Product Uncertainties#

A softer formulation is:

Key Product Uncertainties Value · Usability · Feasibility · Viability

This works particularly well in early discovery, where the goal is to expose what the team does not yet know and gather evidence. SVPG’s own current “build to learn” language and Pichler’s risk-driven strategy discovery both treat uncertainty as something to resolve before larger commitments are made. ¹³¹⁴

Its weakness is precision. “Uncertainty” indicates that knowledge is incomplete; it does not state what objective is threatened or what consequence follows. That makes it a good workshop heading and a weaker risk-register item. This distinction follows the ISO definition of risk as the effect that uncertainty has on objectives. ⁶

A useful phrasing is:

“What are the biggest uncertainties across Value, Usability, Feasibility and Viability?”

Then convert the important answers into specific risk statements.

Best for an experiment backlog: Assumption Categories#

For a team running frequent discovery tests, Torres’ terminology is useful:

Assumption Categories Desirability/Value · Usability · Feasibility · Viability · Ethics, where applicable

An assumption is naturally testable because it can be written as a proposition that needs to hold. Torres defines assumptions in essentially those terms and recommends identifying, prioritizing and testing them rather than evaluating a whole idea as one indivisible object. ²⁷

For example:

Risk: Buyers may not switch because the existing process is good enough. Assumption: The target buyer experiences the problem frequently enough that eliminating it changes purchase behavior.

The risk and assumption are related but are not the same sentence.

The disadvantage of using Assumptions as the name for the top level is that Value, Usability, Feasibility and Viability are not themselves assumptions. A product can contain dozens of assumptions in every category; Torres’ August 2026 material continues to emphasize generating many underlying assumptions before identifying the risky ones. ²⁶

Avoid:

❌ “The four assumptions are Value, Usability, Feasibility and Viability.”

and use:

✓ “Assumptions are evaluated across four product risk dimensions.”

A terminology stack that works across artifacts#

The cleanest vocabulary is:

This combines SVPG’s risk coverage, Torres’ assumption-testing discipline, Lean Startup’s hypothesis/experiment logic, and Google Sprint’s progression from assumptions to questions to prototype validation. ¹²⁵¹⁰

The hierarchy can be represented as:

  flowchart LR
    D["Product Risk Dimension<br/>Value · Usability · Feasibility · Viability"]
    R["Specific Risk<br/>What may prevent the outcome?"]
    A["Underlying Assumption<br/>What has to be true?"]
    E["Evidence<br/>What was observed?"]

    D -->|"classifies"| R
    R -->|"depends on / is driven by"| A
    A -->|"test to obtain"| E

The arrows describe a working decomposition rather than a formal causal ontology. In practice, teams may discover an assumption first and then articulate the risk it creates. What matters is maintaining the distinctions among classification, uncertain outcome, belief, and evidence. Torres similarly says that precise categorization is less important than surfacing and evaluating the assumptions that create risk. ²

For a one-line team standard, use:

Product Risk Dimensions–Value, Usability, Feasibility, and Viability–are assessed by identifying specific risks, surfacing the assumptions behind them, and collecting evidence through targeted tests.

When to add Ethics/Safety#

SVPG places ethical, compliance and related concerns largely within business viability. Cagan has acknowledged the argument for separating ethical risk when it otherwise receives insufficient attention. Torres makes Ethical assumptions a fifth category, while Pichler makes Ethicality a first-class product-success factor. ¹⁸²³

For a team where potential harm, privacy, fairness, safety or societal effects are material, the recommended form is:

Product Risk Dimensions: Value · Usability · Feasibility · Viability · Ethics/Safety

The advantage of a fifth category is attention: teams are forced to ask the question explicitly. The cost is another category and some overlap with viability, security, compliance and usability. SVPG’s 2023 discussion correctly identifies this as a tradeoff between completeness and a taxonomy people can remember and use. ¹

From dimensions to testable evidence#

The critical move is to stop at neither:

“There is value risk.”

nor:

“Value needs to be validated.”

Neither statement identifies what could be false. Torres’ assumption-testing approach and Lean Startup’s measurable-hypothesis approach both push the team toward propositions that can be challenged by evidence. SVPG similarly says teams should understand the risks and then select techniques for quickly testing ideas against them. ²⁵¹

A practical record can use this template:

Dimension: Value / Usability / Feasibility / Viability Objective affected: What outcome is being pursued? Specific risk: What might be true that prevents that outcome? Underlying assumption: What must be true for the proposed solution to work? Current evidence: What is already known, and how strong is that evidence? Test: What is the cheapest credible test that distinguishes the competing possibilities? Decision rule: Before seeing results, what evidence would change the decision? Result: What happened? Decision: Continue, modify, investigate further, or stop.

Defining success criteria before a test is consistent with Torres’ approach to reducing confirmation bias; Lean Startup likewise favors hypotheses with observable, preferably measurable expected behavior. ⁷⁵

Here are four illustrative examples. The product, thresholds and results are hypothetical.

A B2B example shows why keeping Value and Usability separate is often useful. Suppose an executive buyer sees a clear financial return and willingly purchases a workflow product. The end users may still find the workflow difficult enough that adoption collapses. A three-lens model can describe the whole situation as a desirability problem; SVPG’s four-dimensional model produces two clearer hypotheses: the buyer value hypothesis passed while the user usability hypothesis failed. Cagan explicitly cites buyer/user separation as the reason he considers the four-part taxonomy more useful for many business products. ¹

A discovery process built around these records can be visualized as a repeating matrix rather than a phase gate:

No framework prescribes that these columns be resolved sequentially. SVPG emphasizes addressing important risks early; Torres prioritizes the riskiest assumptions; Pichler says to select the largest strategy uncertainty and iterate; design thinking itself is explicitly iterative. The practical implication is to order tests by risk and cost of being wrong, rather than mechanically doing Value first, then Usability, then Feasibility, then Viability. ¹⁷¹⁴⁴

Overall recommendation#

The research supports using risk as SVPG uses it, but with one important refinement in team language.

“The Four Product Risks” is legitimate SVPG terminology. Marty Cagan deliberately calls the model a product risk taxonomy, and Productboard and other practitioners have adopted those exact labels. ¹²⁵

For artifacts, however, “Product Risk Dimensions” is clearer:

Product Risk Dimensions#

Value – Will the customer/user choose the solution? Usability – Can the intended user successfully use it? Feasibility – Can the team deliver it within the relevant technical and operational constraints? Viability – Can the business support, sell, operate and sustain it?

Then reserve risk for statements such as:

“Target administrators may abandon setup because connecting their data requires credentials they do not control, preventing activation.”

And reserve assumption for:

“The target administrator has access to the credentials required during setup.”

That distinction gives every word a clear job:

Dimension
   ↓
Specific risk
   ↓
Underlying assumption(s)
   ↓
Targeted test
   ↓
Evidence
   ↓
Decision

The taxonomy answers where uncertainty may exist. The risk explains what might go wrong and what objective is affected. The assumption identifies what the team currently believes must be true. The test generates evidence. That combination is more operationally precise than using “risk,” “uncertainty,” and “assumption” interchangeably, and it is consistent with the strongest parts of SVPG, Torres, Lean Startup, Google Design Sprints, and formal risk terminology. ¹²⁵¹⁰⁶

For most software product teams, the preferred team wording is therefore:

“For each solution, identify the significant risks across four Product Risk Dimensions–Value, Usability, Feasibility and Viability. State each risk concretely, expose the assumptions behind it, and gather enough evidence to make the next decision.”

For an experiment board, use Assumptions as the individual items. For an executive or design workshop, Desirability-Feasibility-Viability can be simpler when the distinction between buyer value and user usability is not important. For B2B products, internal products, or products with distinct buyers and users, keep SVPG’s four dimensions. Where potential harm warrants independent scrutiny, add Ethics/Safety explicitly instead of trusting it to remain visible inside Viability. ¹²³

References#