How to Talk to Users: A Practical Customer Interview Playbook

Talking to users means holding short, live conversations with people who have the problem you want to solve and asking what they did the last time it came up, not what they think of your idea. In our view, the signal worth trusting is what people commit (money, time, introductions), not compliments.

A few habits make those calls work: pick the right people (the ones who have the problem and control the budget), keep your product out of the conversation until the end, and dig into surprising answers. Then group what you heard into problems, build the smallest thing that addresses the biggest one, and go back to the same people.

Definition: A customer interview (or user interview) is a structured conversation with a current or potential user that aims to understand their problem, current behavior and motivation, without pitching a solution.

Compliments are free. That's why they tell you so little.

If you are still deciding whether an idea is worth pursuing, start with our 4-week plan on how to validate a startup idea before you build. This page goes deeper on the conversation itself: one way we'd run it, and how to tell a real signal from a polite one.

Why talking to users is the job, not a side task

Until you have revenue that proves otherwise, customer conversations are among the most valuable hours on your calendar. Three reasons.

Customers are the people least able to flatter you for long. Investors, advisors and friends can all tell you what you want to hear at no cost to themselves. A customer either uses the product and pays, or does not.

The most customer-obsessed founders build that contact into their routine. In 2010 Airbnb's Brian Chesky gave up his apartment to live in about 50 of the company's listings over a few months, so he could talk to hosts every day. A quick test for your own company: search your inbox for "do not reply" senders and notice how many businesses have arranged not to hear from you.

Analytics tell you where people drop off, rarely what they care about. Dashboards are good at describing what happened and weaker at telling you what to build next. Twitch is one of the clearer public cases: after years of shipping features from usage data at Justin.tv, the team switched to structured interviews with gamers, and those conversations set roughly three years of the Twitch roadmap.

Distance slows learning. Every layer you put between yourself and a customer (a support team, an agency, a survey tool) filters out the detail that matters. More money usually adds layers, which is why we think pre-seed, when you have no layers at all, is a good time to build the habit. Steve Blank, who formalized customer development, compressed the whole idea into a warning that there are no facts inside the building: the answers live with customers, not in your office.

Who to interview: the three-lens list

Who you ask matters more than what you ask. Emmett Shear, Twitch's co-founder, makes this point well: had Twitch interviewed viewers instead of broadcasters, it would have built a different company, and broadcasters were the group that mattered because audiences followed them.

One way to build an interview list is with three lenses.

User versus buyer. The person who uses a product is often not the one who pays. A note-taking app for students may be bought by a university IT team or by parents. Interview both sides until you know who holds the budget and who can veto it.
Your users, a rival's users and non-users. Each group answers a different question. Your own users tell you what to fix. A competitor's users tell you what would make them switch. Non-users tell you what stops anyone from trying. At Twitch, its own broadcasters wanted small chat features, rivals' broadcasters cared about revenue share and stable video, and non-users named slow computers and secrecy about tournament strategy. The rivals' users went first because they already had the behavior and only needed a reason to move.
Experts versus casual users. A small group has tried every tool in your category and thought hard about the problem. Treat them as a separate segment. They can teach you a lot, but they are not typical, so be careful about letting them define the whole market.

Where to find them. Go wherever the people already gather. LinkedIn, Reddit, Slack and Discord communities, and in-person events are the channels early-stage founders use most often. Direct messages on the platforms your users already live on work too, as do conferences where you meet people first and book the call later. Friends reply fastest, but they tend to soften their answers, so keep them to a small share of the sample.

Recruit the people you need, not the people who are available. Interviewing whoever answers first is one of the more common ways these programs go wrong, and the extra days spent finding the right contact details are usually worth it. When you recruit, consider screening on both demographics (role, geography, experience) and psychographics (how people think about the problem and behave around it).

Some users will pull you off course. People who use your product in unexpected ways are worth studying; Justin.tv's gamers were exactly that, and they became Twitch. But resist a single loud user who would bend the roadmap toward a problem you never set out to solve.

