How to Talk to Customers
YC says “talk to your users” so often it starts to sound like a slogan. It isn’t. Most startups die because the founders built something in their head and then went looking for people who would politely agree with them.
Talking to customers is not pitching, It’s trying to find out how someone already deals with a problem when you’re not in the room.
If you leave a call thinking “they loved the idea,” you probably ran the conversation wrong.
What you’re actually trying to learn
You want the messy version of their life.
How they do the thing today. What sucks about it. How often it happens. What they already pay for. What they ignore. What they complain about to coworkers but never put in a survey.
Paul Graham’s test is a good one: can you say what you learned? Not “users are excited.” What was wrong about your first picture of them? If you can’t answer that, you haven’t talked to enough people. Or you talked, but you were too busy selling.
Who to talk to
Talk to people who have the problem. Not your most encouraging friends, unless those friends actually live with the problem.
Start with people you already know. Former coworkers. People one intro away. Then go where they hang out: LinkedIn, Reddit, Slack, Discord, industry groups, events. Warm intros get replies. Strangers are often more honest.
Do the call live. Video, phone, in person. A five-minute conversation beats 2,000 survey answers because you can hear when someone is guessing, being nice, or describing something that actually happened last Tuesday.
How not to blow the call
Build a little rapport first. Then shut up about your product.
This is the part founders hate. They want to explain the idea so the other person “gets it.” The second you explain it, the interview is contaminated. People start answering the version of reality that makes you feel good.
Ask about their world. Let them talk. Take notes. Record if they’re okay with it. You’re trying to catch details you’ll forget ten minutes later.
Ask about what they did, not what they would do
Good questions sound almost boring:
- How do you do X today?
- What’s the hardest part?
- Why is that hard?
- How often does this happen?
- Tell me about the last time it happened.
- What did you do then?
- What do you use now?
- What happens if you don’t deal with it?
Then keep poking:
- What do you mean?
- Can you say more about that?
- Why does that matter?
The gold is in the follow-up. First answers are usually clean and generic. The real stuff shows up when you make them slow down and tell the story.
Don’t ask these
- Would you use this?
- Would you pay for this?
- What features should we add?
- What would the perfect product look like?
- Anything that can be answered yes or no
People are polite. They will invent a more disciplined future self who switches tools, pays annually, and onboards the whole team next month. That person does not exist.
You want evidence from last week, not a speech about next year.
How to tell if the conversation was real
Look for
- a specific recent example
- an ugly workaround they already use
- money, time, or internal pain attached to it
- the same complaint from different people, in almost the same words
- them getting sharper, not vaguer, as they talk
One excited friend is not a market. Five unconnected people describing the same broken workflow starts to be something.
If you later show a prototype, watch their face and their hands. Confusion is more useful than praise.
After the calls
Don’t jump straight to a feature list.
Write down the boring synthesis:
- who actually has this problem
- what they’re trying to get done
- why the current way sucks
- what they already do about it
- why they would bother switching
This week, talk to 5 people who actually have the problem and write one sentence after each call: what surprised you.
If you can’t do that by Friday, you’re still building in your head.