Product Strategy

Product Discovery: Methods for Finding What to Build Next

How enterprise product teams decide what to build next — customer interviews, opportunity scoring, validation, and why most discovery is backward.

The Backward Discovery Problem

Most enterprise product teams believe they do product discovery. They interview customers. They run surveys. They attend trade shows and listen to what the market is saying. They compile feature request lists from sales teams and support tickets.

And yet, despite all this effort, their hit rate on new products hovers around the industry average: roughly six out of ten fail to meet business objectives.

The problem is not that these teams skip discovery. The problem is that their discovery process is backward. They start with solutions and work back toward problems. They ask customers “what do you want?” instead of “what are you trying to accomplish?” They catalog feature requests instead of measuring unmet outcomes. They let the loudest voices — whether internal champions or key accounts — set the agenda.

Effective product discovery does the opposite. It starts with a rigorous understanding of the customer’s job to be done, identifies measurable desired outcomes, quantifies which outcomes are most underserved, and only then moves to solution development. This approach is not faster or easier than traditional discovery. But it is dramatically more reliable.

In this article, we will walk through the methods that actually work for enterprise product discovery — and why most of the popular alternatives produce comfortable-feeling results with poor predictive value.


What Product Discovery Must Answer

Before comparing methods, let us define what effective product discovery should produce. Any discovery process worth its time investment should answer five questions:

  1. What job is the customer trying to get done? (not what product do they want, but what outcome are they trying to achieve)
  2. What are all the desired outcomes within that job? (typically 50-150 measurable outcomes per job)
  3. Which outcomes are most underserved? (high importance, low satisfaction)
  4. Are there distinct customer segments with different patterns of unmet needs? (segment discovery)
  5. What is the size and value of the opportunity? (how many customers share these unmet needs, and what would they pay to have them addressed)

If your discovery process does not answer all five, you are making product decisions with incomplete information.


Customer Interviews (Qualitative)

Customer interviews are the default discovery method for most product teams. A product manager visits five to fifteen customers, asks about their pain points, takes notes, and returns with a set of insights.

What interviews do well: They generate empathy. They reveal context that surveys miss. They uncover stories and workarounds that can inspire creative solutions. They build relationships with key customers.

What interviews miss: With typical sample sizes of 5-15 customers, interviews cannot tell you whether a pain point is shared by 5% or 95% of the market. They are subject to selection bias (you interview customers you have access to, not a representative sample). They are heavily influenced by recency bias (customers describe their most recent frustration, not their most important unmet need). And when you ask customers what they want, they describe solutions — usually incremental improvements to what they already have.

For guidance on conducting effective JTBD interviews, see our JTBD interview guide.

Info

Qualitative interviews are invaluable for building job maps and identifying desired outcomes. They are insufficient for prioritizing those outcomes. Use interviews to discover what outcomes exist; use quantitative surveys to measure which ones are most underserved.

Voice of the Customer (VoC) Programs

Many enterprises run ongoing VoC programs that aggregate feedback from surveys, support tickets, NPS scores, and sales team input. These programs produce dashboards and reports that feel comprehensive.

The fundamental issue: VoC programs measure satisfaction with your current product, not the importance of unmet outcomes. A customer who gives your product an NPS of 8 might still have critical unmet needs — they just evaluate your product as the least bad option available. Conversely, a customer with an NPS of 3 might have complaints that are real but low-importance in the context of their overall job.

VoC tells you how you are performing. It does not tell you where the market opportunity lies.

Competitive Benchmarking

Product teams spend significant time analyzing competitor products: feature comparisons, pricing analysis, trade show observations, reverse engineering. The logic is straightforward — if a competitor launches a feature, it must be important.

The trap: Competitive benchmarking tells you what your competitors decided to build. It tells you nothing about whether those decisions were correct. Following competitors guarantees you will always be a follower, competing on dimensions of value they chose. The most valuable innovation opportunities — by definition — are the ones no competitor has addressed yet.