How to run a customer interview: a seven-step call

Here's the sequence we'd consider running this week if we were starting from zero. Adapt it to your market.

Step 1: Write the learning goal

Before a call, write down your hypothesis and three things you need to learn. For a carbon-accounting idea, that might be: does the company care about its emissions, why or why not, and who inside it owns the problem.

Step 2: Send a short ask with no pitch

Four moves: who you are, the shared connection or context, a one-line note that you are starting a new project (no detail), and a request for a 20-minute call. Leave the product out. Describing the idea in the invitation tends to prime people to agree with you before you have asked a single question.

Step 3: Meet live and record with permission

A five-minute video call can teach you more than hundreds of survey responses. Email interviews are much weaker because you cannot follow up in the moment. Recording with consent helps twice: you stop scribbling and actually listen, and you can play the clip to a co-founder who doubts your conclusion.

Step 4: Build rapport, then go to the past

Open with the person's role and their week. Then move to specific recent behavior: the last time the problem happened, what they did, what it cost. If they can share a screen and show you the spreadsheet or report they use today, that is often better than any description.

Step 5: Chase the surprise

When someone says something you did not expect, switch into detective mode. Ask them to say more, then stay quiet. People tend to fill silence, and the second or third answer is often where the insight sits.

Step 6: Hold your idea until the end, or skip it

This is the habit founders seem to break most. Once you describe or show your product, the answers bend toward being nice about it. Discovery calls are for the problem. Save the product for a separate session.

Step 7: Ask for something that costs them

Close by asking for a second call with their boss, access to their data, a pilot or a deposit. We think of commitment in three currencies: money (they pay), time (they use it regularly) and reputation (they introduce you to peers). An opinion with none of those behind it is weak evidence.

"Customer interviews are a waste of time"

Some founders say this, and we've made a version of the argument ourselves: opinion interviews are a poor substitute for purchase intent. People are generous with their views and stingy with their money, and plenty of teams have run fifty friendly calls and learned nothing.

But That's a case against bad interviews, not against talking to users. A call about past behavior that ends with an ask for money, time or an introduction is a purchase-intent test. It's the opinion part that wastes your time, which is why Step 7 matters more than the other six.

Customer interview questions to ask, and the ones to drop

A core question set we like:

Walk me through how you handle this today.
What is the hardest part of it?
Why is that hard?
How often does it come up?
Why does it matter to you or your company?
What have you done to solve it so far?

The follow-ups often do most of the work: What do you mean by that? Can you give me an example? Why is that important to you?

Questions we'd usually drop:

Would you use our product? People tend to say yes, and it tells you little.
Which features would make this better? Designing the solution is arguably your job.
Any yes or no question, because it produces no examples.
What would a better version look like? Most users are not product designers.
Two questions at once, which muddies both answers.

Rob Fitzpatrick's book The Mom Test is one of the most useful guides to this problem, in our view. It suggests framing questions around the customer's life and past behavior, so that even someone who loves you cannot give you a misleadingly kind answer.

Chase problems, not feature requests. A feature request is a user's guess at a solution, and the guess is often off. Early Gmail users asked for a split view of inbox and message when the real complaint was speed; early Airbnb guests asked for hosts' phone numbers when the real issue was trust.

Twitch's broadcasters asked for polls and chat tweaks, but the interviews revealed three goals (earn money, stable video, a global audience), and most of what Twitch built for those goals was never explicitly requested. Keep asking why until you reach the problem underneath.

A copyable customer interview script

Here is an illustrative script for a 20 to 30 minute discovery call. Replace the bracketed parts, adapt it to your market and say it in your own words.

Opening (2 minutes) - Thanks for the time. I am researching how [role] handle [problem area]. I am not selling anything today. Mind if I record so I can listen instead of typing?

Context (5 minutes) - Tell me about your role and what a normal week looks like. - Where does [problem area] fit into that week?

