How to Talk to Users (and Actually Learn Something)

You know you are supposed to "talk to users." Everyone says it. So you finally work up the nerve, you get someone on a call, you describe your idea, and you ask the big question: "Would you use something like this?" They say yes. They say it sounds great. They might even say they would pay for it. You hang up feeling fantastic, you build the thing they described, and then nobody buys it. What happened is not that they lied to hurt you. They lied to be nice, because you asked a question that has only one polite answer.

This is the single most avoidable mistake in early-stage building, and it is entirely fixable. You do not need charisma or a sales background. You need to stop asking people to predict their own future and start asking them about their actual past. That one shift turns a feel-good chat into an hour that can change what you build. Talking to users the right way is probably the highest-payoff hour in your whole week, and most builders skip it because it is uncomfortable and does not feel like "real work" the way writing code does.

Where does the money actually come from?#

Talking to users does not make money directly. It makes money by stopping you from building the wrong thing, and by starting a relationship with the exact people who will become your first customers. The same conversation is research and the opening move of a sale. Here is the chain.

You find people who plausibly have the problem
  ↓
You ask about their past behavior, not their future intentions
  ↓
You learn what they actually do, what it costs them, what they tried
  ↓
Some of them clearly have the problem badly enough to pay
  ↓
You build (or fix) for that specific pain, not a guess
  ↓
You go back to the people who had it worst: "I built the thing"
  ↓
A few become your first paying customers and tell you what is next

Notice that the money is at the bottom, but the whole outcome is decided at the top. If you talk to the wrong people or ask the wrong questions, everything downstream is built on a bad guess, and no amount of coding saves it. If you talk to the right people and listen, even a rough product finds buyers, because you built it for a problem you watched someone struggle with. This is the same mechanism under every early business: revenue comes from solving a real problem for a real person, which is worth internalizing in where does online money come from. For how these first conversations sit inside the whole picture, how making money online works lays out the shape.

How it works: ask about the past, not the future#

The core rule comes down to one habit. Every time you catch yourself about to ask a hypothetical, swap it for a history question.

Bad question: "Would you use a tool that automates your invoicing?" Good question: "Walk me through the last time you sent an invoice. What did you actually do?"

Bad question: "Do you think you would pay for this?" Good question: "What are you paying for right now to deal with this, if anything?"

Bad question: "Would a feature that does X be useful?" Good question: "Tell me about the last time you needed X. What did you do instead?"

The good versions all point at something that already happened. A person cannot flatter you with a fact. If they never invoiced anyone, the story falls apart on its own and you have learned the problem is not real for them. If they describe a painful thirty-minute ritual involving three tabs and a spreadsheet, you have learned the problem is real, expensive, and unsolved, all without asking a leading question.

A few moves make the history come out cleanly:

• Ask for the specific last instance, not the general habit. "How do you usually handle X" invites a tidy, idealized answer. "What did you do the last time X happened" gets you the messy truth, including the workaround they are slightly embarrassed by.
• Chase the cost. When they describe a problem, find out what it cost them: minutes, dollars, a lost customer, a Sunday night. Cost is how you tell a mild annoyance from a bleeding wound. You only want to build for wounds.
• Ask what they already tried. If they have googled it, bought a tool, cobbled together a script, or asked a friend, the problem is real enough that they spent effort on it. If they have never once looked for a solution, sit with that. It usually means the pain is not big enough to open a wallet.
• Shut up and let silence do the work. After they answer, wait. People fill silence with the real detail they were about to skip. Your instinct will be to jump in and pitch. Don't.

Concrete move: write your interview questions down before the call, and read each one back to yourself asking "can they answer this with a story about something that already happened?" If not, rewrite it until they can.

A worked example (hypothetical numbers)#

Say you want to build a tool that helps freelance designers get paid faster. Here is a made-up but realistic version of the two ways a conversation can go. Every number below is invented to illustrate the point, not data from a real study.

The wrong way. You get a designer on a call and say: "I'm building an app that automatically chases late invoices. Would that be useful?" She says, "Oh yeah, that sounds really helpful, I hate chasing people." You mark it a win. You build for two months. At launch she does not sign up, because in reality she has four clients, they all pay on time, and late invoices were a mild irritation she mentioned to be agreeable.

The right way. Same designer, different questions. "Tell me about the last invoice that got paid late." She lights up: "God, the November one. Client ghosted me for five weeks. I emailed three times, felt like a nag, eventually threatened to stop work." You ask what it cost her. "About two thousand dollars stuck for over a month, and honestly the stress was worse than the money." You ask what she tried. "I bought a contract template, and I looked at some invoicing apps but they were forty a month and felt like overkill." Now you know: the pain is real, it hit around two thousand dollars, she felt social discomfort (a huge motivator), she already reached for her wallet, and price sensitivity sits below the forty dollar tools she rejected.

