# How to Identify and Prioritize Risky Assumptions Using the Value/Usability/Feasibility/Viability Framework

> Identify and prioritize risky assumptions using the Value Usability Feasibility Viability framework. Focus experimentation on high impact high risk items. Learn this essential PM skill now.

- Repository: [Pawel Huryn/pm-skills](https://github.com/phuryn/pm-skills)
- Tags: how-to-guide
- Published: 2026-06-14

---

**Risky assumptions are identified through devil's-advocate analysis across four risk buckets (Value, Usability, Feasibility, Viability) and prioritized using an Impact × Risk matrix that focuses experimentation on high-impact, high-risk items.**

The `phuryn/pm-skills` repository provides a systematic Product Discovery toolkit that implements the **Value/Usability/Feasibility/Viability** (VUFV) framework to surface and rank assumptions before committing engineering resources. This approach ensures product teams validate the most consequential uncertainties first, reducing waste on features that might fail due to misunderstood user needs or technical constraints.

## The Two-Phase Process for Risky Assumption Management

The framework operates through two distinct phases defined in the Product Discovery skills: identification and prioritization.

### Phase 1: Identifying Assumptions Across Four Risk Buckets

In [`identify-assumptions-existing/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-existing/SKILL.md) and [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md), the model conducts a **devil's-advocate analysis** from three product-team perspectives: Product Manager, Designer, and Engineer. For each perspective, the framework forces explicit articulation of assumptions within the four risk categories:

- **Value**: Will users actually want this?
- **Usability**: Can users figure out how to use it?
- **Feasibility**: Can we build and maintain it with our technical capabilities?
- **Viability**: Can we support this operationally and financially?

Each assumption is recorded with a short description, a **confidence level** (High/Medium/Low), and a suggested validation test. This structured approach prevents teams from overlooking critical failure modes that typically hide in cross-functional blind spots.

### Phase 2: Prioritizing with the Impact × Risk Matrix

Once assumptions are surfaced, the [`prioritize-assumptions/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/prioritize-assumptions/SKILL.md) skill maps them onto a **Impact × Risk** matrix (also called the "leap-of-faith" canvas).

**Impact** is calculated using ICE or RICE scoring models documented in [`prioritization-frameworks/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/prioritization-frameworks/SKILL.md):
- **Impact** = Opportunity Score × Number of Customers (or Reach × Impact in RICE)

**Risk** is calculated as:
- **Risk** = (1 − Confidence) × Effort

Where **Confidence** is rated 1-10 and **Effort** is estimated in hours or story points. The matrix yields four quadrants that determine the action for each assumption:

- **Low Impact × Low Risk**: Defer or ignore
- **High Impact × Low Risk**: Ship immediately
- **Low Impact × High Risk**: Discard or reject
- **High Impact × High Risk**: **Prototype and experiment** (the validation sweet spot)

## Implementation Workflow

The framework executes through a five-step workflow orchestrated by the `/discover` command:

1. **Context gathering**: The user provides product or feature descriptions (or uploads PRDs and research files)
2. **Assumption mapping**: The skill iterates over the four risk categories, prompting "what could go wrong?" from each team perspective
3. **Scoring**: Each assumption receives a Confidence rating (1-10) and Effort estimate
4. **Matrix placement**: Calculated Impact and Risk scores place the assumption in one of four quadrants
5. **Outcome routing**: High-Impact/High-Risk assumptions proceed to lean experiments (A/B tests, fake-door tests, prototypes, concierge MVPs), while others are shipped, deferred, or discarded

## Practical Examples and Commands

Below are practical command-line style invocations that execute the framework in the `phuryn/pm-skills` toolkit.

### Running a Full Discovery Cycle

```text
/discover
/discover Smart notification system for our project-management tool

```

This command internally chains:
- `identify-assumptions-existing` → surfaces assumptions across Value/Usability/Feasibility/Viability
- `prioritize-assumptions` → maps them onto the Impact × Risk matrix and returns a ranked table

### Direct Assumption Identification

```text
/identify-assumptions-existing "Feature: Inline comment editing"

```

The bot outputs a structured markdown table:

| # | Category | Assumption | Confidence | Suggested Test |

|---|----------|------------|------------|----------------|
| 1 | Value | Users will edit comments more often | High | A/B test edit frequency |
| 2 | Usability | Inline UI will be discoverable | Medium | Click-through prototype |
| 3 | Feasibility | Existing editor component can be reused | Low | Spike on integration |
| 4 | Viability | Support team can handle additional tickets | High | Support load simulation |

### Prioritizing with the Matrix

```text
/prioritize-assumptions

```

After importing the assumption table, the bot returns:

```

🟢 High-Impact Low-Risk → Ship now
🔴 High-Impact High-Risk → Run experiment:
   • Experiment: A/B test inline editing vs. modal editing
   • Success metric: 15% increase in edit count

```

### Designing Validation Experiments

For high-priority assumptions, generate experiment plans:

```text
/brainstorm-experiments-existing "A/B test inline editing vs. modal editing"

```

Output includes:

| Experiment | Method | Success Criteria | Effort |
|------------|--------|------------------|--------|
| Inline-Edit A/B | Deploy feature flag to 10% of users | ≥15% lift in edit count | 2 sp |
| Fake-door landing | Show "Edit inline" button on landing page | ≥30% click-through | 1 sp |

## Key Files and Implementation Details

The VUFV framework is implemented across these specific files in the `phuryn/pm-skills` repository:

- **[`identify-assumptions-existing/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-existing/SKILL.md)**: Defines the four-risk-area analysis and perspective-based prompts for existing products
- **[`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md)**: Implements the same analysis framework for brand-new product ideas
- **[`prioritize-assumptions/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/prioritize-assumptions/SKILL.md)**: Contains the Impact × Risk matrix logic and quadrant-based routing rules
- **[`discover.md`](https://github.com/phuryn/pm-skills/blob/main/discover.md)** (command): Orchestrates the end-to-end workflow, chaining identification and prioritization skills
- **[`prioritization-frameworks/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/prioritization-frameworks/SKILL.md)**: Provides the detailed ICE/RICE scoring formulas referenced by the prioritization step

## Summary

- **Risky assumptions** are surfaced through devil's-advocate analysis across **Value, Usability, Feasibility, and Viability** categories in `identify-assumptions-existing` and `identify-assumptions-new` skills
- Each assumption receives **Confidence** (1-10) and **Effort** scores to calculate **Risk** as (1 − Confidence) × Effort
- **Impact** is derived from ICE or RICE scoring models that consider opportunity size and reach
- The **Impact × Risk matrix** routes High-Impact/High-Risk assumptions to experiments while shipping or deferring others
- The `/discover` command automates the full workflow, ensuring teams focus validation resources on assumptions that would cause the biggest loss if wrong

## Frequently Asked Questions

### How does the Value/Usability/Feasibility/Viability framework differ from traditional risk analysis?

Traditional risk analysis often focuses on technical feasibility and project timelines. The VUFV framework explicitly surfaces **user value** and **usability** risks alongside **feasibility** and **viability**, ensuring product-market fit issues are identified before engineering begins. By forcing analysis from Product Manager, Designer, and Engineer perspectives simultaneously, it eliminates siloed blind spots that plague single-discipline risk assessments.

### What is the formula for calculating Risk in the prioritization matrix?

According to the `prioritize-assumptions` skill implementation, **Risk** is calculated as **(1 − Confidence) × Effort**, where Confidence is rated on a 1-10 scale (converted to a decimal) and Effort is estimated in hours or story points. This means assumptions with low confidence and high implementation cost generate the highest risk scores, flagging them for validation experiments before committing full development resources.

### Which assumptions should go directly to engineering versus experimentation?

Assumptions landing in the **High-Impact × Low-Risk** quadrant of the matrix proceed directly to engineering for shipment, as the team has high confidence and the effort is justified by the opportunity. Conversely, **High-Impact × High-Risk** assumptions—where uncertainty could lead to costly failure—must proceed to lean experiments (A/B tests, fake-door tests, or prototypes) to validate core hypotheses before full build-out.

### How do the identify-assumptions-existing and identify-assumptions-new skills differ?

While both skills implement the same four-category VUFV framework, `identify-assumptions-existing` in [`pm-product-discovery/skills/identify-assumptions-existing/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-product-discovery/skills/identify-assumptions-existing/SKILL.md) is optimized for incremental features on existing products with established user bases and technical constraints. The `identify-assumptions-new` skill handles greenfield product ideas where technical architecture and market viability are entirely unproven, though both use identical confidence scoring and risk categorization methodologies.