Data Analytics and Usage Patterns

For companies with connected products or digital platforms, usage data reveals how customers actually interact with products. Which features are used most? Where do workflows break down? What workarounds do users create?

The limitation: Usage data reflects how customers interact with your existing product. It cannot tell you about outcomes they care about but cannot achieve with current tools. The most important unmet needs, by definition, are not reflected in usage data because customers have no way to pursue them with your product.

Design Sprints and Ideation Workshops

Design sprints (Jake Knapp’s five-day process) and ideation workshops are popular methods for generating solution concepts. They bring cross-functional teams together to empathize with users, define problems, and prototype solutions.

The gap: These methods are solution-generation tools, not opportunity-identification tools. They work best when the problem is already well-defined. Without quantitative data on which outcomes are most underserved, design sprints often produce creative solutions to low-priority problems — solutions that are impressive in the room but irrelevant in the market.


The Outcome-Driven Discovery Process

Outcome-Driven Innovation flips the discovery process. Instead of starting with solutions and looking for problems they might solve, it starts with a complete map of the customer’s job and systematically identifies where the biggest outcome gaps exist.

Step 1: Define the Job to Be Done

The job is the functional task the customer is trying to accomplish, stated in a way that is solution-agnostic and stable over time.

Examples:

  • “Apply protective coating to automotive components” (for a coating equipment manufacturer)
  • “Manage patient fluid balance during surgery” (for a medical device company)
  • “Prepare soil for planting” (for an agricultural equipment manufacturer)

The job should be defined at a level that is broad enough to capture the full scope of what the customer is trying to accomplish, but specific enough to be researchable.

Step 2: Map the Job Into Steps

Every job follows a process that can be mapped into discrete steps. A typical job map has 8-12 steps, following a universal structure:

  1. Define what needs to be done
  2. Locate necessary inputs
  3. Prepare inputs and the environment
  4. Confirm readiness
  5. Execute the core task
  6. Monitor execution
  7. Make adjustments
  8. Conclude the task

For each step, the research team identifies the desired outcomes — the measurable results the customer is trying to achieve.

Step 3: Develop Outcome Statements

Outcome statements follow a specific format: Direction of improvement + metric + object of control + contextual clarifier.

Examples:

  • “Minimize the time it takes to switch between coating formulations”
  • “Minimize the likelihood that coating thickness varies across complex geometries”
  • “Minimize the volume of material wasted during changeovers”

A comprehensive study typically produces 50-150 outcome statements per job. These statements are the atomic units of customer need — measurable, solution-agnostic, and stable over time.

Step 4: Quantitative Research

This is where ODI diverges from all other discovery methods. Each outcome is measured quantitatively using a survey of 180+ respondents (per segment being studied). For each outcome, respondents rate:

  • Importance: How important is this outcome when performing the job? (1-10 scale)
  • Satisfaction: How satisfied are you with your ability to achieve this outcome today? (1-10 scale)

Step 5: Calculate Opportunity Scores

The opportunity score formula — Importance + max(Importance - Satisfaction, 0) — produces a prioritized list of outcomes. Scores above 12 indicate significant unmet needs. Scores above 15 indicate extreme unmet needs.

This list is the core output of discovery. It tells you, with quantitative precision, which customer outcomes are most underserved and therefore represent the highest-value product opportunities.

In twenty years of product strategy work, I have never seen an enterprise team that could intuitively predict which outcomes would score highest. The data always surprises them — and that surprise is the whole point. If your discovery process only confirms what you already believed, it is not discovery. It is confirmation bias with a research budget.

Martin Pattera

Step 6: Discover Segments

Factor analysis and cluster analysis on the outcome data often reveal distinct customer segments — groups who share similar patterns of unmet needs. These segments are defined not by demographics or firmographics, but by the outcomes they find most underserved.

