Customer discovery is one of the most misunderstood disciplines in product management. Customer discovery sometimes appears to be simply conversational, but when practiced well, it should be rigorous. A product manager can schedule interviews, ask polite questions, collect quotes, and still learn very little that would change the product. The modern reality is that discovery must uncover the context in which customers struggle, the alternatives they already use, the triggers that make change urgent, and the tradeoffs that determine whether a product becomes part of real work or remains an interesting idea. How are they using the product to implement their workflows?
Jobs-to-Be-Done (JTBD) is useful because instead of asking only who the customer is, the product manager asks what the customer is trying to get done, why the current approach is insufficient, what causes the customer to seek a new solution, and what anxieties make switching difficult. This matters for technical products because buyers and users often describe their needs in terms of features. They may ask for dashboards, integrations, automations, exports, alerts, or AI summaries. Those requests are not meaningless, but they are not the deepest unit of product insight. The deeper question is what progress those requested features would enable, and what is the full context of the customer request for this feature?
A strong discovery interview begins before the call. The product manager should know which assumption is being tested and what kind of evidence would be useful. If the team is trying to understand whether a workflow problem is painful enough to justify a new product investment, the interview should focus on recent behavior rather than abstract opinion. The best questions ask about the last time the problem occurred, what triggered it, who was involved, what workaround was used, what happened when the workaround failed, and what consequences followed. Customers are much better witnesses of recent events when asked carefully.
This is why interview technique matters. Leading questions such as “Would you use a tool that automated this?” usually produce weak evidence because they invite the customer to be agreeable. A better question is “Walk me through the last time this happened.” Another useful prompt is “What did you do next?” followed by “Why did that matter?” and “What made that hard?” The goal is to reconstruct the situation with enough specificity that the product team can see the job, the friction, and the context.
JTBD-driven research also helps product managers avoid the trap of treating all customer feedback equally. A loud request from a large account may deserve attention, but it should not automatically become a roadmap priority. The PM should ask whether the request represents a broader job, whether the pain is recurring, whether the customer has already invested in a workaround, and whether solving it would create value for a target segment rather than only one stakeholder. The same discipline applies to user research in consumer products. A customer saying “I want personalization” is less useful than learning that they abandon a task when choices feel overwhelming, or that they return weekly because a specific recommendation saves time at a predictable moment.
Continuous discovery strengthens this work by making it a habit rather than a phase. The strongest teams maintain a steady stream of customer conversations, feedback synthesis, product analytics reviews, support pattern analysis, and sales call learning. This does not mean every PM needs to spend all week in interviews. It means the team has a reliable cadence for refreshing its understanding of customer reality. Regular customer touchpoints and opportunity mapping help teams connect customer needs to product decisions rather than treating research as a separate function.
The output of discovery should be a practical synthesis that includes the customer’s job, the trigger event, the current workaround, the emotional or economic consequence, the strength of evidence, the affected segment, and the product implication. The synthesis should separate observation from interpretation. As an example, “Three customer success managers export data into spreadsheets every Friday” is an observation. “They need a better dashboard” is an interpretation. The interpretation may be correct, but it should be tested against alternatives such as workflow automation or alerting.
AI tools can help with discovery, but they also raise the standard for PM judgment. LLM’s can summarize transcripts, cluster themes, draft interview guides, and compare feedback across sources. When used properly, these AI tools reduce administrative work and help teams notice patterns faster. When used poorly, they create false confidence by smoothing over minority signals, stripping away customer language, or turning ambiguous evidence into tidy themes. A responsible PM should keep raw quotes traceable, review AI-generated summaries against source material, and avoid treating frequency as the same thing as importance. Human-in-the-loop review at this level is still critical to avoid blindly following an AI-generated summary.
The best discovery cultures are humble and commercially aware. They listen for the job behind the request, the cost of the current workaround, the urgency of the trigger, and the constraints that would shape adoption. They connect what customers say with what customers do, what the business needs, and what the technology can responsibly deliver. When discovery works, the roadmap becomes less of a negotiation over opinions and more of a disciplined portfolio of bets grounded in evidence.
For a technical product manager, customer discovery, interviews, and JTBD-driven research are not soft skills at the edge of the role. They are the front end of product judgment. They determine whether technical effort is aimed at a real problem, whether product strategy is connected to market behavior, and whether the team can explain why a feature should exist before asking engineers to build it.
As an exercise to the reader looking for a practical next step: choose one active product assumption, interview five customers about the last time the relevant problem occurred, synthesize the job and workaround, and decide what evidence should change the roadmap.
REFERENCES
Teresa Torres, Product Talk. https://www.producttalk.org : Reference for continuous discovery habits, opportunity mapping, and customer interview practices.
Silicon Valley Product Group, Continuous Discovery. https://www.svpg.com/continuous-discovery : Reference for ongoing discovery as a core practice in empowered product teams.
Harvard Business School Online, Jobs to Be Done. https://online.hbs.edu/blog/post/jobs-to-be-done-examples : Reference for Jobs-to-Be-Done theory and examples of understanding customer progress.
Product Talk, Ask Teresa: How Do You Select Customers for Customer Interviews? https://www.producttalk.org/selecting-customers-for-customer-interviews : Reference for selecting interview participants and building a practical customer interview cadence.