SVPG’s Solution Risk Dimensions and Teresa Torres’s Continuous Discovery Model

Status: Source research report. See risk-areas-model.md for the selected model and risk-areas-reassembled.md for the supporting synthesis.

Executive summary#

SVPG’s Value, Usability, Feasibility, and Viability and Teresa Torres’s Desirability, Usability, Feasibility, and Viability assumptions are best understood as two views of almost the same solution-level concerns. Torres says this explicitly: conceptually, her assumption types and Marty Cagan’s four risks are addressing the same ideas; she prefers assumptions in practice because a concrete assumption tells a team what it can test. ¹²

The more important difference is elsewhere in their models:

SVPG provides a taxonomy for asking, “How could this proposed solution fail?”

Torres provides a structure for asking, “What outcome is being pursued, which customer opportunity should be addressed, which solutions could address it, what must be true for those solutions to work, and what evidence should be collected?” Her Opportunity Solution Tree connects a desired outcome to an opportunity space, solution space, and assumption tests. ³⁴

So these models are mostly complementary, not competing.

The recommended synthesis is:

Outcome -> Opportunities -> Candidate solutions -> Solution risk dimensions -> Concrete assumptions -> Evidence / assumption tests -> Decision -> Production outcome

For the solution risk dimensions, use:

Value, Usability, Feasibility, Viability, and Ethics

Keep Value rather than Torres’s Desirability for work that is heavily B2B, because “will the customer buy or the user choose to use this?” is clearer there. Keep Ethics explicit because Torres treats it as a fifth assumption category, and Cagan has separately argued that ethics can disappear inside the large viability bucket and therefore deserves explicit attention. ⁵¹⁶

Most importantly, do not make “Value risk: high” the atomic unit in discovery documentation. Make the atomic unit a concrete assumption:

Value assumption: Finance controllers will allow the system to auto-match invoices without reviewing every match.

Then record the risk associated with being wrong, the existing evidence, and the next evidence needed. This combines SVPG’s risk/consequence thinking with Torres’s assumption-testing practice. SVPG says risk assessment should consider both severity and consequence; Torres prioritizes assumptions that are critical to the idea and weakly supported by evidence. ⁷⁸

There are four substantive differences to be aware of:

^1910611

Source context and evolution#

The terminology evolved over time, which explains some apparent contradictions between articles.

This history matters because neither framework is a static four-box or five-box checklist. SVPG increasingly describes the four risks as a conceptual model for evaluating potential solutions, while Torres embeds nearly equivalent concerns inside a broader continuous decision system. ¹⁰¹⁶¹⁹

The examples below assume a cross-functional digital product team, using a B2B SaaS product as the concrete case. That makes the value/desirability distinction especially visible. The synthesis also applies to consumer and internal products, but SVPG explicitly notes that the value and usability bars can differ for internal products because users may have less choice and training may be acceptable. ²⁰

Concept mapping#

Consider a B2B product team building an AI-assisted invoice reconciliation system for finance teams.

The mapping is intentionally almost one-to-one. Torres herself says that her assumption categories and Cagan’s risk areas are conceptually addressing the same ideas. Her distinction is about granularity: “viability risk” does not specify what to investigate; a statement such as “SMS acquisition revenue will exceed SMS delivery cost” can be assessed and tested. ¹²²

That suggests a useful distinction:

SVPG dimensions classify the failure mode. Torres assumptions describe the proposition whose failure would cause it.

Where Opportunity Solution Trees fit#

There is no one-to-one SVPG risk corresponding to an opportunity. Torres defines opportunities as customer needs, pain points, and desires that, if addressed, could drive the product outcome; solutions sit below those opportunities, with assumption tests below solutions. ³⁴

For the invoice example:

This is why SVPG’s four boxes should not be added as a peer level to Outcome / Opportunity / Solution in an OST. They are a different axis. An OST describes the decision structure; risk dimensions classify the uncertainties inside candidate solutions.