This is a critical finding for product strategy. A “one-size-fits-all” product strategy fails when segments have fundamentally different patterns of unmet needs. Conversely, segments that look demographically different but share the same unmet outcomes can be addressed by a single product initiative. For a detailed comparison of this approach against traditional persona-based methods, see JTBD vs. personas.


Why Most Discovery Processes Are Backward

The fundamental error in traditional discovery is starting with solutions.

Consider the typical process at an industrial equipment manufacturer:

  1. Engineering develops a new sensor technology
  2. The product team asks: “What could we do with this technology?”
  3. Customer interviews are conducted to find applications for the technology
  4. A product concept is developed and presented to customers for feedback
  5. Positive feedback is interpreted as validation

At every step, the process is solution-forward. The technology comes first; the customer need is reverse-engineered to justify it.

Now consider the ODI approach:

  1. The product team maps the job “operate and maintain conveyor systems in mining operations”
  2. Quantitative research identifies the top unmet outcomes: “Minimize unplanned downtime caused by bearing failure” (opportunity score: 15.4)
  3. The team evaluates multiple possible solutions — including the new sensor technology, but also predictive maintenance algorithms, improved bearing materials, and redesigned lubrication systems
  4. The solution that best addresses the highest-opportunity outcomes is selected for development
  5. Concept testing measures how well the proposed solution satisfies the target outcomes

The difference is not subtle. In the first process, the technology is the answer and the team is searching for a question. In the second, the customer outcome is the question and the team is searching for the best answer.


Integrating Discovery Methods: A Practical Framework

The most effective enterprise discovery process uses multiple methods in sequence, each contributing what it does best:

Phase 1: Qualitative Exploration (2-3 weeks)

  • Method: In-depth interviews with 15-25 job executors
  • Purpose: Build the job map, identify desired outcomes, understand context and language
  • Output: Complete job map, draft outcome statements, initial segment hypotheses

Phase 2: Quantitative Prioritization (3-5 weeks)

  • Method: Survey of 180+ respondents measuring importance and satisfaction for all outcomes
  • Purpose: Calculate opportunity scores, identify segments, quantify market opportunity
  • Output: Prioritized opportunity landscape, segment profiles, market sizing

Phase 3: Concept Development (2-4 weeks)

  • Method: Design Thinking workshops and concept ideation, focused on highest-opportunity outcomes
  • Purpose: Generate creative solution concepts that address the most underserved outcomes
  • Output: 3-5 concept directions with clear linkage to target outcomes

Phase 4: Concept Validation (2-3 weeks)

  • Method: Concept testing against target outcomes, using surveys or structured interviews
  • Purpose: Measure how well proposed concepts satisfy the target outcomes compared to current solutions
  • Output: Validated concepts with quantitative improvement scores

This integrated approach typically takes 9-15 weeks. It is faster than most enterprise discovery processes (which can take 6-12 months) because it eliminates the iterative loops of building and testing concepts without knowing which outcomes to target.


Common Discovery Mistakes and How to Fix Them

Mistake 1: Interviewing Only Friendly Customers

Product teams naturally gravitate toward customers with whom they have good relationships. These customers are easy to access, willing to participate, and generally positive about the product.

The problem: friendly customers are rarely representative of the broader market. They may have adapted their workflow to your product’s limitations, accepted workarounds that dissatisfied customers would not, or simply be too polite to voice their most critical unmet needs.

Fix: Ensure your qualitative interviews include non-customers, former customers, and customers who use competitor products. For quantitative surveys, use a panel or customer list that represents the full market, not just your installed base.

Mistake 2: Asking Customers What They Want

When you ask customers “what features would you like to see?”, you get a feature list. When you ask “what problems do you have?”, you get a solution framed as a problem (“I need a faster drill” instead of “I need to make holes in concrete walls quickly and accurately”).

Fix: Ask about outcomes, not solutions. “When you are operating the coating equipment, what are you trying to accomplish? What does success look like? What makes the difference between a good day and a bad day?”

