skills/product-app-architect/references/product_discovery_framework.md

# Product Discovery Framework

## Purpose

Use this file to decide what should be built before producing detailed requirements or architecture.

Discovery should reduce uncertainty around the problem, user, value, usability, feasibility, and differentiation. It is not a ceremony and does not require a long document.

# 1. Classify the input

## Raw idea
Start with the problem and user, not feature expansion.

## Domain
Generate a small set of product opportunities, compare them, and recommend one.

## Existing product
Inspect the current experience before proposing new scope.

## Feature request
Treat it as a change to an existing product, not a new product.

## Competitor/reference
Understand what the reference actually does, then identify transferable patterns and differentiation.

# 2. Problem framing

Capture:
- **Target user:** Who has the problem?
- **Context:** When/where does it occur?
- **Problem:** What is difficult, slow, confusing, risky, expensive, or missing?
- **Current workaround:** What do users do today?
- **Consequence:** Why does the problem matter?
- **Evidence:** What is known vs assumed?

Avoid vague problems such as “people need a better app.”

# 3. Opportunity test

Evaluate:

## Value
Would solving this create a meaningful benefit?

## Usability
Can the user reasonably understand and complete the core task?

## Feasibility
Can it be built and operated with realistic technology, data, budget, and maintenance?

## Strategic fit
Does it match the stated product/business goal?

## Differentiation
Why would a user choose this over existing alternatives or their current workaround?

## Evidence confidence
What supports the idea today?

Do not convert weak evidence into certainty.

# 4. Assumption map

List important assumptions under:
- user assumptions;
- problem assumptions;
- solution assumptions;
- data/content assumptions;
- technical assumptions;
- business assumptions;
- distribution assumptions.

Mark each:
- **Known**
- **Likely**
- **Unknown**
- **High-risk unknown**

Validate the highest-risk assumptions first.

# 5. Opportunity comparison

When multiple ideas exist, compare using:

| Factor | Question |
|---|---|
| User pain | Is the problem meaningful? |
| Frequency | How often does it occur? |
| Existing alternatives | How well is it already solved? |
| Differentiation | Is the proposed value distinct? |
| Feasibility | Can a useful version be built? |
| Data dependency | Is required data available/legal/reliable? |
| Maintenance | What ongoing burden exists? |
| Validation speed | Can the key assumption be tested cheaply? |

Do not fabricate numeric scores unless the user requests a scoring model and the inputs support it.

Recommend one direction when possible.

# 6. MVP definition

An MVP is not “version 1 with every expected feature.”

Define:

## Core outcome
What must a user be able to accomplish?

## Smallest complete loop
What is the shortest end-to-end experience that delivers real value?

## Must-have
Only capabilities required for that loop.

## Later
Useful but unnecessary for validation.

## Explicitly not building
Features that create scope without validating the core hypothesis.

Prefer a vertical slice over many incomplete features.

# 7. Validation strategy

Choose the cheapest test that addresses the largest uncertainty.

Examples:
- interview;
- clickable prototype;
- landing page;
- concierge/manual workflow;
- fake-door test where ethical;
- small data prototype;
- technical spike;
- limited beta;
- usability session.

Define:

**Hypothesis**  
**Test**  
**Success signal**  
**Failure signal**  
**Decision after test**

Do not treat sign-ups, clicks, or compliments as proof of long-term value without context.

# 8. Product decision output

A useful discovery output is:

1. Problem
2. Target user
3. Evidence / assumptions
4. Recommended product direction
5. Core value
6. MVP
7. Not now
8. Highest-risk assumption
9. Validation plan
10. What would change the recommendation

Keep it concise unless the user asks for a full discovery document.