How to Run Customer Interviews (Process and Script) (2026)

Most founders already have a list of customer interview questions. What they are missing is the process around the questions: who to talk to, how to get them on a call, how to run the 30 minutes so the answers mean something, and how to read a stack of notes without fooling yourself.

That gap is why interviews so often mislead. You ask a room full of polite people whether your idea is good, everyone says yes, you build it, and nobody buys. The yes was free. This guide is about running interviews that produce evidence instead of encouragement.

If you want the exact questions, they live in two companion posts you can open alongside your script. Here we cover the mechanics: recruiting the right people even with no network, the one principle that separates a useful interview from a flattering one, a 30-minute structure, the two mistakes that quietly ruin most interviews, recording and notes when you work solo, how to find real patterns across conversations, how many to run, and the build-change-stop decision the whole exercise exists to produce.

Where interviews sit in the evidence ladder

An interview is a research method, not a verdict. It produces claims about what customers do and want; it does not, by itself, prove anyone will pay. Treat it as one rung on a ladder of increasingly expensive evidence, and keep it in proportion to the broader customer validation framework that decides how much weight any single signal deserves.

The rung below an interview is your own assumption. The rung above it is behavior that costs the customer something: a redacted file they actually send you, a scheduled pilot, a deposit, a signed order. Interviews are valuable because they are cheap and fast and tell you where to point the expensive tests. They become dangerous the moment you treat what someone said as if it were something they did.

That distinction is the core of the customer development discipline: get in front of real buyers before you scale anything, and let what you hear change the product rather than confirm it. Interviews are how you do the talking. The rest of this guide is how to do the talking well.

Who to interview, and how to recruit them with no network

Before you recruit anyone, write the target in one sentence: the specific person, the trigger that makes the problem urgent, and the result they want. "Small e-commerce operators" is too broad to source. "The person at a 10-to-40-person online brand who reconciles refunds after a return spike" is someone you can actually find and recognize.

Then interview people who have the problem now, not people who are easy to reach. A supportive friend, a fellow founder, and your own co-founder will each give you a warm, useless yes. You want the person whose week the problem actually lands in.

If you have no network, you are not stuck. You recruit by relevance instead of by relationship:

Recruit for research, not for a sale. "Can I get your advice on how you handle this?" books far more calls than "Can I show you my product?", and it also produces more honest answers, because the person is not bracing to be sold to. Offer a small thank-you if it fits your audience, keep the ask to 20 to 30 minutes, and make it easy to say yes.

The one principle: ask about the past, not the future

If you fix only one thing about your interviews, fix this: stop asking people to predict their future behavior, and start asking them to describe their past behavior.

People are unreliable at forecasting what they will do and generous when a stranger's feelings are on the line. "Would you use this?" and "Would you pay $30 a month?" invite a polite hypothetical that costs nothing to give and predicts nothing. "What did you use the last time this came up, and what did it cost you?" asks for a fact that already exists.

This is the central idea of Rob Fitzpatrick's The Mom Test: a good question is one you could ask even your own mother without getting a falsely encouraging answer, because you are asking about her life and past actions rather than fishing for approval of your idea. Anchor every question that matters to a real, dated event and to money or time already spent.

The rewrites are not just less pushy. They return information you can act on: a workaround to replace, a number to beat, a trigger to design around.

A 30-minute interview script

You do not need a long script. You need a shape that reliably walks from context to a real event to what that event cost, plus the discipline to stay quiet between questions. This structure fits comfortably in half an hour:

1. Open (about 2 minutes). Set the frame: "This is research, not a sales call. I want to understand how you actually handle [task] today. There are no right answers, and it is completely fine if the honest answer is that this is not a big deal for you." Ask permission to record. Do not describe your idea yet.
2. Current situation (about 5 minutes). Establish context: how the job fits into their week, who owns it, which tools touch it. You are mapping the terrain before you dig.
3. The last time it happened, and what it cost (about 10 minutes). This is the heart of the interview. "Tell me about the most recent time [problem] came up." Reconstruct the event step by step, what started it, what they did first, where it stalled, then follow with the consequence: what broke, who noticed, and what the delay or error actually cost.
4. What they have tried and spent (about 5 minutes). Workarounds, tools bought, contractors hired, internal projects, hours burned. Past attempts reveal both real motivation and the bar a solution has to clear.
5. Decision and budget (about 5 minutes). Who would need to agree, where money for this kind of thing comes from, and how the last comparable purchase actually got approved. Ask this calmly and late, once you understand the problem.
6. Close and referral ask (about 3 minutes). "What should I have asked that I did not?" often surfaces the most important thing in the call. Then: "Who else deals with this a lot that I should talk to?" End every interview with the door open to the next one.

The skeleton is deliberately light on exact wording, because the wording depends on what you still need to learn. To reconstruct the workflow, constraints, and exceptions before you build anything, work from these customer validation questions to ask before building. When you need to gauge urgency, budget, authority, and willingness to commit, use these customer discovery questions that reveal buying intent. Pick the handful that fit the person in front of you; never read all of them like a survey.

The two mistakes that quietly ruin interviews

Two habits do more damage than any missing question: leading the witness, and pitching your solution. Both feel productive in the moment, and both corrupt your data.

A leading question smuggles in the answer you are hoping for. "Saving three hours a week would be valuable, right?" gets a yes from almost anyone, and that yes tells you nothing. Ask the neutral version and let the customer supply the number: "How long does that take you now?" Then stay quiet. Founders instinctively rescue people from a pause by explaining the idea, and the explanation contaminates everything the person says next.

