How to Talk to Your Users: A Guide to User Interviews

Most of the features I regret shipping started the same way. I had an idea I was sure about, I built it, and almost nobody used it. I had been building from my own head instead of from what people were actually doing.

User interviews are the cheapest fix for that. A user interview is a focused conversation where you learn how someone works, what they struggle with, and what they have already tried. Run them well and you save weeks of building the wrong thing. Run them badly and you walk away with false confidence and ship anyway.

This is how I run them while building Peerlist.

A user interview is for learning what people already do. It is not a place to pitch your idea. The moment you start selling, the answers stop being useful.

Why this matters more now with AI

Building used to be the hard part. It is not anymore. You can describe an app to an AI tool and have something working by the end of the afternoon.

When building is cheap, the limiting factor is no longer whether you can build it. It is whether anyone needs it. I see a lot of builders, myself included on bad weeks, making the thing that is fun to build instead of the thing someone is waiting for. AI makes that trap easier to fall into, because it removes the friction that used to force you to stop and ask if the idea was any good.

A polished demo built in a weekend feels like proof. It only proves you can build, which was never the question. The best ideas still come from noticing a real problem someone has, which is the whole argument of Paul Graham's How to Get Startup Ideas. The conversation with the person who has the problem is the part AI cannot do for you (yet!), and it is the part most people skip.

What a user interview actually is

It is a conversation, not a survey read out loud. You are trying to understand one person's real behavior in enough detail that you could describe their day better than they can.

It is not a focus group, where loud opinions drown out quiet ones. It is not a demo. It is not a way to confirm a decision you already made. The output is not a feature request. It is a clear picture of a problem, in the user's own words, specific enough that you know whether it is worth solving.

When to run user interviews

You can run them at every stage, and the goal shifts each time. Before you build, you interview to find out if the problem is real enough that people already hack around it. If nobody has a workaround, the pain is probably not there yet. While you build, you check that your solution matches how people think about the problem. After you launch, you talk to the people who churned and the people who stuck. The ones who left tell you what broke. The power users tell you what to double down on.

The mistake is treating interviews as a one-time phase. I keep three or four conversations going every week, even when I am not deciding anything specific. Teresa Torres calls this continuous discovery, the subject of her book Continuous Discovery Habits, and the habit matters more than any single call.

Who to talk to

Talk to people who have the problem, not people who like you. Friends will be kind, and kindness is useless data.

With no users yet, go where people with the problem already gather:a Peerlist post, a subreddit, a Discord, a Slack group, the comments under a relevant post. Recruiting those first conversations by hand feels slow, and it is the right kind of slow. Paul Graham makes the case for it in Do Things That Don't Scale. Once you have users, your own list is the best source. Recent signups, people who churned, and daily users are three different conversations, so keep them separate.

How to ask for the interview

Most people overthink the outreach. You are asking for fifteen minutes of help, not a favor that needs repaying. A specific ask converts far better than a vague one.

Weak: "Hey, would love to pick your brain about my startup sometime."

Better: "I am trying to understand how people handle [specific problem]. You clearly deal with this a lot. Could I ask you a few questions for fifteen minutes this week? I am not selling anything, I just want to learn how you do it."

Keep it short, name the exact problem, and make the no-pitch promise explicit, because people assume any founder call is a sales call in disguise.

Who actually qualifies

Not everyone is worth interviewing. I use two filters. First, recency: has this person hit the problem in the last month? Fresh memory gives you real detail, while a problem from a year ago gets remembered as a tidy story that never happened that way. Second, effort: have they already tried to solve it, even with an ugly workaround? Someone who built a spreadsheet or paid for something that half worked has a real problem. Someone who shrugs and says it would be "nice to fix one day" does not, at least not yet. If a person fails both filters, they can still be a pleasant chat. Just do not let their answers move your roadmap.

If they say no to a call

A lot of people will not get on a call, and that is fine. Ask if you can send two or three questions over text instead. Async often works better, because people answer on their own time and write more than they would say out loud. A voice note is a good middle ground. The rules stay the same in any format: ask about the last real time they hit the problem.

