Customer discovery: how to keep interviewing customers every week

Most product teams agree they should talk to customers every week, yet most of them stop within a month. Customer discovery is the work of checking, with the people concerned, that a problem is real before you spend months building the answer. The method is well documented. What wears teams down is the logistics: finding someone every week, fitting the call into two calendars, running it and writing it up. This page covers the method, fifteen questions that keep people on facts, and our fix: an asynchronous interview that each customer answers when it suits them, so nobody has to book a slot.

What customer discovery is

Customer discovery is the stage where a team tests its assumptions about a customer’s problem by talking to the people who have it, before building the solution. It differs from market research, which sizes a market, and from user testing, which evaluates a product that already exists. Its output is evidence: who has the problem, how often, and what they already do about it.

Steve Blank, the entrepreneur and Stanford lecturer who coined the term in The Four Steps to the Epiphany (2005), summed it up as “get out of the building”. Inside your office, what you know about customers stays an opinion until customers confirm it.

The term has since spread beyond startups. Product teams inside established companies use “product discovery” for the same activity, applied to the next feature rather than to a whole company.

The four phases of customer discovery

In Blank’s customer development model, discovery is the first of four steps: customer discovery, customer validation, customer creation, then company building. A startup searches for its business model during discovery and validation, then executes it during creation and company building. When validation fails, you go back to discovery with what you learned rather than pushing on.

graph TD
  A["Customer discovery: does the problem exist, and for whom?"] --> B["Customer validation: can we sell the solution again and again?"]
  B -->|"No, the model does not repeat"| A
  B -->|"Yes"| C["Customer creation: build demand"]
  C --> D["Company building: organise to execute"]

Discovery itself runs in four phases in Blank’s book. They are the ones people usually mean when they ask about “the four phases of customer discovery”.

Phase	What you do	What you come out with
1. State your hypotheses	Write down who the customer is, what problem they have and how they deal with it today	A short list of claims you can check one by one
2. Test the problem	Interview people about how they experience the problem, without showing them your idea	Confirmation that the problem exists, how often it occurs and what it costs
3. Test the product concept	Show the solution to people who confirmed the problem, and watch their reaction	A read on whether your answer fits the problem they described
4. Verify	Review what phases 2 and 3 taught you and decide	Carry on to validation, adjust the hypotheses, or start over

Most of the interviews happen in phase 2, which teams skip more often than any other. Showing a prototype feels productive. Listening to someone describe a problem without mentioning your solution feels slow, yet you only find out in this phase whether the prototype is worth showing.

Continuous discovery: why a weekly interview works better than a quarterly study

Teresa Torres, a product discovery coach and the author of Continuous Discovery Habits (2021), moved the idea from the startup to the product team. She defines continuous discovery as “at a minimum, weekly touchpoints with customers by the team building the product, where they conduct small research activities in pursuit of a desired product outcome”.

In practice, that means an interview every week. The product manager, the designer and an engineer run it themselves, instead of waiting for a report from a research team. A thirty-minute conversation already counts as a research activity.

Weekly matters because product decisions happen every day, in a planning meeting, in a design review, in a Slack thread. A quarterly study answers the questions the team had three months ago. In the meantime, every decision relied on memory and opinion. With one interview a week, whoever has to decide can point to what a customer said last Tuesday.

Torres also asks for story-based interviews. Rather than asking people what they want, you ask them to tell you about a specific time they ran into the problem.

15 customer discovery questions that avoid the Mom Test traps

Rob Fitzpatrick, a founder and the author of The Mom Test (2013), named the book after the only kind of question your mother cannot lie to you about. His three rules fit on one line: talk about the customer’s life instead of your idea, ask about specific past events instead of opinions about the future, and talk less than the customer does.

Everyone likes answering “would you use an app that did X?”, but you learn almost nothing from the answer. People want to be kind to you and overrate what they will do later. The past is harder to embellish: it happened or it did not, it took two hours or ten minutes.

The fifteen questions below follow those rules. Pick the ones that fit your topic, and plan a follow-up for each one.

Context

1. Walk me through your role and what a normal week looks like.
2. Which part of that week takes more time than it should?
3. Who else is involved when that part goes wrong?

The last time it happened

4. Tell me about the last time you had to deal with this. When was it?
5. What were you doing just before, and what triggered it?
6. What did you do, step by step?
7. How long did it take you, all things considered?
8. How did it end?

What they already do about it

9. What have you tried so far to make it easier?
10. What did you drop along the way, and why?
11. Do you use anything on the side for this, a spreadsheet, a script, a colleague?
12. What does it cost you today, in time or in money?

Closing

13. If you could change one thing about how this works, what would it be?
14. Who else should I talk to about this?
15. What should I have asked you that I did not?

Ask what people use on the side (a spreadsheet, a script, a colleague): you usually learn the most from that question. People keep a workaround going for months only when the problem hurts enough. By then they have usually stopped mentioning the problem to anyone, so you only hear about it if you ask. Ask what the problem costs them today instead of “how much would you pay”, which Fitzpatrick lists among the questions that produce compliments. People know what the problem already costs them, so they answer from experience.

If you need more, pick from 45 open-ended questions sorted by research goal. To order your questions over a whole session, structure an interview guide.

Why teams stop after three weeks

