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

Status: Research synthesis and supporting material. The canonical guidance is risk-areas-model.md. This document preserves source comparisons, alternative terms, citations, and the reasoning from which the shorter model was developed.

Editorial note: This document reassembles existing passages around one coherent argument. The source prose remains verbatim. Labeled callouts explain the ordering and the choices made where the source notes contain competing models.

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.

Decision rationale: This thesis comes before the synthesis because the frameworks work at different levels. SVPG supplies a coverage check for solution failure, while Torres supplies the surrounding discovery and testing structure; treating them as substitutes would create a false choice.

The recommended synthesis is:

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

Decision rationale: The combined sequence is introduced before the naming decisions so the reader can first see where each concept belongs. It prevents the later terms from looking like one flat taxonomy.

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. ⁵¹⁶

Decision rationale: The choices of Value and explicit Ethics are stated early because they govern the vocabulary used throughout the document. Leaving them unresolved until later would make the synthesis appear internally inconsistent.

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. ⁷⁸

Decision rationale: This is the operational center of the argument. The proposed unit of discovery work is a testable assumption with consequences and evidence, not a broad dimension label.

There are four substantive differences to be aware of:

^1910611

Decision rationale: The table is a compact decision log: it isolates the points that require a choice from the larger area of agreement. The scope section follows immediately because those choices only make sense once the taxonomy’s boundary is explicit.

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.

This became clearer in SVPG’s newer writing.

Their current model starts with:

Problem -> desired outcome -> candidate solution

Then discovery asks whether the candidate solution is valuable, usable, feasible, and viable and whether it is likely to achieve the desired outcome. (Silicon Valley Product Group)

Avoid claiming:

“These are the four risks of building a product.”

That’s too broad.

Instead:

These are four major dimensions of solution risk.

There are uncertainties outside them.

For example:

Problem selection risk

Is the problem worth spending resources on?

Problem-understanding risk

Are the problem and affected people understood correctly?

Outcome risk

Even if people adopt the solution, does it actually move the target metric or business outcome?

Delivery/operational risks

Will the production implementation be reliable, secure, scalable, observable, etc.?

SVPG explicitly separates problem discovery from solution discovery, and its 2026 material says the four risks primarily apply while discovering the solution. (Silicon Valley Product Group)

That scope makes the model much stronger.

Decision rationale: This narrower scope turns an overbroad product-risk claim into a precise solution-discovery tool. Problem selection, problem understanding, outcome realization, and routine delivery remain important, but sit outside this taxonomy.

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.

Decision rationale: The invoice example makes the two axes concrete. It justifies keeping Outcome, Opportunity, and Solution as the decision structure while using risk dimensions to inspect each candidate solution.

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. ¹⁶

Decision rationale: This passage is retained because the tree can otherwise be mistaken for a waterfall. Its bidirectional character is essential to the later workflow, where solution evidence can revise the understood opportunity or outcome.

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:

Decision rationale: The side-by-side comparison shows that the genuine difference concerns ownership, emphasis, and allocation of discovery effort, not merely terminology.

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.

Decision rationale: This synthesis preserves strategic direction from leadership without removing the team’s responsibility to discover which customer need within that direction is worth addressing. Terminology comes next because the two axes are now separated.

Terminology differences#

The terms are related but should not be collapsed.

Decision rationale: The vocabulary table precedes the worked examples because every later section depends on these terms remaining distinct. It fixes stable meanings for risk, uncertainty, assumption, evidence, test, and experiment before showing how they interact.

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. ⁷⁸

Decision rationale: The worked example is retained because each field answers a different decision question. Without one assumption decomposed into evidence, uncertainty, and risk, the distinctions could appear merely semantic.

Decision rationale: The notes contain two operational models. Earlier passages use Dimension -> Risk -> Assumption -> Test -> Evidence; the later synthesis makes the assumption the atomic testable proposition and records uncertainty, consequence, evidence, and the next test around it. This assembly chooses the latter because a broad risk label is not directly testable, while an assumption is. The risk-first version remains preserved in the source notes.

Concept mapping#

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. ²⁸

Decision rationale: A B2B case is used because the separation between buyer and user puts the Value-Usability distinction under the greatest pressure. The internal-product caveat prevents that case from being generalized beyond its limits.