How many user interviews you need

Fewer than you think. You are looking for patterns, not statistical significance. The same themes start repeating after about five to eight conversations with a similar group. When the third person describes the same workaround the first two did, you have a pattern worth acting on. If every interview tells you something completely new, you are probably talking to people who are too different from each other, and you need to narrow who you recruit.

The questions that work, and the ones that lie to you

The single biggest skill in user interviews is asking about the past, not the future. People are terrible at predicting what they will do, and very good at telling you what they did last week. If you read one book on this, make it The Mom Test by Rob Fitzpatrick. The whole premise is asking questions people cannot accidentally lie to you about.

Questions that work, because they pull out real behavior:

• "Walk me through the last time you tried to do X."

• "What did you use before this? Why did you switch?"

• "When was the last time this cost you time? What happened?"

• "How are you solving this today, even if the fix is ugly?"

Questions that lie to you, because they invite a polite guess:

• "Would you use a tool that did X?" Everyone says yes, and yes means nothing.

• "How much would you pay for this?" People cannot price a thing they have not used.

• "Do you think this is a good idea?" You are asking them to rate you, not to describe themselves.

When someone says they would "definitely use" something, treat it as a flag, not a win. The follow-up is always the same: "Have you looked for something like this before?" If they have not, the pain is not real yet.

How to run the conversation

Keep it to thirty minutes, and record it if they agree, so you are not splitting attention between listening and writing. Aim to talk for about a fifth of the time. Silence feels awkward, and that awkwardness does your job for you, because people fill it with the answer they were holding back. Eric Migicovsky's YC talk How to Talk to Users is thirty well-spent minutes on this exact framework.

When someone says something vague, ask for the story behind it. "It is annoying" is not data. "I had to export to a spreadsheet every Friday because the report does not show last quarter" is data. And do not defend your product. If someone misunderstands what you built, that is a finding, not an argument to win.

How to turn interviews into decisions

Notes you never reread are wasted interviews. Right after each call, I write down three things: the problem in their words, the workaround they already use, and one thing that surprised me. After a batch of five or six, I look for what repeats. A problem three people described independently is real. A problem one person mentioned with great passion is a maybe.

The honest test is whether the interviews changed anything. If you ran ten conversations and your roadmap looks identical, you were probably hearing what you wanted to hear. When we were working through onboarding on Peerlist, the interviews that mattered were the ones that made me delete something I was attached to.

The mistakes I see builders make

Stopping at the first answer. The first thing someone says is the polite version. The real answer is two follow-up questions deeper.

Forgetting to act. Interviews are cheap to run and easy to forget. If they do not change a decision, you ran a ritual.

A few questions worth answering

How do I conduct user interviews if I have no users yet? Go to the communities where people with the problem already spend time. Send a short, specific message asking for fifteen minutes, and be clear you are not selling. Ask how they handle the problem today.

How many user interviews should I do? Usually five to eight per group is enough to see patterns. When the same themes keep repeating, you can stop. If every conversation is wildly different, narrow who you are recruiting.

What questions should I ask in a user interview? Ask about specific recent events, not hypotheticals. "Walk me through the last time you did X" beats "Would you use X." Past behavior predicts future behavior. Stated intentions do not.

What are the main types of user interviews? Broadly: problem interviews before you build, usability interviews while you build, and churn or retention interviews after you launch. The format is similar. The goal is what changes.

Should I record user interviews? Yes, if the person agrees. Recording frees you to listen instead of typing, and you catch the exact phrasing later, which is the part that matters most. You can use AI note taker apps if you want to even improve this flow.

How long should a user interview be? Thirty minutes is plenty. Longer calls drift into feature wishlists. Keep it tight and you keep it honest.

Action items for you

Book three calls this week. Ask people to walk you through the last time they hit the problem you are solving. Then take notes and stay quiet. That one habit has changed more of my product decisions than any dashboard.