Identify Assumptions Existing

Identify Assumptions Existing

Identify risky assumptions for a feature idea in an existing product across Value, Usability, Viability, and Feasibility. Uses multi-perspective

Category: development Source: phuryn/pm-skills

What Is This?

Overview

When a product team proposes a new feature for an existing product, the idea often carries hidden assumptions that go unexamined until they become expensive problems. The Identify Assumptions Existing skill is a structured analytical technique that surfaces those risky assumptions before development begins. It applies devil's advocate thinking across four critical risk dimensions: Value, Usability, Viability, and Feasibility.

This skill is designed specifically for existing products, where the stakes are higher because changes affect a live user base, established workflows, and real revenue streams. Unlike greenfield ideation, assumption identification in an existing product requires accounting for legacy constraints, current user behavior, and the competitive context already in play. The technique forces teams to ask uncomfortable questions early, when the cost of pivoting is low.

The process produces a structured list of assumptions that can feed directly into assumption mapping sessions, risk registers, or discovery backlogs. It is not about killing ideas. It is about knowing which bets you are making so you can validate them deliberately rather than discover them accidentally.

Who Should Use This

  • Product managers preparing a feature brief or writing a product requirements document
  • Product designers stress-testing a concept before committing to wireframes
  • Engineering leads evaluating technical feasibility before sprint planning
  • Startup founders assessing whether a proposed feature aligns with business sustainability
  • QA and risk analysts building test coverage around uncertain behaviors
  • Agile coaches facilitating assumption mapping workshops with cross-functional teams

Why Use It?

Problems It Solves

  • Teams ship features based on untested beliefs about what users want, leading to low adoption and wasted engineering effort
  • Feasibility risks are discovered late in development, causing scope cuts and rework
  • Business viability concerns are raised after launch rather than before, when reversing course is costly
  • Usability assumptions go unchallenged because designers are too close to the solution
  • Cross-functional teams lack a shared vocabulary for discussing risk, leading to misaligned priorities

Core Highlights

  • Covers all four VUFB risk dimensions: Value, Usability, Feasibility, and Viability
  • Uses devil's advocate framing to bypass confirmation bias
  • Produces actionable outputs suitable for assumption mapping and risk registers
  • Applies specifically to existing products with live users and real constraints
  • Encourages multi-perspective thinking across roles and disciplines
  • Scales from solo analysis to full team workshops
  • Integrates with discovery, sprint planning, and go/no-go decision processes

How to Use It?

Basic Usage

The skill is invoked by providing a feature idea and the existing product context. A typical prompt structure looks like this:

Product: [Name and brief description of the existing product]
Feature Idea: [One to two sentence description of the proposed feature]
Task: Identify risky assumptions across Value, Usability, Viability, and Feasibility.

The output is a categorized list of assumptions, each framed as a belief the team is implicitly holding. For example:

Value:
- We assume users currently experience friction at this step and want it removed.
- We assume this feature will increase retention, not just initial engagement.

Feasibility:
- We assume the existing data model supports this without a schema migration.
- We assume third-party API rate limits will not constrain the feature at scale.

Specific Scenarios

Scenario 1: Pre-Sprint Risk Review. Before committing a feature to a sprint, a product manager runs this skill to generate a list of assumptions. The team reviews the list and flags which assumptions are unvalidated. High-risk unvalidated assumptions become discovery tasks before development starts.

Scenario 2: Assumption Mapping Workshop. A facilitator uses the output as seed material for a team workshop. Assumptions are printed on cards, placed on a two-by-two grid of certainty versus risk, and prioritized for validation experiments.

Real-World Examples

A team building a notification preference center assumed users wanted granular control. The skill surfaced the counter-assumption that most users ignore notification settings entirely. A quick survey validated the counter-assumption, saving two weeks of development.

An engineering team assumed a new filtering feature could reuse existing query infrastructure. The feasibility assumption check revealed that query complexity would exceed current database index coverage, prompting an architecture review before a single line of code was written.

Important Notes

Requirements

  • A clearly defined feature idea with enough detail to reason about its implications
  • Basic familiarity with the existing product, its users, and its technical architecture
  • Willingness to engage with uncomfortable counter-arguments without dismissing them prematurely