Pitching is the more seductive mistake. The moment you describe your solution, the conversation stops being research. The customer switches into reaction mode, turns polite, and starts evaluating your feelings instead of recalling their own behavior. Hold your idea until the last few minutes, if you mention it at all. If they ask what you are building, give one sentence and steer back: "I will show you in a minute. First, the last time this happened, what did you actually do?"

Running interviews solo: recording, notes, and permission

Doing this alone creates a real tension: you cannot both hold a natural conversation and transcribe it word for word. Resolve it deliberately rather than hoping to remember.

Record when you can. Ask first, since a plain "Do you mind if I record this so I am not scribbling the whole time?" is almost always fine, and follow whatever privacy and consent rules apply where your customer works. A recording lets you stay present and capture exact phrases, which matter more than you would expect: when a customer calls your assumed "analytics problem" a "client-trust problem," that word choice can redraw your entire category.

If you cannot record, take sparse notes, capturing verbatim quotes, numbers, and the sequence of events rather than full sentences, and block ten minutes right after the call to write it up while it is fresh. Either way, keep one interview to one page. That single-page-per-conversation habit is what makes the next step, finding patterns across interviews, possible at all.

Find patterns across interviews, don't cherry-pick anecdotes

The most common way interviews mislead is not a bad question. It is a good story. One vivid, articulate customer says something quotable, it lodges in your memory, and you build a roadmap around a single person. Synthesis is the discipline that protects you from your own most memorable interview.

At Rocket Internet, we built audience before product — customer conversations came first. The part that made those conversations worth trusting was refusing to grade them by how good they felt. Every batch of interviews got ranked on a forced distribution — a few severe pains, several mild ones, most of them nothing — instead of scored by instinct, because instinct always tilts toward the idea you already love. Run your own notes through the same discipline before you decide what they mean.

Work across the set, not down a single transcript. For each recurring element, the trigger that starts the problem, the workaround people use, the step that breaks, the cost they named, count how many independent people raised it unprompted. Something three or four unrelated buyers describe the same way is a signal. A brilliant point that one person made is a hypothesis, at best.

Keep two columns separate the whole way through: what the customer stated, and what you inferred. "The monthly report takes six hours" is a fact they told you. "They will pay $500 a month to cut it" is your inference until someone actually commits. Blurring those two is how a wall of encouraging quotes becomes a product nobody buys.

Capture every conversation the same way so it can be compared. A consistent customer interview notes template with fields for context, the recent event, its cost, prior attempts, the decision path, and three exact quotes turns a pile of calls into something you can actually count. This is also where an AI co-founder earns its place: inside 100 Tasks AI, it can draft your recruiting messages and assumption list before the calls and then keep the repeated facts from your notes connected to the product and sales decisions that follow, though no amount of tidy summarizing rescues weak evidence.

How many interviews before you decide

There is no magic number, and anyone who hands you one is selling a framework. The honest stopping rule is saturation: keep interviewing within a single segment until new conversations stop surprising you. When the fifth and sixth people describe the same trigger, the same workaround, and the same cost you already heard, you have probably found the pattern. When every interview still tells a different story, you either have more to learn or your segment is too broad.

As a rough illustration, founders often need something like five to eight focused interviews in one narrow segment before a pattern is trustworthy, but that count resets the moment you change who you are talking to. Six interviews spread across six unrelated buyer types are six anecdotes, not a pattern. Concentrate on one segment at a time.

The decision every interview set should produce: build, change, or stop

Interviews are not the goal. A decision is. After a concentrated set in one segment, force yourself to one of three outcomes rather than drifting into "that was interesting, let's keep talking."

Build, narrowly, when the same workflow, trigger, and cost repeat across independent buyers, people give you access to real artifacts, and a small first version can plausibly reach the result they described. Build the wedge, not the whole vision.

Change when the problem is clearly real but something about your framing is off. This is the most common and most useful outcome, and it takes several shapes: narrow to the one subgroup that showed genuine urgency; reframe around the problem customers actually named instead of the one you assumed; or run a commitment test, a pre-sale or a paid pilot, because the talk is strong but no one has yet spent anything. Changing direction on evidence is progress, not failure.

Stop when the interviews were full of praise and empty of behavior: no recent examples, nothing tried, no money or time spent, no urgency, no one willing to take a next step. A wall of "I love it" with no action underneath is the clearest stop signal there is, and catching it now costs you a few weeks instead of a year.

Book three interviews this week

The method fails closed if you never schedule the calls, so make the next step small and dated:

1. Write your one-sentence target: the specific person, their trigger, and the result they want.
2. List ten people who match it, drawn from workaround-users, one community, and cold outreach.
3. Send five research-framed requests today, asking for advice, not a demo.
4. Book three 30-minute calls for this week, and open the two question lists beside your script.
5. After each call, spend ten minutes filling one page of notes while it is fresh.

Three honest conversations about what customers actually did last month will teach you more than a month of guessing at what they might do next. Ask about the past, stay quiet, write down their exact words, and let the pattern, not the applause, decide whether you build.

Inside 100 Tasks AI, this exact workflow lives at SETUP stage Task 14 (pain points and jobs-to-be-done from AI-assisted interviews) and Task 24 (AI customer discovery), run through the ICP Builder + Prospect Starter Sales Skill. It keeps recruiting, interviews, and synthesis attached to the rest of your build instead of scattered across a separate stack of notes.