product-discovery

# Product Discovery
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.

<!-- dual-compat-start -->
## Use When

- Evaluating a new product idea or market opportunity.
- De-risking a major feature before it enters the backlog.
- Deciding whether to pivot or persevere on an existing product direction.
- Running a time-boxed discovery sprint with a cross-functional team.

## Do Not Use When

- The work is already defined at feature level and only needs implementation sequencing.
- The request is a narrow screen-level UX refinement with no product-risk question.

## Required Inputs

- Business objective, target market, and the product or feature idea under review.
- Available research, usage data, constraints, and stakeholder context.

## Workflow

- Read this `SKILL.md` first, then load only the referenced deep-dive files that are necessary for the task.
- Use the four risks to decide what needs evidence, then choose the cheapest prototype or test that can answer the risk.
- End with a concrete recommendation and the evidence supporting it.
- For premium products, test willingness to pay, proof threshold, perceived quality, decision process, and buyer commitment before treating positive feedback as demand.

## Quality Standards

- Discovery must produce decisions, not theater.
- Success metrics must be defined before deeper investment.
- Prototype fidelity should stay as low as possible while still answering the risk question.

## Anti-Patterns

- Treating output volume as discovery progress.
- Asking customers about hypothetical future preferences instead of present behavior.
- Using colleagues or stakeholders as stand-ins for target users without recording the limitation.

## Outputs

- Opportunity assessment, discovery brief, test plan, prototype recommendation, evidence summary, and build / pivot / kill recommendation.

## References

- Use `enterprise-ux-process` when the work has enterprise constraints, stakeholder churn, or requirement ambiguity.
<!-- dual-compat-end -->

Based on Cagan (2017) *INSPIRED: How to Create Tech Products Customers Love*, 2nd ed.

## The 4 Product Risks

Every product must clear four risks before full delivery investment:

| Risk | Question | Validated By |
|------|----------|-------------|
| Value | Will customers choose to use or buy this? | Demand tests, interviews |
| Usability | Can customers figure out how to use it? | Prototype testing |
| Feasibility | Can we build it with our team, tech, and time? | Engineering spike |
| Business Viability | Does it work for the business? | Stakeholder review |

For premium offers, add a fifth commercial proof question: will the right buyer pay a premium now, and what proof, risk reduction, service layer, or authority asset is required for that decision?

## Opportunity Assessment

Before committing to deeper discovery, capture:

1. Business objective
2. Key results
3. Customer problem
4. Target market

If these are unclear, the opportunity is not ready.

## Customer Discovery Rules

- Ask about current behavior, not speculative future wishes.
- Keep the target market narrow.
- Recruit real reference customers early when possible.
- Use prototypes and manual concierge work before large build commitments.

## Prototype Selection

Choose the cheapest prototype that answers the risk:

| Prototype Type | Best For |
|---|---|
| Feasibility prototype | Technical uncertainty |
| User prototype | Usability and task flow |
| Live-data prototype | Value and workflow realism |
| Hybrid prototype | Mixed risk across value, usability, and feasibility |

## Discovery Sprint

Run a 1-2 week cycle:

1. Frame the opportunity.
2. Interview target users.
3. Prototype 2-3 directions.
4. Test with real users.
5. Make a build / pivot / kill recommendation.

## Companion Skills

- `enterprise-ux-process` for feature-definition inside enterprise delivery environments.
- `feature-planning` once the opportunity passes discovery.
---

## ARRIVE: separating Research from Reframe

Many discovery processes collapse "research" and "synthesis" into one phase, which is exactly the failure mode that produces decks nobody acts on. The ARRIVE framework treats them as distinct stages — Research is ethnographic gathering, Reframe is the deliberate scope-and-meaning shift that names what to build against.

Load `references/arrive-framework.md` for:

- The two-R front end (Research, then Reframe — never collapsed).
- The Persona Needs Matrix and the Reframed Project Vision template that locks in scope.
- The Concept Board (A) for low-fidelity concepts that test the *idea*, not the polish.
- The Assumption Map (importance × evidence) that prioritises which assumptions to validate first.
- Strategic Suitability as a fourth dimension alongside Desirability/Viability/Feasibility.

Use ARRIVE's Reframe stage as a hard checkpoint: the client signs off on the new frame before any concept work begins. Without that gate, ideation becomes unanchored.