The broader SVPG material presents a coherent model, but the terminology mixes two levels: properties of a good solution and risks that those properties won’t hold.

SVPG itself uses both forms. It says an effective solution is “valuable, usable, feasible and viable,” while also calling value/usability/feasibility/viability a risk taxonomy. (Silicon Valley Product Group)

It can be formalized this way.

1. The four are solution dimensions#

A candidate solution needs to satisfy four conditions:

Decision rationale: The dimensions are phrased as conditions a successful solution must satisfy. This keeps each property separate from the uncertainty and consequence associated with its possible failure.

2. Value needs the most careful definition#

SVPG defines value more narrowly than the word normally implies.

It means roughly:

Will the customer buy it, or will the user choose to use it?

SVPG explicitly distinguishes this from usability: a user may be perfectly capable of using something while having no desire to use it. Their 2025 material calls this the distinction between “could use” and “choose to use.” (Silicon Valley Product Group)

A slightly stronger definition is:

Value: Will the target customer/user choose this solution given their alternatives, costs of switching/adoption, and the importance of the problem?

For a commercial product, this becomes competitive:

Is this solution sufficiently better than the customer’s current alternative that they will switch, buy, adopt, or continue using it?

That matches SVPG’s newer emphasis. In 2026 they explicitly say that a commercial solution often needs to be substantially better than alternatives to cause switching. (Silicon Valley Product Group)

For an internal product the definition changes slightly because users may have no meaningful choice. SVPG acknowledges this. In that case, value can be defined as:

Does the solution actually solve the intended problem well enough to produce the required benefit?

SVPG says much the same: for internal products, what counts is successfully completing the job to be done. (Silicon Valley Product Group)

So “value” is probably the weakest label of the four. “Adoption risk” would be clearer for commercial products, but worse for internal products.

Value is worth retaining for compatibility, with an explicit definition.

Decision rationale: Value receives the longest treatment because it is the most ambiguous label. The argument tests it against commercial and internal cases before retaining the familiar term with a stricter definition.

3. Usability is comparatively clean#

It can be defined as:

Usability: Can the intended users successfully accomplish the required tasks in their expected context, with an acceptable amount of learning, effort, and assistance?

The important separation is:

• “The solution can be used successfully” -> usability.
• “The solution is worth choosing or using” -> value.

A beautiful, intuitive solution to a problem nobody cares about has low usability risk and high value risk.

A highly desirable tool with a confusing workflow has low value risk and high usability risk.

This separation is one reason SVPG prefers four dimensions over IDEO’s desirability/feasibility/viability taxonomy, especially for B2B products where buyer and user can be different people. (Silicon Valley Product Group)

Decision rationale: Usability follows Value so their boundary is fixed immediately. The paired counterexamples show that willingness and ability can fail independently rather than forming one combined concern.

4. Feasibility should mean more than “can it compile?”#

SVPG’s original wording is:

Can the engineers build what is needed with the time, skills, and technology available? (Silicon Valley Product Group)

Their newer material talks about being able to build and deliver a product-quality solution. (Silicon Valley Product Group)

It can therefore be defined as:

Feasibility: Can the team build and deliver the required solution within the relevant technical, capability, and time constraints?

Examples of concrete feasibility risks:

• the model may not achieve required accuracy;
• latency may be too high;
• an external API may not support the required behavior;
• the team may lack a required technical capability;
• the architecture may not handle the necessary scale;
• implementation may take 18 months when the opportunity requires 3.

One boundary needs judgment. SVPG’s 2026 material separates discovery risks from ordinary delivery concerns such as reliability, scale, fault tolerance, security, and operations. (Silicon Valley Product Group)

The following rule is useful:

If a technical property could invalidate the solution concept, it is feasibility risk during discovery. If the means of satisfying it are already known and only correct implementation remains, it is delivery work.

For example, “Can inference finish within 100 ms at all?” is discovery. “Make sure the known implementation meets its 100 ms SLO” is delivery.

Decision rationale: The discovery-versus-delivery rule is retained because the same technical property can belong to either stage. Whether the uncertainty can invalidate the solution concept is the practical boundary; the topic alone does not determine the classification.

