🔍Product Discovery Basics
Discovery is how you decide what to build before you waste a quarter building the wrong thing.
Discovery is the single highest-leverage PM activity. Skipping it is the most common cause of feature factory output, wasted engineering quarters, and PMs who can't articulate why their team's work matters.
Product discovery is the practice of validating four risks — value, usability, feasibility, viability — *before* committing engineering time. The output of discovery is not a feature; it's confidence that you're building the right thing.
The four risks (Cagan)
Every product idea has four ways to fail:
- Value risk — will customers buy/use it? (Most common failure mode.)
- Usability risk — can they figure out how to use it?
- Feasibility risk — can engineering build it within constraints?
- Viability risk — does it work for the business? (Compliant, profitable, on-strategy, sustainable.)
Discovery is the process of de-risking each of these before you spend an engineering quarter on the build. The classic failure: PMs assume value and usability are fine and spend all their discovery time on feasibility — leading to beautifully engineered features no one wants.
The discovery toolkit
- Customer interviews. Highest signal, lowest cost. Aim for 3-5 per week, ongoing.
- Surveys. Lower signal but scalable for quantifying patterns.
- Data analysis. Look at what users are actually doing in the existing product.
- Prototypes. Low-fidelity (paper, Figma) for usability; high-fidelity (clickable, vibe-coded) for value testing.
- Concierge / Wizard of Oz. Manually deliver the value to 5 users and see if they keep coming back.
- Smoke tests. Run a fake landing page or fake button click; measure intent.
- Competitive teardowns. What did Stripe / Notion / Linear do here, and why?
The Teresa Torres framing
Teresa Torres' Continuous Discovery Habits is the most-cited modern playbook. Key ideas:
- Discovery is a habit, not a project. Weekly customer interviews, ongoing.
- The Opportunity Solution Tree. Map every solution back to the customer opportunity it serves, back to the business outcome.
- Assumption testing, not feature testing. Identify the riskiest assumption behind a solution and design the smallest test that validates or invalidates it.
What discovery is NOT
- It's not a single research sprint before development. It's continuous.
- It's not just user interviews. It's a portfolio of techniques.
- It's not "let's run an A/B test." A/B testing is for marginal optimization; discovery is for what to build in the first place.
- It's not the researcher's job. Even if you have a dedicated UX researcher, the PM owns discovery.
Tactical starting point for a new PM
Week 1: schedule 5 customer interviews and 5 internal interviews (sales, support, success). Week 2: do them. Notes in one Notion page per interview. Week 3: synthesize patterns. Write 3-5 "opportunities" — recurring problems you heard. Week 4: pick the biggest opportunity. Design a small test (prototype, smoke test) to validate the value proposition. Week 5-6: run the test, decide whether to commit.
That cycle is the minimum viable discovery practice. Don't skip it.
Key frameworks
Value, usability, feasibility, viability. De-risk each before building.
Map solutions to opportunities to outcomes — and use it to decide what to test next.
Weekly customer touch, ongoing, not a one-off research project.
Real-world examples
Intuit's PMs and engineers visit customers in their homes to watch them use the product. Decades old, still considered one of the gold-standard discovery practices. The lesson: there's no substitute for watching the actual user struggle with your actual product in their actual context.
Early Airbnb used storyboards (Disney-style) to map the host and guest journeys, identify the 'magic moments,' and prioritize what to build. The discovery output wasn't a PRD — it was a story that made the entire team see what experience they were trying to create.
Common pitfalls
- ⚠Skipping discovery because 'we know what to build' — almost always wrong.
- ⚠Treating discovery as a one-time sprint instead of an ongoing habit.
- ⚠Doing only feasibility discovery and assuming value/usability — recipe for wrong products built right.
- ⚠Discovering forever and never deciding — at some point you have to ship and learn.
Go deeper — recommended reading
Interview questions (2)
Q1What is product discovery, in your own words?executionmid▼
Discovery is how a team de-risks an idea before committing engineering time to building it. Specifically, it's the work of validating that there's real customer value, that the design is usable, that engineering can actually build it within constraints, and that it works for the business.
Concretely it looks like: customer interviews, prototype tests, data analysis, smoke tests, sometimes manual concierge versions of the product. The output isn't a feature; it's confidence. A successful discovery cycle ends with you saying 'I'm 80% sure this is worth building' or 'we should kill this idea.'
The best teams do discovery continuously, not as a one-time sprint before development.
Q2How would you do discovery for a feature where leadership has already decided it's going to be built?executionsenior▼
Two-part move.
First, scope the discovery to the things that aren't pre-decided. Even if the feature is mandated, the specifics — which user segment, which workflow, what the success criterion is — usually aren't. Run discovery on the how and the who.
Second, *discover what not to build inside the feature.* A pre-decided feature can still be a 10-week build or a 4-week build depending on which components actually matter. Use discovery to find the 20% of the feature that delivers 80% of the value, and ship that.
If discovery surfaces real evidence the whole feature is a bad idea, that's a separate conversation — but you have to earn the right to that conversation with evidence, not opinions. Run the discovery, get the data, then go back to leadership with 'here's what we learned and here's what I recommend.'