# Common Pitfalls When Using the Value/Usability/Feasibility/Viability Framework

> Avoid common pitfalls when using the Value Usability Feasibility Viability framework. Learn to prevent static checklists conflating viability with value and mismatched experiments.

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

---

**The most common pitfalls when using the Value/Usability/Feasibility/Viability framework include treating the four buckets as a static checklist, conflating business viability with customer value, analyzing multiple segments simultaneously, and failing to pair assumptions with concrete experiments.**

The Value/Usability/Feasibility/Viability (V-U-F-V) framework, popularized by Teresa Torres' *Continuous Discovery Habits*, serves as the backbone of product discovery in the `phuryn/pm-skills` repository. While the four risk buckets appear simple on the surface—listed in [`pm-product-discovery/skills/identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-product-discovery/skills/identify-assumptions-new/SKILL.md) as **Value**, **Usability**, **Feasibility**, and **Viability**—teams frequently stumble over predictable implementation traps that undermine the framework's effectiveness.

## Treating the Four Buckets as a Static Checklist

The [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md) file presents the four risk categories as a concise list spanning lines 18–36, which tempts teams to treat the framework as a “tick-the-box” exercise. When product teams simply mark each category as “addressed” without probing deeper, they miss nuanced assumptions that surface only through guided inquiry. This superficial approach contradicts the framework’s intent as a thinking lens rather than a compliance document.

### Shift from Compliance to Conversation

Instead of checking boxes, use the guided prompts found in the same skill file, specifically the “Think from three perspectives” exercise spanning lines 26–30. This approach forces cross-functional discussion by requiring input from Product Managers, Designers, and Engineers for each risk bucket. Frame the activity as a risk-discovery conversation rather than a documentation requirement to surface underlying uncertainties.

## Analyzing Multiple Segments Simultaneously

The framework is explicitly designed for *one segment at a time*, as emphasized in [`pm-product-strategy/skills/value-proposition/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-product-strategy/skills/value-proposition/SKILL.md) lines 78–82. Teams often apply the same V-U-F-V analysis across multiple customer segments without adapting the questions, which produces vague or contradictory insights that fail to reflect specific user realities. This conflation masks segment-specific risks that could kill the product for one audience while seeming viable for another.

### Run Parallel Analyses for Different Audiences

Execute separate V-U-F-V assessments for each target segment, explicitly stating the segment at the top of each analysis. Compare findings across segments to identify divergent risks rather than averaging them into meaningless generalizations. This method aligns with the repository’s emphasis on segment-specific value propositions.

## Conflating Viability with Value

In [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md), **Viability** specifically addresses business economics—monetisation, cost, and compliance—while **Value** focuses on customer benefit and retention (lines 33–36). Teams frequently merge these categories, asking only “Will customers like this?” while overlooking “Will customers pay enough to sustain the business?” This confusion leads to products users love but businesses cannot afford to operate.

### Distinguish Customer Benefit from Business Economics

Maintain a strict mental and written distinction: under **Value**, ask “Will customers find this valuable enough to keep using it?” and under **Viability**, ask “Will this generate sufficient revenue to cover costs and compliance requirements?” This separation ensures financial feasibility receives independent scrutiny rather than being assumed as a byproduct of user satisfaction.

## Neglecting the Usability Dimension

The framework explicitly calls out **Usability** concerns including learning curve, onboarding friction, and cognitive load in [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md) lines 34–35. Despite this, many product discussions default to feature completeness and skip user-experience validation entirely. Ignoring usability risks assumes that valuable features automatically translate to usable products, which proves false in high-stakes enterprise or complex consumer contexts.

### Validate Cognitive Load Early

Include a dedicated usability walkthrough—such as a prototype test or cognitive walkthrough—before advancing to feasibility or viability assessments. Test whether users can interpret analytics, navigate workflows, or onboard without extensive training. This step prevents committing to features that solve real problems but remain inaccessible to the target audience.

## Defining Feasibility Too Narrowly

According to [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md) lines 36–37, **Feasibility** encompasses technology, integration complexity, efficiency, and scalability—not merely “Can engineering build it?” Teams often limit feasibility analysis to technical constraints, ignoring operational readiness, supply-chain limitations, or regulatory compliance. This narrow view surfaces critical blockers only after development commitments have been made.

### Expand Beyond Technical Constraints

Broaden the feasibility inquiry to include supply-chain viability, legal compliance, and operational readiness alongside technical architecture. Ask whether the organization can support the feature at scale, not just whether the code can be written. This holistic view prevents feasibility surprises that emerge post-launch.

## Isolating the Analysis from Market Reality

The [`pm-product-strategy/skills/value-proposition/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-product-strategy/skills/value-proposition/SKILL.md) file includes an “Alternatives” section spanning lines 53–56 that forces teams to name competing solutions. When teams skip this step, the V-U-F-V analysis remains isolated from market reality, evaluating the product in a vacuum rather than against actual customer options. This omission leads to overestimating value and underestimating switching costs.

### Map Competing Solutions Explicitly