The last time (10 minutes) - Walk me through the last time [problem] came up. When was it? - What did you do, step by step? Can you show me? - What did it cost you in time, money or stress? - What have you tried before? Why did you stop? - Follow-ups: tell me more; why does that matter; can you give me an example?

Priority (5 minutes) - Where does this rank against the other problems on your plate? - Who else is involved when it goes wrong? Who signs off on spending to fix it?

Close (3 minutes) - Who else should I talk to about this? - If I build something, can I show you an early version in a few weeks? - Optional, last: a one-line description of what you are exploring, then listen.

Consider logging each call the same day: date, segment, the problem in their words, frequency, current workaround and its cost, one direct quote, and the commitment you asked for and got.

Check your signal: a worked example and how many calls is enough

Numbers here are hypothetical, chosen to show the arithmetic of a two-week sprint for a B2B tool.

Outreach. A founder sends 80 personalized LinkedIn and community messages to operations leads. At a 20 percent reply rate, 16 people answer, and 12 calls actually happen (75 percent of replies).
Synthesis. Grouping notes on a board, 9 of the 12 (75 percent) describe the problem happening in the last 90 days. 5 of 12 (about 42 percent) already pay for a workaround such as a contractor or a spreadsheet add-on.
Signal. The founder brings a clickable prototype back to the 5 who pay for workarounds. 2 of them (40 percent) agree to a paid pilot at $300 per month, or $600 of monthly recurring revenue, $7,200 annualized.

Our read: the 75 percent recency figure (9 of 12) suggests the problem is common. The number we'd watch is the 5 people already spending money, because that's where the pain looks most real. Charging is often a quick way to test it. Stripe tested its core bet by pricing above competitors rather than giving the product away.

How many calls is enough? As a rule of thumb, six to eight interviews per type of person is a reasonable plan. Shear's experience is that you stop hearing new things around that point, which is why we'd usually move to a different segment after eight rather than add more of the same one. First Round Review's founder guide to customer discovery uses five per segment as its working number and runs interviews in sprints of five to eight. Later, for prototype testing, Nielsen Norman Group's analysis (published in 2000) found that five users uncover about 85 percent of usability problems, which is why many teams prefer several small rounds to one big one.

From interview notes to an MVP

After five to ten interviews, put every note in one place, cluster the notes by problem, write down your conclusions, and form a solution hypothesis without over-thinking it. Then run three value tests on the top problem:

Are people already paying for other solutions? Paid consultants, contractors or tools are a good sign.
Are they happy with something basic? A spreadsheet is a formidable competitor to hundreds of startups. You often need to be dramatically better to move people off one.
Is the audience easy to sell to? Startups try new tools constantly. Trades such as plumbing and contracting rarely switch software. Neither is a reason to quit, but they usually need very different plans.

Then prototype. Hand people a clickable prototype, give them a goal ("book a stay", "file this invoice"), and watch without explaining the screens while they think aloud. Many founders keep interviewees close afterwards in a small Slack or WhatsApp group that sees each new version.

Shipping a fix to their feedback within days, then calling them back to show it, tends to build more trust than a pitch. Our guide on how to build an MVP covers what to put in that first version, and how to find product-market fit covers how to measure whether it is working.

Where views differ

Serious founders and researchers disagree on a few points. Here's where we land, though reasonable people land elsewhere.

Surveys. Useful for narrow choices, such as picking between four names, and weaker for finding fundamental truths. Once you have users, product-market fit surveys such as the Sean Ellis test (covered in our product-market fit guide) become a standard measuring tool. Interviews to discover, surveys to measure.
Paying interviewees. At pre-seed, we usually wouldn't. If someone won't spend 20 minutes on their own problem, you may be targeting the wrong problem, and free participation is itself a signal of pain. A small incentive can still make sense for hard-to-reach professionals or formal usability studies.
Showing the product. Some researchers end discovery calls with broad questions about an ideal solution (a zoom out, zoom in, zoom out shape). We lean toward keeping discovery calls product-free and running prototype sessions as separate meetings, which lets you do both without contaminating either.
Rejection. An early no can be useful data: it tells you who may not be your customer. We tend to see good early sales as learning and filtering more than convincing. Watch for the disguised no, too. Praise for your technology plus a promise to talk next quarter is usually a rejection said politely.

