Do not ask people to design your product for you

The fastest way to get polite but weak research is to ask someone, “Would you use this feature?” Most people are trying to be helpful. They will answer from imagination, give advice, and say yes to an idea that never has to compete with their real day.

A better interview starts with something that already happened.

“Tell me about the last time you had to follow up after a meeting.”

“What did you do first?”

“Where did the information go?”

“What made it difficult?”

Those questions move the conversation away from a hypothetical product and toward the messy details that a product needs to respect. The calendar, the notes app, the half-written message, the CRM field that was skipped: that is where the useful evidence is.

Look for behaviour, not applause

When I am speaking to an early user, I am not trying to collect validation. I am trying to understand the job they are already doing and the workaround they have built around it.

Someone saying “that sounds useful” is a weak signal. Someone showing how they copy meeting notes into three places because they are afraid of forgetting a follow-up is a strong signal. It reveals frequency, stakes, existing tools, and the cost of the current process.

Nielsen Norman Group’s User Interviews 101 makes the same distinction: interviews are for understanding attitudes, needs, and context, but the quality of the result depends on asking about actual experience rather than steering a participant toward an answer.

Keep the questions open long enough to surprise you

An interview should contain a point where the person says something you did not expect. If every answer fits the feature you planned to build, the questions were probably too narrow.

I use three simple moves:

  1. Ask for the last specific example, not the usual process.
  2. Ask what happened next until the real handoff appears.
  3. Ask what they tried before, including what failed.

The third question is especially valuable. Existing workarounds tell you what a person has already been willing to do. If they use a spreadsheet, an assistant, a template, or a recurring reminder, that is evidence of a recurring job. If they have tried nothing, the problem may not be urgent enough yet.

Separate the problem from the proposed solution

People can describe their work extremely well and still suggest a solution that is too specific to their current tool. That is normal. Your job is not to ignore the suggestion; it is to find the underlying need.

For example, “I need an AI summary after every call” might actually mean:

  • I forget what I promised.
  • I lose time turning notes into tasks.
  • I do not trust that the CRM is up to date.

Those are different problems. They lead to different product choices. A summary may be part of the answer, but it is rarely the entire workflow.

End with a decision, not a pile of notes

Research only earns its time when it changes what happens next.

After each interview, I write four lines before looking at another conversation:

  • The job the person was trying to complete.
  • The moment where the process broke down.
  • The evidence that the problem mattered.
  • The product decision it may change.

That last line matters. It might be “test a simpler follow-up flow,” “do not automate this without review,” or “this customer is not the first audience.” The decision can be small, but it should be explicit.

The standard for a good interview

A good interview does not make you feel more certain about your product. It makes you more precise about the person’s problem.

That precision is what lets an early team make fewer invented decisions, write clearer product copy, and build a workflow that meets someone where their work actually happens.