Customer discovery interview questions help you learn how someone handles a problem today. Ask for a recent story, what the person tried, and what happened next. Learn about their work before you discuss your idea.
A useful opening asks someone to describe the last time they did the task you want to learn about. Follow the story, including the parts that went well. A complaint may point to a problem worth studying. It cannot tell you how many people share it or whether they will buy a tool.
The question bank links each assumption to an open question and a gap to check. A made-up invoice example shows how to use it when earlier interviews disagree.
Prepare your next discovery questions
Compare earlier interviews with your problem hypothesis.
What discovery questions should reveal
A discovery interview explores a person's work, needs, and choices. You start with a problem hypothesis: an idea about a problem that may exist. Treat it as a question to check. Great Lakes I-Corps preparation guidance suggests going in with a clear purpose and a plan.
For example, you might suspect that small agencies struggle to collect overdue invoices. Ask how collections happen, what counts as overdue, and when follow-up becomes difficult. Someone whose clients always pay on time can help you find the limits of that hypothesis.
Keep what people say apart from what you see. User Interviews 101 explains that interviews collect reports of behavior.
In a usability test, you watch someone use a design. A story can guide a new question or a check of a record you may use. It may still leave out events, get dates wrong, or describe an unusual week.
Build a bank around real events
Choose questions that serve your goal. You do not need to finish a long list in one talk. Open-ended questions give someone room to explain. Check details once you understand the story.
Use these original question patterns as starting points, then adapt the task words to the person's setting.
| Assumption to examine | Open question | Evidence still needed |
|---|---|---|
| The task creates a recurring problem | Describe the last time you handled this task. What happened? | Other occasions, including easy cases |
| The current workaround takes effort | How did you handle it that time? | Steps, people, and any permitted records |
| The consequence changes priorities | What happened after that? | Who was affected and what they did |
| Existing options have been tried | What have you tried before? How did that go? | The reason an option was kept or dropped |
| The user can decide to buy | How was the last relevant purchase decided? | Buyer role, approval process, and actual spend |
Table 1: The final column records what the first answer leaves unresolved, not a reason to dismiss it.
Context and recent events
Ask what the person is responsible for and where the task fits. Then invite one event: “Think of the most recent time you followed up on an invoice. Take me through it.” If that task is not part of their role, follow the work they actually do rather than forcing the example.
Useful follow-ups include “What happened next?”, “Who was involved?”, and “What do you mean by that term?” The funnel technique starts broad and then seeks detail. A date or frequency check makes more sense after you know which event the person means.
Workarounds, consequences, and decisions
Explore what they did, including manual steps and help from other people. Ask what they kept using and why they abandoned an alternative. Request a redacted example only if it is appropriate and they are willing to share it.
For money questions, ask about a purchase that happened. What led to it, who chose, and who signed it off? Strategyzer's interview advice warns that a promise to buy may differ from what someone does.
What they spent in the past helps explain that choice. It does not tell you what they will pay you.
Worked example for invoice follow-up
Imagine a founder studying invoice follow-up at small design firms. Both stories below are made up for this example. They are not results from an Atlas test or a study. The founder suspects that sending reminders by hand gets in the way of other work.
Keep the difficult account specific
In made-up interview A, an owner describes chasing one late invoice after a client contact left. The owner found a new contact and sent a reminder. This broke up the day's work. The story does not say how often it happens or whether the owner would change tools.
The next question could be: “What other follow-ups have you handled recently, and how did those go?” Ask about time or impact after hearing those accounts.
Avoid “How much time does this frustrating process waste?” That wording assumes both frustration and waste; NN/g's leading-question guidance explains how assumptions enter the answer.
Preserve the easy account too
In made-up interview B, another owner says a weekly finance routine handles reminders without much trouble. Keep this story beside A. Do not assume that B has failed to notice a problem. The firms may differ in their clients, workload, or who owns the task.
A follow-up might ask: “Walk me through the last reminder your finance colleague handled.” The founder can then examine whether the routine works reliably or whether trouble appears elsewhere. This is a new question, not a conclusion that delegation solves the problem.
The working note is narrow. One owner lost time after a contact change; another describes a routine that works. You still need to know whether this pattern holds for other events and firms. Neither story supports “small agencies urgently need automated reminders.”
Ask questions without steering the answer
Prepare an introduction that states why you want to learn about the task and how you will use the conversation. Explain recording and ask permission if you intend to record.
Strategyzer notes that recording can affect how openly people speak, so consent does not remove every influence.
Start with the person's role, then invite the recent event. Let them complete the account before choosing a follow-up. A planned guide helps you cover important topics, while the person's words tell you where a useful probe belongs.
When an answer is vague, ask for an example without giving one yourself. If they say “it was slow,” ask which part they mean and what happened. Keep their word rather than changing it to “painful” or “broken.” Neutral wording lets them describe what happened even when it differs from your view.
Use a closed question to check a fact, such as whether the same person chose and paid for a tool. Then return to the story. NN/g's open and closed question guidance explains how both forms can help. Choose the form that gets the detail you need.
Before closing, ask what you missed and whether another role would offer a different view. Keep recruitment and permissions separate from the person's answers. A referral to another agency is a possible next contact, not evidence that the referred agency has the same problem.
After the talk, write down the story while it is fresh. Keep the person's words, your reading of them, and your next question in separate fields. If you need speech turned into text, interview transcript AI tools address that earlier step. Check the text before using it as a source.
Prepare a source-linked guide in Atlas
Use Atlas when earlier interview text and your problem hypothesis already exist. Add only sources you are allowed to use. Remove names and other details you do not need. Keep your hypothesis in its own note so it cannot be mistaken for something a person said.
Select sources and ask a bounded question
Open the research project and start a chat. Type @ to select the earlier interviews and hypothesis note. For the fictional invoice example, the question could be:
Compare these interviews with my note about invoice follow-up. Suggest open questions about recent events and current workarounds. For each question, name the assumption, cite a source passage, and state what is still unknown. Keep views that disagree. Do not infer demand or willingness to pay.
This request asks for preparation from existing material. It does not ask Atlas to supply missing interviews. For later analysis across a larger set of accounts, AI interview analysis explains tool choices and the distinction between research and hiring workflows.
Check the citation and repair the question
Open each citation and read the text around it. Check the speaker and event. Does nearby text change what the passage means? If a draft question says “Why are late invoices such a serious problem?”, change it to “Describe your most recent invoice follow-up.” The new version allows an easy story as well as a hard one.
The source-and-answer view below illustrates that review step. It displays an unrelated research paper, not the fictional invoice interviews. Inspect a cited passage beside the answer, then decide whether the proposed wording says more than the source supports.

