The interview that produces usable data has one rule: you ask about the past, never the future. "Would you use something like this?" gets you a warm, useless yes. "Walk me through the last time that happened" gets you a date, a cost, a workaround and a name. Everything else in customer discovery is detail. If you only change one thing about how you talk to customers before you build, change the tense of your questions.
Why hypotheticals produce flattery
When you ask someone to predict their own behaviour, they answer with their self-image. People imagine a version of themselves who is organised, decisive and has budget. That person does not exist at 4pm on a Tuesday.
Worse, most of the people you interview early are people who like you. They can hear what answer you want. A hypothetical question hands them the script.
History is harder to fake. If the problem is real, there was a last time it happened, and that event left a trail: an email thread, a spreadsheet someone built at the weekend, a contractor invoice, a plan that slipped. If you dig and find no trail, that is your answer.
Replace every "would you" in your script with "when did you last".
The question list
Use this in order. Fifteen minutes of it beats an hour of pitching. Do not send your idea in advance, and do not describe your solution until the end, if at all.
- "Tell me what your week looks like when [area of work] is involved." You are getting context, not commitment.
- "When was the last time [the problem] happened? Take me through that day." Ask for the actual sequence. Push for specifics: who was in the room, what was open on the screen.
- "What did you do about it?" This is the most important question in customer discovery for beginners. The answer is their current alternative, and it is your real competitor.
- "What did that cost you?" Let them pick the unit. Hours, overtime, a missed deadline, an angry client, a refund.
- "What did you try before that?" Anything they have already bought, hacked together or abandoned is a signal of intensity.
- "What are you paying for today that touches this problem?" Tools, freelancers, agencies, internal headcount. You are looking for an existing line item.
- "How often does this come up?" Weekly pain gets funded. Annual pain gets tolerated.
- "Who else feels it? Who would have to agree before anything changed?" You are mapping the buying group before you waste three months selling to someone with no authority.
- "If it disappeared tomorrow, what would you stop doing?" This separates convenience from cost.
- "Where does this sit against everything else on your plate this quarter?" Fourth priority means no budget, regardless of enthusiasm.
- "Who else should I talk to about this?" A real introduction, sent that day, is worth more than any compliment.
Then stop. If you have a solution in mind, ask permission: "Can I show you something rough and get your reaction?" The reaction after this sequence is far more honest than the reaction cold, because you have already anchored them in their own facts.
What you are listening for, not what you hope to hear
Three things make a problem buildable. Frequency, cost and existing spend. You want a problem that happens often, hurts measurably, and already has money moving toward it in some clumsy form.
A workaround is the best news you can get. If someone has built a spreadsheet, hired a cousin, or stayed late every month to handle this, they have already proven willingness to spend resources. Your job is to be a better workaround, not to invent a new category of desire.
Silence is also data. If nobody can name the last occurrence, or everyone describes the problem in the abstract ("efficiency", "visibility", "better reporting"), you are hearing a topic, not a problem. Topics do not pay invoices.
If you want to pressure-test what you heard against a wider set of signals before you build, our free five-minute score at /validate scores the idea on demand, competition and how quickly you could get paid, and it will usually confirm or contradict what your interviews are telling you.
The tells that a polite yes is not a real one
Enthusiasm is the least reliable signal in the room. Watch for these:
- They speak in the future tense. "I'd definitely use that." Real buyers speak in the past tense about their pain and the present tense about their budget.
- They compliment the idea rather than the fit. "This is such a smart idea" means they are being kind. "How would this handle our multi-site setup?" means they are imagining using it.
- They have never searched for a solution. If it hurts, they googled it. Ask what they found and why they did not buy.
- No workaround exists. Nobody has hacked anything together, so nobody is bleeding.
- They redirect to other people. "This would be great for smaller firms than us" is a no with good manners.
- They want more features instead of a price. Feature curiosity is free. Price questions cost something to ask.
- They will not commit anything small. Which brings us to the test.
Ask for a small, specific, costly next step at the end of every interview: an introduction by name, a 30-minute session with their data, a spot on a paid pilot list, or a deposit. Anything that costs them time, reputation or money converts words into evidence. If a warm, enthusiastic conversation produces no commitment of any kind, log it as a no and move on without resentment. It is not personal, it is a price signal.
How to line up the conversations
You do not need a panel or a research budget. You need eight to twelve people who live with the problem, and you probably already know most of them through your job.
Ask directly and without a pitch: "I am looking into how teams handle [problem]. Could I ask you about how yours does it, fifteen minutes, no selling?" That framing gets accepted far more often than a request for feedback on an idea, because it costs the other person nothing to be helpful and nothing to be honest.
Interview across roles, not just friends. The person who feels the pain is often not the person who signs. If you learn that late, you will price wrong. Our post on how to know if people will buy your product before you build it covers what to do with those signals once you have them, and if the conversations reveal that the problem is worth paying to solve but you have no idea what to charge, start with how much should I charge rather than guessing on the call.
Turning transcripts into a decision
Do not write summaries. Summaries smuggle in your hopes. Instead, keep one row per interview with five columns: last occurrence, frequency, cost they named, current workaround, commitment given.
Ten rows of that and the pattern is unmissable. Either most people can name a recent, expensive, frequently repeating event and several took a next step, or they cannot. There is no third outcome that needs interpreting.
Be honest about which feedback deserves weight. Entrepreneur made a useful distinction recently between criticism worth acting on and noise you should ignore, and the same filter applies to praise: weight the people who have the problem and the budget, discount everyone else no matter how encouraging they are.
A conversation where someone tells you your idea is great and commits nothing is not validation. It is a very pleasant form of no, and you paid for it with a week of building.
When to stop interviewing and start selling
Stop when you can predict the answers. Once two or three interviews in a row produce nothing you have not heard, you have your pattern. More conversations at that point are procrastination wearing a lab coat.
The next step is not building. It is making an offer to the specific people who described the specific problem, at a price, with a start date. That is the real test, and it is the fastest way to find the gap between stated interest and actual demand. If you would rather not run that step alone, the First Customer Validation is built for exactly this stage, and how pricing works is a conversation rather than a published figure. If the interviews left you with a signal but no idea what to sell, how to get your first customer is the next thing to read.
Frequently asked questions
How many customer interviews do I need before I build?
Usually eight to twelve people who genuinely have the problem, though the number matters less than the repetition. Stop when new interviews stop producing new information. If you have done twenty and still cannot describe the problem in your customer's own words, you are interviewing the wrong people or asking hypothetical questions.
What customer interview questions should I never ask?
Anything starting with "would you", "do you think" or "how much would you pay". All three invite speculation. Replace them with "when did you last", "what did you do about it" and "what are you paying for that today". Also avoid describing your solution up front, because from that moment on you are being given reactions to you rather than facts about them.
Can I validate with customer interviews alone?
No. Interviews tell you whether the problem is real and expensive. Only an offer tells you whether people will pay for your version of the fix. Treat interviews as the step that earns you the right to make a specific offer, and if you want a second opinion on the idea before you commit time to it, book a validation call.