Talking to users sounds like one of the easiest parts of building a product.

You ask what they think. They tell you. You improve the product.

Unfortunately, user research rarely works that neatly.

People are polite. They want to be helpful. They struggle to predict what they would actually buy. They may tell a founder that an idea sounds amazing and then never use it. And founders have their own biases: when you have spent months building something, it is surprisingly easy to ask questions designed to confirm what you already believe.

The goal of a good user conversation is therefore not to collect compliments.

It is to understand what people actually do, what frustrates them, what they value, and what they care about enough to change.

Ask about the past, not the imaginary future

One of the weakest questions you can ask a potential customer is:

“Would you use a product that does this?”

The answer will often be yes.

There is almost no cost to saying yes to a hypothetical product.

Instead, ask about what the person has already done.

“When did you last experience this problem?”

“What did you do about it?”

“How often does this happen?”

“Have you paid for anything to solve it?”

Past behavior gives you much stronger evidence than future intentions.

Imagine someone tells you they would “definitely” pay €30 per month for a better productivity tool.

That sounds promising.

Then you discover they have never paid for productivity software, currently use a free spreadsheet, and do not consider the problem important enough to search for alternatives.

That context changes the meaning of the original answer.

Get them to tell you stories

Specific stories are much more useful than general opinions.

Instead of asking, “Is managing invoices difficult?” ask, “Tell me about the last time you had a problem with an invoice.”

Now the customer has to describe reality.

Perhaps they explain that a client paid 45 days late, they forgot to send a reminder, and they eventually had to search through old emails to find the original invoice.

That story gives you details.

You can ask what happened next. How did they solve it? How long did it take? What was frustrating? Did it cost them money? Did anyone else become involved?

These details help founders understand not only that a problem exists, but how the problem fits into someone’s actual life or workflow.

That is where useful product ideas usually appear.

Stop pitching during research conversations

Founders naturally want people to understand their product.

That instinct can ruin a customer interview.

The moment you begin explaining why your solution is brilliant, the conversation changes. The user stops describing their world and starts reacting to yours.

If you say, “We’re building an AI platform that automatically handles this entire process. Would that be useful?” you have already influenced the answer.

Most polite people will find something positive to say.

Instead, spend most of the conversation listening.

Ask how they currently solve the problem. Ask what they like about the existing solution. Ask what they hate. Ask what they have already tried.

You can explain your product later.

Research is most useful when customers forget they are supposed to be evaluating your idea and simply start talking about their own experience.

Ask uncomfortable follow-up questions

The first answer is rarely the whole answer.

A customer says, “This takes too much time.”

How much time?

“Probably several hours.”

How often?

“Maybe once every few months.”

Suddenly the problem may be less urgent than it initially sounded.

Or perhaps someone says their current software is terrible.

Why have they continued paying for it for five years?

Maybe switching would require migrating thousands of records. Perhaps everyone on the team already knows how to use it. Maybe it integrates with another critical system.

Now you have discovered that your real competitor is not simply another product.

It is the cost of switching.

Good interviews involve gently digging underneath broad statements until you understand what they actually mean.

Pay attention to what users do, not only what they say

Sometimes the best user research involves very little interviewing.

Watch someone use the product.

You might think your onboarding process is obvious because you designed it. Then you watch a new customer spend 30 seconds searching for the button you assumed nobody could miss.

Do not immediately help them.

Observe.

Where do they hesitate? What do they click first? Which words confuse them? What do they expect to happen?

Behavior exposes problems customers may never mention in an interview.

A user might tell you the product is “easy to use” and then struggle through six different screens trying to complete a basic task.

Both pieces of information matter, but the behavior is often more actionable.

Learn to recognize strong signals

Not every piece of feedback deserves equal weight.

“I like this” is a weak signal.

“Can I start using this with my team next week?” is stronger.

“I would pay for this” is interesting.

“Where do I enter my card?” is stronger.

“This problem is annoying” tells you something.

“We currently pay €800 per month for someone to solve this problem manually” tells you much more.

Strong signals usually involve behavior, money, time, urgency, or commitment.

Customers who have already invested significant resources trying to solve a problem are demonstrating that the problem matters.

That does not automatically mean your solution is right.

But it is much stronger evidence than enthusiasm alone.

Do not build every feature customers request

Talking to users does not mean turning the product roadmap into a voting system.

Customers are excellent sources of information about their problems.

They are not always the best people to design the solution.

A customer might ask for an export button because they constantly move information into a spreadsheet. The obvious response is to build the button.

But ask why they need the spreadsheet.

Perhaps they are creating a report your product could generate automatically.

The requested feature was an export button.

The underlying need was reporting.

Understanding that distinction allows the product team to solve the deeper problem rather than simply collecting feature requests.

Talk to people who left

Founders naturally prefer speaking with happy customers.

Unhappy customers can be more educational.

Talk to people who stopped using the product, canceled their subscription, abandoned onboarding, or chose a competitor.

Ask what happened.

Do not try to win the argument.

Perhaps the product was too expensive. Maybe an essential feature was missing. Perhaps onboarding was confusing. Maybe they were never the right customer in the first place.

Churned users can reveal weaknesses that loyal customers no longer experience or have learned to tolerate.

Even people who never became customers can be useful.

Understanding why someone said no can sharpen positioning, pricing, targeting, and product decisions.

Look for patterns, not individual opinions

One customer asks for dark mode.

Another wants a mobile application.

A third wants 15 new integrations.

If you react to every conversation independently, your roadmap becomes chaos.

Instead, collect feedback and look for repetition.

What problems appear again and again? Which customer segments mention them? How severe are those problems? What are customers currently doing to solve them?

Patterns matter more than volume alone.

Ten casual requests from poorly matched users may be less important than three urgent complaints from your highest-value customer segment.

User research requires judgment.

The goal is not to satisfy every person you interview. It is to understand the market well enough to decide which problems deserve attention.

The best conversations change what you believe

A successful user interview does not end when someone tells you your idea is brilliant.

It ends when you understand something you did not understand before.

Maybe the problem is more urgent than you thought. Maybe customers use completely different language to describe it. Perhaps your target audience is wrong. Maybe the feature you considered essential barely matters.

Sometimes the most valuable conversation is the one that proves your assumption wrong.

That can be uncomfortable, especially when you have already invested time and money in the product.

But discovering the truth after ten customer conversations is much cheaper than discovering it after two years of building.

That is the real purpose of talking to users.

Not to hear that you are right.

To find out where you are wrong while there is still time to do something about it.