Product Discovery: How to Validate Ideas Before You Build Them

Most features fail to deliver the impact teams expect, and many barely get used at all. Product discovery is the work of reducing that waste: understanding customer problems deeply and testing ideas cheaply before investing engineering time. It's how teams learn what's worth building.

#Key takeaways

• Discovery reduces four risks: value (will they want it?), usability (can they use it?), feasibility (can we build it?) and viability (does it work for the business?).
• Good customer interviews ask about past behavior, not hypothetical opinions.
• Frame work as opportunities (customer needs and pains) before jumping to solutions.
• Test the riskiest assumptions with the cheapest experiment that gives a credible signal.
• Make discovery continuous: small, regular touchpoints with customers every week.

#The four risks

Product leaders often describe discovery as addressing four risks:

Discovery is a team sport: PM, designer and a tech lead working together (the "product trio"), not a PM gathering requirements alone (what does a product manager do).

#Customer interviews that actually work

The most common discovery mistake is asking customers what they want, or whether they'd use your idea. People are poor predictors of their own future behavior and tend to be polite. Instead, learn about what they've actually done.

#Principles

• Ask about specific past events: "Tell me about the last time you prepared a client report."
• Dig into behavior and context: what they did, which tools they used, what was frustrating, what it cost them in time or money.
• Don't pitch your idea during problem interviews. It biases everything after.
• Look for evidence of pain: workarounds, spreadsheets, money spent, time lost, emotional language.
• Listen more than you talk.

#Good vs bad questions

(Rob Fitzpatrick's book The Mom Test is a popular, practical guide to this style of interviewing.)

#Synthesis

After each interview, capture a short interview snapshot: who they are, key quotes, pains, current solutions, and opportunities you noticed. Look for patterns across interviews. One loud customer isn't a market.

#Jobs to be done

Jobs-to-be-done (JTBD) framing focuses on the progress a customer is trying to make in a situation:

When [situation], I want to [motivation], so I can [expected outcome].

"When I'm preparing for a quarterly review with a client, I want to show the results of our campaigns in one place, so I can prove our value and keep the account."

JTBD shifts attention from features to outcomes and reveals your real competition, which is often spreadsheets, email, an intern or doing nothing.

#Opportunity solution trees

A useful structure (popularized by Teresa Torres) connects a desired outcome to customer opportunities (needs, pains, desires), then to possible solutions, then to experiments:

textOutcome: Increase activation of new teams
├─ Opportunity: "I don't know where to start"
│   ├─ Solution: Template gallery ─▶ Experiment: fake-door test on templates
│   └─ Solution: Guided checklist ─▶ Experiment: prototype test with 5 users
└─ Opportunity: "My team won't adopt another tool"
    ├─ Solution: Slack integration ─▶ Experiment: concierge notifications
    └─ Solution: Invite-by-link     ─▶ Experiment: A/B test on invite flow

The tree keeps the team focused on the outcome, makes alternatives visible, and prevents falling in love with the first idea (product metrics that matter).

#Assumption testing

Every solution rests on assumptions. Map them, then test the riskiest and least-proven first:

1. List assumptions across value, usability, feasibility and viability.
2. Prioritize by importance (if wrong, does it kill the idea?) and evidence (how much do we know?).
3. Design the cheapest test that could change your mind.

#Experiment toolbox

Define success criteria before running each test, just like an MVP (how to build an MVP).

#Continuous discovery habits

Discovery shouldn't be a phase that happens once a year. Healthy teams:

• Talk to customers every week (even two or three short conversations).
• Automate recruiting: in-app prompts, a customer panel, support and sales handoffs.
• Share learnings openly with engineering and design, and keep a searchable research repository.
• Mix qualitative and quantitative: interviews reveal why; analytics reveal how much.
• Revisit the opportunity tree as evidence accumulates.

#Discovery and delivery together

Discovery and delivery run in parallel, not in sequence. While engineers build validated ideas, the trio explores the next opportunities. Engineers who hear customers directly make better decisions about scope and trade-offs (how PMs and engineers work well together).

#Common pitfalls

• Validation theater: running interviews to confirm a decision already made.
• Talking only to power users or friendly customers, which skews the sample.
• Treating feature requests as requirements instead of clues to underlying problems.
• Over-researching low-risk, reversible decisions. Just ship and measure.
• No decision criteria, so every result gets rationalized.

#FAQ

#How many customer interviews are enough?

Keep going until you stop hearing new patterns for a given segment and question. That's often five to ten interviews for a focused topic. Continuous discovery means you never fully stop.

#What's the difference between product discovery and user research?

User research is a set of methods for understanding users. Product discovery is the broader process of deciding what to build, which uses research alongside data analysis, experiments, technical exploration and business analysis.

#How do I do discovery with limited time?

Keep it small and regular: a couple of short interviews weekly, quick prototype tests, and fake-door experiments. Focus effort on the riskiest assumptions of the biggest bets.

#Can AI help with product discovery?

AI can help transcribe and summarize interviews, cluster feedback themes and generate test variants. It can't replace talking to customers or judging which evidence matters, and summaries should be checked against the source material.