Common mistakes when talking to users

Pitching instead of listening. If you are doing most of the talking, you are probably selling, not learning.
Asking about the future. Would-you and will-you questions tend to produce polite fiction; asking what they did is usually more reliable.
Treating feature requests as the answer. Asking why they want it often leads to the underlying problem.
Interviewing only friendly or available people. A stronger sample includes the buyer, the skeptic and the non-user.
Stopping after launch. The people who get you started are often not the people who use you three years later, and teams that stop interviewing risk building weaker second features. The same habit later powers customer references and referrals.
Protecting your ego. Many founders who avoid these calls are avoiding rejection. Treat each call as an experiment, not a verdict on you.

How 1752vc's Launchpad helps you practice this

If you are preparing to leave a job to start a company, Launchpad is 1752vc's 12-week, self-paced, remote sprint from -1 to 1: validate an idea, find a first customer and build a path to traction. Customer conversations are the raw material for all three, so it can be a natural place to run the script above with structure and feedback. Admissions are rolling. Once you have users, the manual work of keeping them happy is the subject of our sibling guide on doing things that don't scale.

The bottom line

Ask about the past, listen more than you talk, and end every call by asking for something real. The rest is practice.

What people say is a guess.

What they pay for is an answer.

Key takeaways

Who you interview can matter as much as what you ask: it helps to separate users from buyers, and to talk to current users, competitors' users and non-users.
Asking about specific past behavior and current workarounds tends to work better than "would you use this," feature wish lists and yes or no questions.
Consider keeping your idea out of discovery calls, recording with permission, and following surprising answers with "tell me more."
We would measure interest by commitment (money, time or referrals), not by compliments, and treat quick rejections as useful filtering.
Six to eight interviews per segment usually reveal the pattern; then build a small prototype and show it to the same people.
Many teams keep talking to users after launch, because the people who matter to a company change as it grows.

Frequently asked questions

What questions should you ask in a customer interview?

In our view, open questions about recent, specific behavior work best: how they handle the task today, the hardest part and why, how often it happens, why it matters, and what they have already tried. Follow up with "tell me more" and "can you give me an example." Questions about your product tend to invite polite guesses instead of facts.

Should you show your product during a user interview?

We would generally avoid it in a discovery interview. Introducing your idea early tends to bias the answers that follow, and showing the product is a common mistake founders make in these calls. A separate prototype session later often works better: give the user a goal, stay silent, and ask them to think aloud as they click through the screens.

Should you pay people for customer interviews?

Usually not at the pre-seed stage, in our view. People who will not give 20 minutes to discuss their own problem may not feel it strongly, so free participation is itself a useful signal of pain. A small incentive can make sense for hard-to-reach professionals or formal usability studies, where recruiting the right person matters more than the signal.

Are surveys a good substitute for talking to users?

Not for early discovery, in our view. Surveys work for narrow choices, like picking between names, but they tend to miss the fundamental truths and the expert users who teach you the most. They become valuable later, once you know the problem and want to measure how widely it is felt or track product-market fit over time.

How do you find people to interview for a startup?

A good place to start is where your users already gather: LinkedIn, Reddit, Slack and Discord communities, and in-person events are the most common early channels. Send a short, personal message asking for a 20-minute call without describing your product. Former coworkers and friends of friends can help, but relying only on people who know you tends to skew answers.

Sources

Disclaimer: This guide is for general education only and is not legal, tax or investment advice. Laws, market data and program terms change, so it may not reflect the latest developments or fit your situation. Treat it as a starting point, not a source of truth, and talk to a qualified lawyer, accountant or financial adviser before you make decisions.