Always identify at least three realistic alternatives—whether direct competitors, manual workarounds, or status quo inertia—and explicitly compare them against your assumptions across all four buckets. This comparison validates whether your feasibility and viability claims hold up against existing market solutions. The repository’s value proposition skill treats this as mandatory, not optional.

## Failing to Connect Assumptions to Experiments

The [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md) skill encourages rating confidence and suggesting tests for each assumption (lines 42–44), yet teams often stop at “high confidence” or “low risk” without defining validation steps. Without concrete experiments, confidence ratings become opinions rather than data points. This gap leaves teams unprepared when assumptions prove false during development.

### Pair Risk Buckets with Fast, Cheap Tests

Use the “Experiment” step from [`pm-product-discovery/skills/opportunity-solution-tree/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-product-discovery/skills/opportunity-solution-tree/SKILL.md), which recommends fast, cheap tests spanning lines 22–23, to create clear validation steps for every risk bucket. For each assumption in the V-U-F-V framework, define a specific experiment—such as a smoke test, prototype, or technical spike—that can validate or invalidate the risk within days, not months.

## Treating the Framework as a One-Off Exercise

Continuous discovery requires repeated application of the V-U-F-V framework, yet some teams treat it as a single worksheet completed during initial ideation. This static approach misses new risks that emerge after prototype testing, market feedback, or technical spikes. The framework’s value diminishes when it lives in an initial PRD rather than evolving with the product.

### Revisit at Key Milestones

Re-run the V-U-F-V analysis at critical decision points—after user interviews, prototype tests, or competitive shifts—to surface new risks and retire outdated assumptions. Treat the framework as a living document that guides iteration rather than a gatekeeping document that greenlights development. This cadence aligns with the repository’s emphasis on continuous discovery habits.

## Practical Implementation Example

Below is a minimal prompt structure that applies the V-U-F-V framework correctly to a feature idea, designed for the `identify-assumptions-existing` skill in the `phuryn/pm-skills` repository:

```markdown
---
name: identify-assumptions-existing
description: "Identify risky assumptions for a feature idea in an existing product across Value, Usability, Viability, and Feasibility."
---

## Feature Idea

**Product:** TeamCollab
**Feature:** Real-time task-level analytics dashboard

## Run the assumption analysis

- **Value:** Will customers consider the dashboard essential enough to keep paying?
- **Usability:** Can users interpret the analytics without extensive training?
- **Viability:** Does the added analytics increase our hosting costs beyond our budget?
- **Feasibility:** Do our current data pipelines support real-time aggregation at scale?

*Rate confidence (0-100) and suggest a quick validation experiment for each.*

```

When executed, this skill outputs a markdown table with confidence scores and suggested experiments, following the pattern described in [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md) lines 42–44. This format ensures each risk bucket receives specific, testable scrutiny rather than generic acknowledgment.

## Summary

- **Use the framework as a conversation driver**, not a static checklist, by leveraging the three-perspective prompts in [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md).
- **Separate the four buckets clearly**, distinguishing customer **Value** from business **Viability** and expanding **Feasibility** beyond pure technical constraints.
- **Iterate continuously** by re-running the analysis at milestones rather than treating it as a one-time ideation exercise.
- **Integrate usability validation and competitive alternatives** to maintain customer-centricity and market realism throughout the discovery process.

## Frequently Asked Questions

### What is the difference between Value and Viability in the framework?

**Value** measures whether customers will find the product beneficial enough to use and retain, while **Viability** measures whether the business can afford to build and sustain it through monetisation, cost management, and regulatory compliance. According to [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md), these are distinct risk buckets (lines 33–36) that require separate validation: ask “Will they use it?” for Value and “Will they pay enough?” for Viability.

### How often should teams run the V-U-F-V analysis?

Teams should treat the framework as a continuous discovery tool rather than a one-time worksheet. Re-run the analysis at key milestones—such as after prototype tests, user interviews, or market shifts—to surface new risks and validate previous assumptions. This iterative approach aligns with the repository’s emphasis on continuous discovery habits and prevents outdated risk assessments from guiding development.

### Why is the Usability dimension frequently overlooked in V-U-F-V assessments?

Teams often default to feature-centric discussions that assume “if we build it, they will use it,” ignoring the cognitive load, onboarding friction, and learning curves explicitly called out in [`identify-assumptions-new/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/identify-assumptions-new/SKILL.md) (lines 34–35). To avoid this, include dedicated usability walkthroughs or prototype tests before advancing to feasibility reviews, ensuring the product is accessible to its intended audience.

### Can the V-U-F-V framework be used for multiple customer segments at once?

No, the framework is designed to analyze *one segment at a time*, as specified in [`pm-product-strategy/skills/value-proposition/SKILL.md`](https://github.com/phuryn/pm-skills/blob/main/pm-product-strategy/skills/value-proposition/SKILL.md) (lines 78–82). Applying the same analysis across multiple segments simultaneously produces vague or contradictory insights. Instead, run parallel V-U-F-V assessments for each distinct segment and compare findings to identify segment-specific risks.