Read the source context before keeping a proposed question or interpretation.
The visible paper is The AI Scientist-v2 by Yamada et al., licensed under CC BY 4.0. This Atlas screenshot is reused unchanged.
If the citation is missing or points to the wrong interview, select the source you meant and ask again. Mark an assumption unknown when no source backs it. A question that sounds useful can still assume something false.
Save the corrected question bank
Select New → Note and give the note a clear title, such as “Invoice follow-up questions for the next interviews.” Save each assumption, proposed question, supporting passage, and gap. Wait for Saved before closing the editor.
In the made-up example, the checked note keeps A's contact-change story and B's routine together. It asks about other events and who owns the task. It makes no claim about all small firms. As you gather interviews, qualitative coding can help group accounts. Check each code against the text it refers to.
Choose what to investigate next
Review the question bank with a colleague before using it. They can check whether a question assumes a problem, merges two topics, or introduces your solution too early. I-Corps preparation advice emphasizes a purposeful plan; your evidence gaps determine which topics deserve the next conversation.
For the invoice example, another account from a finance colleague may explain the routine better. A permitted redacted record may clarify timing. Choose the next step based on the claim you need to examine, and keep interview recollections separate from observed events and actual purchase behavior.
If the next question concerns how people use a specific design, write a usability test plan. Discovery interviews explore accounts of work and choices; a test plan connects the question to tasks that let you observe relevant behavior.
Prepare your next discovery questions
Compare earlier interviews with your problem hypothesis.