That second conversation did two jobs at once. It validated the problem with a concrete story, and it ended with a natural next step: "I'm building exactly this. Can I show you the first version when it is ready?" She says yes, and she means it this time, because you were talking about her actual November, not a hypothetical. Five conversations like that and you have both a spec and a launch list. That is the double payoff, and it is why this hour beats almost anything else you could do.

What you need and what it costs#

Required:

• A short list of people who plausibly have the problem. Five to ten to start. Not "everyone," a specific type of person. Getting this list right is its own skill, covered in pick a narrow first segment.
• A written set of past-focused questions. Six or seven is plenty. You will not ask them all in order; they are a safety net so you never drift into hypotheticals.
• Thirty minutes of your attention per conversation, and the discipline to listen more than you talk. The whole cost here is emotional, not financial.

Optional:

• A note-taking method (even a text file open during the call). Write quotes verbatim; exact words carry more signal than your summary.
• A recording, with permission, if you want to re-listen. Useful but not required.
• A tiny thank-you, like a gift card, if you are asking a lot of someone's time. Nice, never necessary.

The dollar cost is basically zero. The real cost is that it feels awkward and slow, and it does not produce a commit in your repo. That is exactly why so few builders do it, and exactly why doing it is an edge.

Concrete move: block a single recurring hour in your week for this and protect it like a deploy. One hour, one or two conversations, every week.

How long it takes#

A single conversation is twenty to thirty minutes. You start noticing patterns after about five, and by ten you usually have a clear sense of whether the problem is real and who has it worst. That is days of calendar time, not weeks, if you actually schedule them. The bottleneck is almost never the conversations themselves; it is the two weeks you spend not sending the messages because it feels intimidating. Reaching out is its own small skill, and cold DMs that aren't spam covers how to get the first replies without feeling like a spammer.

Concrete move: send three outreach messages today, before you touch any code. Not tomorrow, today. The conversations can only start once the messages are out.

What beginners get wrong#

• Pitching instead of listening. The whole point is to learn, and you cannot learn while you are talking. If you spend the call describing your idea, all you get back is politeness. Describe the idea last, or not at all.
• Asking leading questions. "Don't you hate how slow that is?" tells them the answer you want. Ask "how do you feel about that step?" and let them supply the emotion, or not.
• Talking to friends and family. They love you, so they lie to you, kindly. You need people with the problem, not people who want you to feel good.
• Treating compliments as validation. "That's a great idea" is not a fact and not money. Watch what people have actually done, not what they say about your idea. This is the heart of validating properly, laid out in validate your idea before you build.
• Only talking to people once and then hiding in the code for three months. These conversations are ongoing. The people you talk to now are your launch list later.
• Doing it after you build instead of before. The order is talk first, build second. Reversed, you are just looking for reassurance about a decision you already made.

Concrete move: before your next call, delete every question that mentions your product. If the person never learns what you are building, you can still have a useful conversation. That is the test.

How I would start#

If I were starting from zero this week, here is the exact sequence I would run.

First, I would pick one narrow type of person, not a broad market. "Freelance illustrators who invoice international clients," not "freelancers." Narrow makes it obvious who to message and what to ask.

Second, I would write seven questions, all about the past, and I would run them past the "already happened" test. Anything hypothetical gets cut or rewritten.

Third, I would find five to ten of these people where they already hang out: a subreddit, a Discord, a Slack, a hashtag. Reddit especially is full of people describing their problems in detail because they are asking for help, which doubles as research (see mine subreddits for topics people want).

Fourth, I would reach out one to one, lead with genuine curiosity rather than a pitch, and ask for fifteen minutes. Then on the calls I would ask about last time, chase the cost, ask what they tried, and stay quiet.

Fifth, I would end every call with "can I come back to you when I have something to show?" and I would keep a list of the people whose problem was worst. That list is my first launch, and it flows straight into founder-led sales in your first 100 conversations.

Concrete move: do step one right now. Write down the single narrowest description of your target person you can defend. Everything else gets easier once that sentence exists.

What I would not do#

I would not run surveys as a substitute for talking. A survey full of "how likely are you to use this on a scale of one to five" gives you tidy numbers that mean nothing, because it is hypothetical questions at scale. Talk to ten people before you send a form to a hundred.

I would not ask a group. One-to-one is where honesty lives. In a group, people perform for each other and mute the specific, embarrassing, valuable detail.

I would not treat a single enthusiastic call as proof. One person with the problem is a lead, not a market. Look for the pattern across several before you commit code.

And I would not wait until the product is "ready" to start. The conversations are most valuable before you have built anything, when they can still change your direction instead of just confirming it.

The close#

Talking to users is not a soft, optional, nice-to-have activity you get to once the "real" work is done. It is the work. An hour spent asking the right person about their actual last week can save you two months of building the wrong thing, and it hands you a short list of people who already told you, in their own words, exactly what they would pay to fix. Ask about the past, chase the cost, listen more than you talk, and end every conversation with a door left open.

Do that, and research and selling stop being two separate scary things. They become the same conversation. When you are ready to turn these first talks into paying customers, our first customers hub is where to go next.