Talking to Users

You built it, people are using it, and now you want to know what to fix. So you ask: "What do you think?" And you get back: "Looks great!" — which tells you absolutely nothing and feels wonderful.

This is the trap. Most feedback is polite noise, and polite noise is dangerous because it feels like progress while teaching you nothing. Getting useful feedback is a skill, and it's mostly about asking better questions and shutting up afterward.

Why people lie to you (nicely)

Users don't lie to be cruel — they lie to be kind. They don't want to hurt your feelings, they want the conversation to end pleasantly, and they genuinely don't know what they'd do in the future. So they default to encouragement.

This means three of the most natural questions are also the most useless:

• "Do you like it?" — they'll say yes.
• "Would you use this?" — they'll say probably.
• "Would you pay for it?" — they'll say maybe, and mean no.

All three ask people to predict their own future behaviour, which humans are terrible at. The fix is to stop asking about the future and start asking about the past.

Ask about the past, not the future

Past behaviour is real evidence. Future intention is a wish. So aim every question backward:

• Instead of "would you use a tool for X?" → "When did you last deal with X, and what did you do?"
• Instead of "is this useful?" → "Walk me through the last time you had this problem."
• Instead of "would you pay?" → "What do you use now, and what does it cost you?"

You're collecting facts about what actually happened, not opinions about what might. Facts don't flatter, and they don't lie.

Watch them use it — and say nothing

The most honest feedback isn't spoken. Sit a person in front of your product, give them a real task ("try to add your first invoice"), and then be quiet. Don't guide them. Don't explain. Just watch.

Where they hesitate, where they click the wrong thing, where they squint and say "wait, what?" — that's your bug list, and it's brutally honest because they're not performing for you. The hardest part is your own silence. Every instinct will scream to help. Don't. Their confusion is the data.

Separate the complaint from the request

When users do suggest things, take the problem seriously and the solution lightly. People are great at telling you where it hurts and bad at prescribing the cure.

"I want a button here" might really mean "I couldn't find how to do X." The button is their guess at a fix; the lost feeling is the real signal. Dig underneath every feature request to the problem that spawned it — then solve the problem your own way, which is often simpler than what they asked for.

Five conversations beat five hundred survey responses

You don't need scale to learn. Five real conversations with people in your target audience will teach you more than a survey with five hundred checkboxes. Surveys give you the answers to questions you already thought of. Conversations surface the things you didn't know to ask — and those are the ones that change the product.

Talk to five people this week. Ask about their past, watch them struggle in silence, dig past their suggestions to their problems. Then build for what you saw, not for what they said. That gap — between what people say and what they do — is where most products go wrong, and noticing it is one of the most valuable skills a builder can have.