Terminology differences#

The terms are related but should not be collapsed.

Risk and assumption should remain separate#

A useful team model is:

Assumption: what must be true. Uncertainty: how little is known about whether it is true. Risk: why being wrong is consequential. Evidence: what currently supports or contradicts it.

For example:

Assumption: Controllers will trust the system enough to permit automatic matches above 98% confidence. Evidence: 3 of 8 controllers enabled automation in a prototype pilot. Uncertainty: High; sample is small and all users came from design-partner accounts. Risk: High; if controllers continue manually reviewing every match, the solution cannot reduce reconciliation time enough to achieve the outcome.

That decomposition reflects SVPG’s emphasis on consequence and sufficient evidence, and Torres’s emphasis on critical assumptions with weak evidence. ⁷⁸

Scope differences#

The biggest conceptual difference between the two bodies of work is not the four versus five categories. It is how much discovery attention the product team gives to the problem/opportunity space.

Torres gives the opportunity space first-class status#

Torres describes discovery as:

desired outcome -> opportunity space -> solution space

The opportunity space contains customer needs, pain points, and desires; teams build it continuously from customer stories and use it to decide which customer opportunity to target before comparing candidate solutions. ³²⁶

She recommends framing opportunities from the customer’s point of view and provides a simple check: could a customer plausibly say it? For example, “reduce support tickets” is business language, while “I can’t figure out how to do X” expresses the customer problem. ¹⁸

She also treats the model as bidirectional and continuous. Learning about solutions can change the understanding of the opportunity; learning across opportunities can change the understanding of the outcome. Torres explicitly warns against treating outcome -> opportunity -> solution as sequential phases that must be completed once. ³¹

Current SVPG puts more weight on solution discovery#

SVPG’s April 2026 Build To Learn FAQ starts with a problem to solve and an outcome to achieve, but says product strategy normally selects the problem and product leaders normally own that choice. It argues that most build-to-learn effort should then go toward finding a solution that actually solves the problem and produces the outcome. ¹¹

This is consistent with Cagan’s earlier Discovery - Problem vs. Solution, where he argues that strong companies spend the majority of discovery effort on finding a valuable, usable, feasible, and viable solution. ³²

This is a genuine difference in emphasis:

Both levels should be preserved.

A product strategy or leader can define a broad strategic problem such as:

Reduce month-end close time for mid-market finance teams.

The product team can still build an opportunity space underneath it:

“I can’t tell which invoice mismatches actually need investigation.” “I repeatedly investigate the same supplier-specific differences.” “I’m afraid to automate matching because I need an audit trail.”

This gives leadership control over where the company plays while giving the team room to discover which customer needs inside that space are most promising.

Discovery practice differences#

The two approaches become especially complementary when comparing how they surface, prioritize, and test uncertainty.

Surfacing assumptions#

Torres is more prescriptive here, and her techniques fit naturally under SVPG’s categories.

Story mapping can expose what users must want, understand, do, and what the technology must support. Walking the lines of the OST exposes assumptions in the causal chain “solution addresses opportunity -> addressing opportunity moves outcome.” Pre-mortems expose failure modes the team has overlooked. ²

A useful workshop sequence is therefore:

Candidate solution -> scan Value / Usability / Feasibility / Viability / Ethics -> enumerate specific assumptions -> ask what failure would invalidate the solution.

Prioritizing assumptions#

SVPG and Torres use slightly different language but combine cleanly.

SVPG asks teams to consider the severity and consequence of being wrong and then choose the amount of evidence warranted. ⁷

Torres’s assumption mapping asks whether an assumption is critical to success and how much evidence already supports it. The assumptions that are both critical and weakly supported are the riskiest. ⁸

Record three fields:

Test assumptions with high criticality, high consequence, and weak evidence first.