Take a product trio (a product manager, a designer and an engineer) committed to one interview a week. The first week goes well because someone already had a customer in mind. The second week, the product manager emails ten customers, three reply, and one books a slot. By the third week, the slot moves twice, the engineer drops out of the call to fix a production incident, and the notes stay in a notebook no one else reads. The fourth week, nobody sends the emails.

Every interview goes through four steps that cost time every week:

Step	What it takes each week	Why it slips
Recruiting	Finding and emailing people until one says yes	The reply rate drops as you exhaust your warm contacts
Scheduling	Matching two or three calendars with the customer’s	A single meeting that moves pushes the interview into next week
Running	30 to 60 minutes of the whole trio’s time	The first urgent task of the day takes priority
Writing up	Turning notes into something the rest of the team can read	Nobody owns it, so it happens days later or never

Torres identifies recruiting as the biggest obstacle. Her answer is to automate recruiting: a prompt inside the product, colleagues from sales or support who refer customers, or a customer panel. Her goal is for the team to wake up on Monday with an interview already booked, without anyone having to do anything that week.

That solves recruiting. Scheduling, running and writing up still take hours of the team’s time every week.

Running discovery interviews asynchronously

With an asynchronous interview, the team skips scheduling, running and writing up. You write the interview once, send a link, and each person answers by voice when they have a quarter of an hour, in the evening if that suits them. An AI runs the conversation: it asks the questions, follows up when an answer stays vague, and brings people back to a specific episode when they drift into generalities.

That is what we built Raconte for. Among the interview templates, the discovery interview covers the person’s context, the tools they use today, the last problem they ran into, how they solved it and what they would like to change. You can adapt it with the fifteen questions above.

Here is what the weekly loop looks like once the interview no longer depends on anyone’s calendar:

graph TD
  A["Monday: send the link to this week's customers"] --> B["Each person answers by voice when it suits them"]
  B --> C["The AI follows up on vague answers and asks for the last real episode"]
  C --> D["A transcript, a sentiment reading and a summary for each person"]
  D --> E["Friday: the team reads them and updates its hypotheses"]
  E --> A

Four things change for continuous discovery:

• The cadence no longer depends on a slot in the calendar. One interview a week becomes five if five people answer the link. On Raconte, 82% of invitees finish their interview, which lasts 16 minutes on average.
• The same questions go to everyone, so you can compare one week’s answers with the next.
• An AI has no hypothesis of its own to defend, so its follow-up questions are less likely to be leading than a founder’s. The questions you write for it can still be leading, so check them against the Mom Test rules.
• The whole trio reads the transcript, including the engineer who was pulled into an incident. You can also retrieve transcripts through the API or the MCP server and feed them to your own analysis.

Once you have a few dozen transcripts, run a thematic analysis to pull out themes you can defend in a planning meeting.

What an AI interview will not replace

An AI interview records what people say. For some discovery questions, what they say falls short.

When the problem lies in how someone moves or where they work, you need to see it. A warehouse operator describing how they scan parcels often leaves out the workarounds they no longer notice. Spend ten minutes watching them in the warehouse and you will spot those workarounds. The same goes for a usability test on a prototype: you learn more from watching where people hesitate than from their account of it.

Co-design needs people in the same room, or on the same video call. When you sketch a solution with customers, you learn from the back and forth on a shared drawing, which a voice interview cannot offer.

Run the sensitive conversations yourself, face to face or on video: a strategic account, a customer about to leave. You will see a look or a shrug that a voice recording misses. Those signs often show you how far to push.

The asynchronous interview covers the regular part of discovery: problem interviews with many customers, week after week. That leaves you time for the sessions that need someone in the room.

Where to start

Write your three riskiest hypotheses about the customer’s problem. Turn each one into a question about the last time it happened. Send those questions to five customers this week, then read the transcripts together on Friday. When an interview is the wrong tool for the question at hand, compare the qualitative research methods to pick another one.

Discovery interviews cover the time before the purchase. After that, you need other customer research methods, such as the win-loss interview to learn why a deal was won or lost, or the churn interview to learn why a customer cancelled.

Raconte gives every organisation 60 free interview minutes each month, with no card required. You can check the price of additional minutes.

Frequently asked questions

What is customer discovery?

Customer discovery is the stage where a team checks, by interviewing the people concerned, that a problem exists and matters before building a solution. Steve Blank named it as the first step of his customer development model. It produces evidence about who has the problem, how often it happens and what people already do about it.

What are the four phases of customer discovery?

In Steve Blank’s method, customer discovery runs in four phases: state your hypotheses, test the problem with customers, test the product concept with the people who confirmed the problem, then verify what you learned and decide whether to move on to customer validation, adjust or start over.

What are good questions to ask during customer discovery?

Good discovery questions ask what people actually did the last time the problem came up. “Tell me about the last time this happened”, “what did you do, step by step”, “what have you tried so far” and “what does it cost you today” all return facts. Avoid “would you use” and “how much would you pay”, which people answer with compliments.

What is continuous discovery?

Continuous discovery is the practice, described by Teresa Torres, of product teams talking to customers at least once a week, through small research activities tied to a product outcome. The team building the product runs the interviews itself, so every decision rests on recent evidence rather than on a study from last quarter.

How many customer discovery interviews do you need?

For one hypothesis in one customer segment, the same answers usually start repeating after eight to twelve interviews. In continuous discovery the count matters less: you keep interviewing every week, because the product and the customers keep changing.