Mistake 3: Treating All Feedback Equally

Not all customer feedback has equal strategic value. A complaint about a minor usability issue carries the same weight in most feedback systems as a report of a critical unmet functional need.

Fix: Use opportunity scores to weight feedback by strategic value. An outcome with an opportunity score of 15 is significantly more valuable than one with a score of 9 — even if more customers mention the lower-scored issue.

Mistake 4: Skipping Quantitative Validation

Qualitative insights feel compelling — a vivid customer story about a product failure is more emotionally persuasive than a bar chart of satisfaction scores. But vivid stories can be outliers.

Fix: Always validate qualitative findings with quantitative research. If an interview uncovers what seems like a major unmet need, confirm it with a survey. If fewer than 30% of the market rates it as important, it may be a niche need rather than a strategic opportunity.

Mistake 5: One-Time Discovery Instead of Continuous Learning

Many enterprises treat product discovery as a project — conduct research once, then execute for two years. Markets evolve. Competitor launches change the satisfaction landscape. New technologies create new possible solutions.

Fix: Build a standing outcome database that is updated with fresh quantitative data at least annually. This turns discovery from a project into a capability. How those insights then feed into a living roadmap is covered in the article on customer insights and the product roadmap.

Transform Your Product Discovery Process

Book a complimentary discovery call to explore how these ideas apply to your organization.

Schedule a Discovery Call

Frequently Asked Questions

Product discovery answers the question “what should we build and for whom?” Product development answers the question “how do we build it?” Discovery comes first — it identifies which customer outcomes are most underserved and therefore represent the best opportunities. Development then creates solutions to address those specific outcomes. The most common mistake is merging these two activities, which leads to teams building features without validating that they address important unmet needs. Effective discovery should produce a clear, quantitatively prioritized list of target outcomes before any development begins.
For qualitative exploration (building job maps and identifying outcome statements), 15-25 in-depth interviews are typically sufficient to reach saturation — the point where new interviews stop revealing new outcomes. For quantitative validation (measuring importance and satisfaction), you need a statistically significant sample: at least 180 respondents per segment. The qualitative phase tells you what outcomes exist; the quantitative phase tells you which ones are most underserved. Skipping either phase produces an incomplete picture.
Yes, and it is arguably more important in regulated industries because the cost of building the wrong product is so high. The discovery process itself is unaffected by regulation — you are researching customer needs, not testing medical devices. A JTBD study for a surgical instrument manufacturer follows the same process as one for a consumer electronics company. The regulatory constraints apply to the development and validation phases that come after discovery. In our work with medical device clients such as B.Braun and Teleflex, the ODI discovery process fits comfortably within existing regulatory frameworks.
In B2B contexts, different stakeholders (users, buyers, decision-makers, influencers) often have different and sometimes conflicting needs. This is not a problem to solve — it is information to capture. Effective discovery maps the jobs of each stakeholder separately. A surgeon’s job when performing a procedure is different from a hospital administrator’s job when managing costs. Each produces its own set of outcomes and opportunity scores. Product strategy then involves deciding which stakeholder’s outcomes to prioritize, based on their influence on the purchase decision and the size of the unmet opportunity.
The ROI of structured product discovery is best measured by what it prevents: investing millions in product development that targets the wrong customer outcomes. In enterprise contexts, a single failed product line can cost EUR 10-50 million in development costs plus years of opportunity cost. A comprehensive ODI-based discovery process typically costs EUR 100,000-300,000 and takes 10-16 weeks. If it prevents even one major product failure — or redirects development toward a higher-value opportunity — the return is 50-100x the investment. published ODI data shows an 86% success rate for ODI-developed products, compared to roughly 17% for traditional approaches.
Martin Pattera
Written by

Martin Pattera

Martin helps leadership teams build innovation capabilities and navigate strategic transformation. With experience spanning Fortune 500s and high-growth startups, he brings a practitioner's lens to strategy consulting.