Do not turn those fields into a pseudo-precise score unless ranking actually helps the decision. Both Cagan and Torres emphasize judgement and context over blindly applying a formula. Cagan explicitly argues discovery requires judgement, while Torres treats opportunity and assumption decisions as revisable as new evidence arrives. ⁷³⁶

Complementarities and conflicts#

Strong complementarity: dimensions versus testable propositions#

This is the cleanest synthesis.

SVPG:

“Remember to examine value, usability, feasibility, viability.”

Torres:

“Turn those concerns into the actual propositions on which the candidate solution depends.”

Torres herself says the concepts are essentially the same and that assumption wording makes them easier to test. ¹

So:

Dimension -> assumptions -> evidence

is stronger than either:

“Value risk: medium”

or a large unclassified assumption list.

Mild terminology conflict: Value versus Desirability#

This is the one disagreement Torres describes directly.

Cagan argued that desirability could blur customer value and usability and is particularly awkward in B2B, where users may need a product to do their jobs without “desiring” it. Torres retained desirability, arguing that wanting something and being able to use it are separate, and that B2B adoption and renewal can still depend on willingness to use. ¹

Both positions are internally coherent.

For team language, prefer:

Value: Will the relevant customer or user choose the required behaviour given their alternatives and costs?

This covers purchase, adoption, switching, continued use, and required behaviour without requiring users to emotionally “desire” a mandatory enterprise system.

Under it, use value assumptions, not “desirability assumptions.”

Real taxonomy conflict: Feasibility versus Viability#

Torres deliberately allows feasibility to include technical, legal, compliance, security, and even organizational constraints. She says the exact classification matters less than ensuring the assumptions are surfaced and assessed. ⁹

SVPG draws the boundary differently. Its 2026 material puts compliance, security, legality, marketing/selling economics, and monetization under viability, while feasibility focuses on whether the solution can technically be built. ¹¹

For organizational clarity, adopt the SVPG boundary:

Feasibility: Can the team technically create and deliver the intended behaviour with available technology, data, skills, dependencies, and relevant time constraints?

Viability: Can the organization legally, commercially, financially, operationally, and organizationally support the solution?

The classification itself is secondary to surfacing the assumption. Torres explicitly makes that point. ⁹²

One useful caveat comes from SVPG’s 2026 distinction between discovery and delivery: ordinary production concerns such as scale, fault tolerance, reliability, privacy, security, and operations become delivery concerns when the solution is already known and those properties are implementation work. They remain discovery concerns when uncertainty about them could invalidate the proposed solution. ¹⁶

So:

“Can this model ever achieve the accuracy required for regulated approval?” -> discovery feasibility/viability assumption.

“Implement the known authorization pattern correctly” -> delivery requirement.

Ethics should be explicit#

Torres has five categories because ethical assumptions sit alongside desirability, viability, feasibility, and usability. The guiding question is whether building the solution might cause harm. ²

SVPG’s main four-risk taxonomy says ethics can be embedded in viability, but Cagan has separately argued that this makes ethics too easy to lose among sales, finance, legal, compliance, privacy, and other viability concerns. He therefore proposed explicitly asking a fifth question: whether the team should build the solution. ¹⁰⁶

There is therefore less disagreement than the “four versus five” labels imply.

The recommendation is:

Ethics / Harm: Could this solution create material harm for customers, non-customers, employees, society, or the environment, even if it is valuable, usable, feasible, and commercially viable?

For an AI reconciliation product, an assumption might be:

“Automatically prioritizing invoices will not systematically disadvantage small suppliers due to poorer historical data quality.”

Evidence could include subgroup analysis, failure-mode review, stakeholder/user interviews, and a controlled pilot.

Genuine emphasis difference: opportunity discovery#

Torres gives the product team an explicit mechanism for continuously discovering and prioritizing customer opportunities. SVPG’s current formulation assumes that product strategy has already identified a worthwhile problem and argues that the difficult work is usually finding a winning solution. ³¹¹¹