5. Viability is the broad business constraint#

It can be defined as:

Business viability: Can the organization offer, operate, support, and benefit from this solution within its economic, legal, strategic, commercial, and organizational constraints?

This includes things such as:

• monetization and unit economics;
• sales;
• marketing and distribution;
• customer support/service;
• legal;
• compliance;
• privacy/security requirements;
• contracts and partnerships;
• brand;
• financing/funding;
• manufacturing or operations.

SVPG explicitly places sales, marketing, finance, legal, compliance, and similar concerns here. (Silicon Valley Product Group)

It is deliberately a large bucket. Cagan acknowledges that things like ethics, compliance, and go-to-market could be separate risk categories, but argues that a short taxonomy people actually use is preferable. (Silicon Valley Product Group)

The clean distinction with value is:

Value asks whether the customer wants the transaction. Viability asks whether the business wants and can support the transaction.

For example:

Customer will happily pay $10/month -> value looks good.

Serving that customer costs $35/month -> viability problem.

Decision rationale: Viability completes the technical-versus-business boundary. The two-sided transaction example makes the distinction concrete: customer willingness belongs to Value, while organizational sustainability belongs to Viability.

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.

Decision rationale: The detailed mapping follows the standalone definitions so the example tests the chosen boundaries rather than defining them by anecdote. The raw note supplied the fullest definitions; passages that simply equate risk with uncertainty were excluded because they conflict with the terminology established above.

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.

Decision rationale: Complementarity is established before disagreement so the residual conflicts are not overstated. The chosen structure needs both a completeness scan and propositions concrete enough to test.

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.”

Decision rationale: This is a team-language decision, not a claim that Torres’s term is conceptually wrong. Value is chosen because it describes choice and adoption without implying emotional desire, while preserving Usability as a separate dimension.

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.

Decision rationale: The SVPG boundary is adopted for clarity of ownership and action, not because every constraint has one intrinsic category. The stage-dependent caveat preserves cases where legal, security, or technical uncertainty can invalidate the solution itself.

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.

Decision rationale: Ethics is explicit because visibility is itself a safeguard. Harm can exist even when a solution is valuable, usable, feasible, and commercially viable, and it is easier to omit when buried inside the broad Viability category.

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.

Decision rationale: The emphasis conflict is resolved according to where uncertainty is concentrated rather than by declaring one universal winner. These disagreements precede the unified model because that model depends on the choices made here.

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. ^1510267

Decision rationale: The “Level” column shows that each term answers a different kind of question. The unified taxonomy appears only after the conflicts because it is the result of those choices, not a neutral restatement of either source framework.

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 rationale: The evidence table translates the ontology into a usable team artifact. Making the assumption the row’s atomic proposition keeps consequence, confidence, evidence, test, success criterion, and decision visible without collapsing them into one risk score.

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. ^19162511

Decision rationale: The diagram converts the static record into a learning process. Its loops prevent the taxonomy from being read as a stage gate and allow evidence to revise the assumption, candidate solution, opportunity, or outcome.

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.

Decision rationale: This compact vocabulary is the team-facing version of the fuller model. It comes after the ontology and workflow so the prescribed words have already been defined, bounded, and demonstrated.

Discovery practice differences#

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

Decision rationale: This crosswalk appears after the unified model because it is an execution check, not part of the conceptual hierarchy. The combined-practice column turns the source comparison into a concrete operating approach.

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.

Decision rationale: Dimensions are used first as a completeness scan, then assumptions become the testable units. Starting and stopping at dimensions would remain vague; starting with an unstructured assumption list could miss an important class of failure.

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. ⁷³²

Decision rationale: Prioritization follows surfacing because ranking only makes sense once assumptions exist. Criticality, consequence, and evidence strength remain separate to guide judgement without introducing false precision.

Editorial note: The long practitioner inventory and alternative naming schemes are kept in risk-areas-comparisons.md. They support this argument, but placing them in the main path would interrupt the dependency from definitions to operating practice.

Citation references#

Reference note: These numeric turn... entries are preserved from the source report. They are internal research references rather than usable publication citations. Rearrangement can retain them, but cannot repair them without changing the underlying text and sourcing.