Product Discovery

---
name: product-discovery
description: "Helps teams rapidly validate product ideas and de-risk decisions before coding by using experiments, prototyping, and customer interviews."
metadata:
  tags: "business-growth, product-management, product-discovery, idea-validation, rapid-prototyping, customer-interviews, fake-door-tests"
  source: "https://skilldb.dev/skills/product-management-skills/product-discovery"
  pack: "product-management-skills"
  category: "Business & Growth"
---

# Product Discovery

## When to use this skill
Use when the user says things like:
- "I want to validate a product idea quickly."
- "How can we de-risk before coding a feature?"
- "Help me design experiments to test a concept."
- "I need customer interviews to understand the problem."
- "What’s the fastest way to learn if this is worth building?"


## Core Philosophy
Product discovery is the process of reducing four key risks before building:
value risk (will customers want it?), usability risk (can they use it?), feasibility
risk (can we build it?), and business viability risk (does it work for the business?).
Discovery separates deciding what to build from building it, ensuring that
engineering effort is invested in validated ideas rather than untested assumptions.
The cheapest way to learn is before writing code.

## Key Techniques
- **Assumption Mapping**: List every assumption underlying a product idea, rank
  them by risk and importance, and design experiments to test the most critical
  ones first.
- **Rapid Prototyping**: Build lightweight prototypes (paper, Figma, coded
  prototypes) that test specific hypotheses without full engineering investment.
- **Fake Door Tests**: Place a feature entry point in the product that measures
  interest (clicks) before building the feature behind it.
- **Concierge MVP**: Deliver the proposed value manually to a small number of
  customers to validate demand before automating with technology.
- **Customer Problem Interviews**: Structured conversations focused on understanding
  the customer's problem and current workarounds, conducted before proposing
  any solution.
- **Sprint-Based Discovery**: Time-boxed discovery cycles (1-2 weeks) that produce
  evidence for or against proceeding with an initiative.

## Best Practices
- Frame discovery around risks, not features. The question is not "should we build
  X?" but "what do we need to learn before deciding?"
- Set clear success criteria for each experiment before running it. Decide in
  advance what evidence would change your mind.
- Involve engineering in discovery from the start. Feasibility insight shapes
  which solutions are worth testing.
- Run multiple small experiments rather than one large one. Each experiment
  should answer a single focused question.
- Accept that most ideas will not survive discovery. A high kill rate is a sign
  of effective discovery, not failure.
- Time-box discovery to prevent analysis paralysis. Perfect evidence does not
  exist; sufficient evidence does.

## Common Patterns
- **Dual-Track Agile**: Run discovery work in parallel with delivery work so
  there is always a pipeline of validated ideas ready for engineering.
- **Opportunity Solution Tree**: Map desired outcomes to opportunities (user needs)
  to solutions to experiments, creating a visual logic chain for product decisions.
- **Design Sprint**: A structured five-day process for rapidly prototyping and
  testing ideas with users, popularized by Google Ventures.
- **Wizard of Oz**: Present what appears to be a working product to users while
  actually performing the back-end work manually, testing the interface and
  value proposition before building the technology.

## Anti-Patterns
- Skipping discovery and going straight to building because the team is "confident"
  in the idea. Confidence without evidence is the most common source of waste.
- Discovery theater — going through the motions without genuine openness to
  learning that the idea is wrong.
- Over-investing in discovery for low-risk ideas. Not every feature needs
  extensive validation; reserve deep discovery for high-stakes bets.
- Testing solutions without validating the problem first. A beautiful solution
  to a problem nobody has is still a waste.
- Treating discovery as a one-time phase rather than a continuous practice
  integrated into the team's weekly rhythm.
- Ignoring qualitative signals because they are not statistically significant.
  Five users struggling with the same task is a strong signal.