Product discovery

Product discovery is the process of determining what to build. It's the work that happens before and alongside development to ensure teams build products that customers want, that work for the business, and that are technically feasible. Discovery involves understanding user needs, testing assumptions, exploring solutions, and validating ideas - all aimed at reducing the risk that significant development effort produces something nobody wants.

Why it matters

Development is expensive. Building, testing, deploying, and maintaining features requires substantial investment. If that investment goes toward features users don't want or need, it's largely wasted.

Discovery reduces this risk by front-loading learning. Teams validate assumptions before committing to full builds. Small experiments reveal what works before large investments. Customer input shapes products early, when change is cheap, rather than late, when it's expensive.

The alternative - shipping whatever seems like a good idea and hoping for the best - produces high failure rates. Studies consistently show that most new features fail to move target metrics. Discovery improves these odds.

Discovery vs. delivery

Product work divides into discovery (figuring out what to build) and delivery (building it).

Discovery is generative and exploratory. It asks: What should we build? For whom? Why? Does this solution actually solve the problem? It emphasizes learning and reducing uncertainty.

Delivery is convergent and executional. It asks: How do we build this well? How do we ship it reliably? It emphasizes quality and efficiency.

Both are necessary. Discovery without delivery produces ideas but no products. Delivery without discovery produces products but often the wrong ones.

In waterfall approaches, discovery (in the form of requirements gathering) happened once, upfront. Agile approaches integrate discovery and delivery, with ongoing learning informing ongoing development.

Discovery activities

Discovery encompasses various activities depending on what needs to be learned.

User research includes interviews, observations, and surveys that reveal user needs, behaviors, and contexts. Research builds understanding of the problem space.

Problem framing articulates what problem you're solving, for whom, and why it matters. Clear problem definition is foundational - solutions to non-problems or wrong problems fail regardless of execution.

Opportunity identification explores where value might be created. What user needs are unmet? What pain points could be alleviated? What gains could be enabled?

Ideation generates possible solutions. Brainstorming, design studios, and creative exercises produce options to explore.

Prototyping creates low-fidelity representations of solutions. Paper prototypes, wireframes, and clickable mockups allow testing without full development.

Usability testing validates whether users can accomplish tasks with proposed designs. Observation of users attempting to use prototypes reveals problems and opportunities.

Experimentation tests hypotheses about what will work. A/B tests, fake door tests, and concierge experiments provide evidence before full builds.

Continuous discovery

Modern product practice emphasizes continuous discovery - ongoing, regular discovery activities rather than periodic research phases.

Weekly customer touchpoints keep teams connected to user reality. Even a single customer interview per week accumulates significant insight over time.

Regular experimentation tests assumptions as part of normal work. Discovery isn't a separate phase; it's woven into how teams operate.

Cross-functional involvement includes engineering and design in discovery, not just product management. Diverse perspectives improve learning.

Opportunity solution trees structure ongoing discovery, connecting outcomes to opportunities to solutions to experiments.

Continuous discovery contrasts with models where research happens in big phases separated from development. Small, frequent learning beats occasional comprehensive studies.

Discovery techniques

Various techniques serve different discovery needs.

Customer interviews reveal motivations, behaviors, and contexts through open-ended conversation. Good interviews explore problems without leading toward particular solutions.

Observation watches users in their natural context. What people do often differs from what they say they do.

Surveys collect data at scale but sacrifice depth. They're useful for quantifying what qualitative research has identified.

Prototype testing validates specific solution ideas. "Does this design work?" is a discovery question prototype testing can answer.

Fake door tests measure demand before building. Show users a feature that doesn't exist yet; their click rate indicates interest.

Concierge testing delivers value manually before automating. If users pay for a human-powered version, an automated version might succeed.

Wizard of Oz testing appears automated to users but is actually human-powered behind the scenes. It tests whether users want the capability before building it.

Discovery outputs

Discovery produces insights and artifacts that inform development.

Problem statements articulate what needs to be solved clearly enough to guide solution design.

Personas or jobs-to-be-done describe who the product serves and what they're trying to accomplish.

Validated solutions are approaches that evidence suggests will work. They've passed prototype testing and experimentation.

Experiment results document what was learned from tests, successful or not.

Prioritized opportunities rank where to invest based on discovery findings.

Common discovery mistakes

Skipping discovery entirely assumes teams already know what to build. This assumption is usually wrong, producing wasted development.

Confirmation bias uses research to validate existing beliefs rather than genuinely learn. Teams see what they want to see.

Prototype attachment falls in love with a solution before validation. The goal is learning, not defending a favorite design.

Insufficient problem understanding jumps to solutions before truly understanding what's wrong. Solutions to poorly understood problems often miss the mark.

Discovery as a phase treats discovery as something done once, before development. Continuous learning throughout development is more effective.

Discovery and customer feedback

Customer feedback is a discovery resource that's often underutilized. What customers tell you - in support tickets, feature requests, reviews, and surveys - reveals needs, pain points, and opportunities.

Tools like Klero help product teams leverage this resource by aggregating feedback, identifying patterns, and connecting customer input to discovery efforts. When feedback analysis reveals that many customers struggle with the same issue, that's discovery data pointing toward opportunities.