This should not be resolved by choosing one philosophy universally.

The appropriate allocation depends on uncertainty:

When the strategic problem is clear but the answer is unclear, spend most effort on solution discovery.

When the customer, need, segment, or causal connection to the outcome is weakly understood, invest more heavily in opportunity discovery.

That preserves SVPG’s warning against endless problem research while retaining Torres’s protection against solving the wrong customer need.

Unified taxonomy and workflow#

The following taxonomy keeps each term at one conceptual level.

The first three levels come directly from Torres’s discovery structure; the risk dimensions come from SVPG, with explicit ethics supported by both Torres’s taxonomy and Cagan’s ethics guidance; the assumption/evidence mechanism follows Torres; the risk/consequence discipline follows SVPG. ^2610267

Recommended team document#

Instead of a document with headings such as:

Value risk Usability risk Feasibility risk Viability risk

Keep one evidence table per target opportunity or solution set:

Torres recommends being specific because specific assumptions enable smaller, faster tests, and she recommends agreeing on success criteria before running the test. ²⁸

Decision flow#

  flowchart TD
    A[Desired outcome] --> B[Continuously learn about customer opportunities]
    B --> C[Map and compare opportunity space]
    C --> D[Choose target opportunity]

    D --> E[Generate multiple candidate solutions]

    E --> F[Scan solution risk dimensions:
    Value
    Usability
    Feasibility
    Viability
    Ethics]

    F --> G[Enumerate concrete assumptions]

    G --> H{Critical assumption
    has weak evidence?}

    H -->|Yes| I[Choose fastest credible
    assumption test]
    I --> J[Collect evidence]
    J --> K{What was learned?}

    K -->|Assumption weakened| L[Change or reject solution]
    K -->|Assumption strengthened| M[Update confidence]
    K -->|Learned about opportunity| B

    L --> E
    M --> H

    H -->|No material unknowns| N[Choose solution and move to delivery]
    N --> O[Release safely]
    O --> P[Measure production behaviour and outcome]

    P --> Q{Desired outcome achieved?}
    Q -->|Yes| R[Continue monitoring and discover next opportunity]
    Q -->|No| S[Diagnose assumptions,
    solution, opportunity, or outcome]
    S --> B

This flow deliberately has loops. Torres describes continuous discovery as weekly customer touchpoints and small research activities in pursuit of a product outcome, and describes the opportunity/solution relationship as bidirectional. SVPG likewise cautions against treating discovery and delivery as rigid sequential phases and says learning continues after release, with actual outcome impact as the ultimate evidence. ^19311611

Recommended vocabulary#

For team communication, standardize on this wording:

Desired outcome – what result is the work intended to change?

Opportunity – which customer need, pain point, or desire is being targeted?

Candidate solution – how might it be addressed?

Solution risk dimensions – Value, Usability, Feasibility, Viability, Ethics.

Assumption – what specifically must be true for this candidate to work?

Risk – what is the consequence if that assumption is false?

Evidence – what is currently known?

Assumption test – what is the cheapest credible way to learn enough to make the next decision?

Production outcome – after release, did actual behaviour and the target outcome change?

This keeps “risk” at the decision/consequence level and “assumption” at the testable-proposition level. It also keeps “opportunity” out of the solution taxonomy: an opportunity is something in the customer’s problem space, while Value/Usability/Feasibility/Viability/Ethics classify uncertainties about a proposed intervention. That separation is consistent with Torres’s OST structure and with SVPG’s description of the four risks as things to assess when discovering a solution worth building. ⁴¹⁰

The resulting model can be summarized as:

Torres tells the team where it is in the discovery decision structure. SVPG tells the team which classes of solution failure to remember. Concrete assumptions tell the team what to learn next. Evidence tells the team when it is reasonable to make a decision.

That is the recommended terminology for product-team documentation.

Citation references#