Talking to users before you build anything

How to find 10 real prospects, what to ask, what NOT to ask. The Mom Test in practice.

6 min read·Updated Apr 28, 2026

Most builder advice tells you to "talk to users." Most builders do talk to users. They just do it badly. They pitch the idea over coffee, the friend says "yeah, cool, I'd use that," they go heads-down for three months, ship to crickets, and conclude that user interviews don't work. The interviews weren't the problem. The questions were.

Here's the single most useful idea in this whole space, and it's older than any startup blog: stop pitching, start asking about past behavior. People will lie about the future to be polite. They will not, generally, lie about what they actually did last Tuesday. If you ask "would you pay for a tool that does X," you will get a soft yes from almost everyone, because saying no to a friend's idea feels rude. If you ask "the last time you ran into X, walk me through what you did," they have to tell you the truth, because the truth is just a story about their week. This is the core of Rob Fitzpatrick's Mom Test, and it's the only framework you need at the start.

Finding 10 prospects without a network

You don't need a network. You need patience and a slightly thicker skin than usual.

Three places that work, in order of effort. First, the niche Slack and Discord communities you're already in. Not the giant ones. The 200-person ones where people recognize your handle. Post a short note: "Doing some research on how people currently handle [problem]. Looking for 15 minutes on a call, no product to pitch, just want to learn how you do it now." That single line will get you 3 to 5 conversations if the community is right.

Second, subreddits where people complain about the problem. Find the threads where someone is venting. DM them and say you're researching, not selling. Most will say no. Some will say yes, and those people are gold because they're already self-identified as having the pain.

Third, the coffee gift card lever. If response rates are slow, offer a 15 dollar gift card for a 20 minute call. It feels mercenary but it doubles your reply rate and the people who say yes for 15 dollars are not the people who will lie to you. They want the card and they want to get off the call, so they'll be direct.

Skip cold-DMing strangers on LinkedIn. The reply rates are bad and the conversations are worse, because the only people who answer cold are the ones who like getting cold messages, which is not your customer.

Questions that actually work

The pattern is always: past, specific, concrete.

Good questions sound like this. "Tell me about the last time you tried to do X." "Walk me through what happened next." "What did you try before that, and why did you stop?" "How did you find your current tool? What almost made you not pick it?" "Where did you get stuck this week?"

Bad questions sound like this. "Do you struggle with X?" (Yes, everyone struggles with everything, this tells you nothing.) "Would this be useful?" (Yes, hypothetically, in the abstract, sure.) "What features would help?" (Now you've turned the user into your product manager, which is not their job and they're bad at it.)

The asymmetry: good questions force the user to recall a real event. Bad questions invite them to imagine a hypothetical. Memory is honest. Imagination is polite.

Three questions to never ask

"Would you use this?" People say yes to be nice. The signal is zero.

"How much would you pay?" Nobody knows what they'd pay for something that doesn't exist. They guess high to flatter you or low to negotiate something that isn't being negotiated. Either way, the number is fake.

"What features would you want?" You're outsourcing the hardest part of your job to someone who has thought about the problem for 4 minutes. Their answer will be the average of every product they've ever used, and the average product is exactly what you don't want to build.

The signal that matters

You're not listening for "I'd use that." You're listening for evidence of an existing hack. Are they paying for a tool that almost solves it? Running a janky spreadsheet? Doing the work manually every Friday and resenting it? Asking a coworker to help? That workaround is the thing your product replaces, and the cost of it (in dollars, hours, or annoyance) is your ceiling on willingness to pay.

If they don't have a workaround, the pain isn't real. They've adapted, or they don't actually care, or it happens once a quarter and they've forgotten about it by Wednesday. No workaround, no product.

After the tenth interview

Sit down with your notes. You have three options and most builders only seriously consider two of them.

Commit, if a clear pattern emerged and the workarounds are expensive. Pivot, if the pain you found was adjacent to the pain you expected. Kill, if nobody has a workaround and the conversations felt like pulling teeth.

The mistake almost everyone makes is refusing to kill. They've already told friends about the idea, registered the domain, sketched a logo. So they squint at the data until it says yes. The next guide, "Killing ideas early without ego damage," is about how to do this without it feeling like failure, because killing fast is the single highest-leverage skill an early builder has.

Read that one before you pick your next idea.