Product discovery process: customer interviews and validation
Product discovery process in 7 tests: run customer interviews, map assumptions and test ideas cheaply before building, with a hypothetical worked example.
Product discovery is the work of finding out whether an idea is worth building before a team commits to building it. Teresa Torres defines continuous discovery as weekly customer touchpoints by the team building the product, with small research activities aimed at a desired outcome. Marty Cagan frames discovery around four risks: value, usability, feasibility and business viability.
What is product discovery, and how does it differ from delivery?
Product discovery decides what is worth building, and delivery builds it. Cagan of Silicon Valley Product Group names the four risks discovery must reduce: value (whether customers will buy it or users will choose to use it), usability, feasibility and business viability. He says the toughest is usually value risk, that the product manager is responsible for value and viability, and that strong teams tackle the big risks early and work on problems, not features.
Delivery turns a chosen idea into working software. The two overlap in practice, since a team learns during delivery as well, but they ask different questions: discovery asks whether this should be built, and delivery asks how to build it well. Torres says her three requirements for discovery to be continuous are that the team building the product talks to customers directly, that research is small enough to fit alongside coding and design, and that the focus is on outcomes.
Torres wrote in 2021 that she still met product managers every day who had never talked to a customer, or were not allowed to.
How do you run customer interviews?
Interview customers about specific past events, as a team, and on a regular rhythm. Torres defines a story-based interview as one that collects specific accounts of past behaviour instead of opinions or predictions, and recommends that the product trio, a product manager, a designer and a software engineer, interview together, with one person asking and the other two watching and taking notes. Atlassian gives similar advice for requirements work: include a designer and a developer so they hear the customer directly.
The steps below are a practical sequence.
- Decide the outcome the team is working toward, so the interview has a purpose.
- Recruit people who recently did the thing being studied. Torres recommends automating recruiting, for example while customers use the product, through customer-facing teams, or from a customer community.
- Open with the last time: ask the customer to describe the most recent occasion, then follow the story step by step.
- Ask for specifics when answers drift into generalities, and steer back to the actual event.
- Do not pitch the idea. Rob Fitzpatrick's book The Mom Test, a guide to talking to customers and avoiding biased feedback, is widely summarised as three habits: keep the talk on the customer's life rather than the idea, ask about specific past events rather than opinions about the future, and listen more than you talk.
- Write a one-page summary straight after, with quotes and the opportunities heard, so patterns can be found across interviews.
Which interview questions avoid leading the customer?
Questions that ask about a specific past event avoid leading the customer, and questions that ask for opinions or predictions invite polite answers. Product Talk contrasts asking how often someone watches a streaming service with asking about the last time they watched it, and says the specific story reveals the when, where and why that a frequency never shows. The table applies the same idea to a hypothetical food-ordering app; the examples are illustrative.
| Leading or weak question | Why it fails | Better question |
|---|---|---|
| "Would you use an app that reorders for you?" | Asks for a prediction about a product that does not exist | "Tell me about the last time you ordered the same meal twice." |
| "Don't you hate retyping your address?" | Suggests the answer | "Tell me about the last time you entered an address in an app." |
| "How much would you pay for this?" | Hypothetical, and anchors on the idea | "What do you do today when you want the same meal again, and what does that cost you?" |
| "What features do you want?" | Customers describe solutions, not needs | "Tell me about the last order that went wrong." |
How many customer interviews are enough?
There is no single number, and the answer depends on whether the aim is a habit or a finished study. Torres recommends interviewing at least one customer every week and says the habit matters more than the count: one a week beats four in one week and none in the next.
For a single study of one group, qualitative research gives a guide. A 2006 study by Guest, Bunce and Johnson in the journal Field Methods analysed sixty in-depth interviews with women in two West African countries. It found that saturation, the point where no new themes appear, occurred within the first twelve interviews, although basic elements of the main themes were present as early as six.
That sample was a single group in a health study, so the figure is a starting point for a similar group of customers, not a rule. A second customer segment needs its own interviews.
The best-known small number belongs to a different method. Jakob Nielsen's Nielsen Norman Group article of 18 March 2000 recommends testing with no more than five users, since five find about 85% of the usability problems in a design, and running several small tests. That is about usability testing of a design, not discovery interviews, and the two should not be mixed up.
How do you map assumptions and pick a test?
List what must be true for the idea to work, then test the assumptions that are important and have the least evidence. David J. Bland of Strategyzer describes assumptions mapping as a team exercise where desirability, viability and feasibility hypotheses are made explicit and placed on a grid of importance against evidence, using the question of which hypothesis, if proven wrong, would cause the idea to fail. He advises starting with desirability and focusing near-term experiments on the critical beliefs with the least evidence behind them.
Torres groups assumptions into desirability, usability, feasibility, viability and ethical, and says most assumption tests fall into four categories: prototype tests, one-question surveys, data mining and research spikes. In the hypothetical reorder example, the belief that customers reorder the same basket is important and has no evidence, so it is tested first, by checking past orders, which is data mining. The belief that menus stay stable enough for a reorder to work is a feasibility and viability assumption and comes second.
| Test | Risk it addresses | How it works | Limit |
|---|---|---|---|
| Story-based interview | Value: is the problem real? | Customers describe a recent event in detail | Small samples; people recall imperfectly |
| Prototype test | Usability and desirability | Customers react to a simulated experience | A prototype is not real use |
| One-question survey | Past or current behaviour | A short survey about what customers did | Self-reported answers |
| Data mining | Whether behaviour exists | Check existing data for the pattern | Only shows what is already tracked |
| Research spike | Feasibility | Engineers investigate a technical question | Takes engineering time |
| Landing page or pricing page test | Demand and willingness to pay | A page measures sign-ups and plan clicks | Shows interest, not use |
| Concierge test | Value and workflow | A person delivers the service by hand | Does not scale |
Which cheap tests work before building?
Three cheap tests are common before building: a landing page, a concierge service and a prototype. Buffer's founder Joel Gascoigne described the first on 16 February 2011. He tested demand with a two-page site and treated the idea as validated once a few people left an email address and feedback. He then added a pricing page to see which plan people clicked, and only after that built the first version over 7 weeks.
The first paying customer arrived within 4 days of launch. It is one founder's account of one product, and a page can show interest without showing that people will use the product.
The Real Startup Book describes a concierge test as delivering a product's value by hand, as a personal service, to a small number of real customers who know a person is doing the work. For the reorder idea, a support agent could repeat orders for a handful of customers by chat and record what goes wrong. A Wizard of Oz test differs because the customer believes the service is automated.
Prototype tests are the third option, simulating a moment so the team can watch behaviour before engineering builds anything. The Lean Startup site describes the aim of a minimum viable product as starting to learn as quickly as possible once the problem is understood.
How does discovery feed the roadmap?
Discovery supplies the opportunities and the evidence for what appears on a roadmap and in a requirements document. Torres says a date-based roadmap lists solutions already matched to opportunities and vetted by assumption tests, while an outcome-oriented roadmap may also include outcomes the team plans to explore next. The product roadmap guide shows how problem, outcome and confidence appear in a now-next-later format, and the guide to writing a PRD shows where findings go in the problem and assumptions sections.
What are the limits of discovery?
Discovery reduces risk and does not remove it. Interviews are small samples and people recall past events imperfectly. A landing page measures interest, and interest is cheaper than use or payment. Customer conversations also reveal needs better than they reveal solutions: Product Talk notes that a feature request rarely includes the customer's goal, the context of use or the underlying need.
Time and access are a second limit. Torres's weekly rhythm assumes a team that can reach customers, and she wrote in 2021 that some product managers are not allowed to. The frameworks in this area come from practitioners and vendors, such as Product Talk and Strategyzer, and they describe one way of working, not a standard.
Discovery with no decision date can also run indefinitely. A useful rule is to agree in advance what result would change the plan, and to stop testing when it arrives. For the wider process around discovery, see the product management process guide.
Where does discovery fit in a product management programme?
Certificate Programme in Product Management in the Agentic AI Era is a live online programme from IIM Tiruchirappalli (IIM Trichy), run with Masai as the implementation partner, covering product foundations, platform strategy, AI for product managers, agentic AI and a team capstone to design and pitch an agentic-AI-powered product. Its listed topics include product thinking, customer-centric design and experimentation, in modules such as Foundations in Product Management.
Frequently asked questions
What is product discovery?
Product discovery is the work of deciding what is worth building: understanding customer problems, testing ideas and reducing risk before committing engineering time. Teresa Torres defines continuous discovery as weekly touchpoints with customers by the team building the product, running small research activities toward a desired outcome.
How many customer interviews are enough?
Torres recommends at least one a week as a habit. For a single study of one similar group, Guest, Bunce and Johnson found saturation within twelve interviews in a 2006 health study, with main themes visible by six. Treat those as starting points and keep going until new interviews stop producing new themes.
What is the difference between discovery and delivery?
Discovery decides what to build and whether it is worth building, by testing risks such as value and usability. Delivery builds and ships the chosen solution. Cagan says strong teams tackle the biggest risks early and work on problems, not features, so discovery continues during delivery.
What is The Mom Test?
The Mom Test is a book by Rob Fitzpatrick on how to talk to customers and learn whether an idea is good when people are inclined to be polite. Its advice is usually summarised as three habits: talk about the customer's life, ask about specific past events instead of opinions, and listen more than you talk.
What is an assumption map?
An assumption map is a grid, described by David J. Bland of Strategyzer, that ranks a team's hypotheses by importance and by the evidence behind them. Teams test the hypotheses that are critical and have the least evidence first, so effort goes to the beliefs most likely to sink the idea.
Next step
Discovery habits form through repeated practice with real customers and real data. The Certificate Programme in Product Management in the Agentic AI Era page lists the foundations modules that cover product thinking, customer-centric design and experimentation.