User interviews validate nothing

User interviews are one of the most useful tools I know and one of the worst used. The problem is not the technique, it is what they get used for: most of the time somebody goes out to interview when they have already decided what they are going to build, and what they are really after is permission.

An interview is for understanding how somebody lives with a problem. It is not for validating an idea, and treating it as though it were is the most elegant way of fooling yourself I have found in this job.

Why they do not validate

Opinions about ideas are kind by default. When you show somebody something you made, that person is not evaluating your product: they are managing an awkward social situation in which a stranger has asked them to judge his work. Saying it does not sound good carries an emotional cost almost nobody is willing to pay with someone they have just met.

On top of that you are asking about the future. Would you use this and would you pay for this ask a person to predict their own behaviour, and people are terrible at that. Not through dishonesty, but because the version of us answering in a quiet room is not the one deciding on a Tuesday at six with fifteen things outstanding.

What they are good for

They are good for finding out what already happened. What that person did the last time they ran into the problem, how long it took, what they tried first, why they gave up. All of that is fact, and facts cannot be dressed up out of politeness.

They are also good for finding the vocabulary. What people call the thing that happens to them, in the words they reach for when nobody is suggesting any. That ends up being the text on your home page, and not by accident: it is the only part written in the language of the person with the problem.

And they are good for finding workarounds. The improvised system somebody has built for themselves in a spreadsheet is the strongest evidence you will get that the problem is real, because nobody spends their own time solving something they do not care about.

How I run them

I do not explain my idea until the end. The moment you describe what you plan to build, the conversation stops being about that person life and becomes about your proposal, and from there you will only get opinions.

I always ask backwards. When was the last time. What exactly did you do. How long did it take. What had you tried before that. If somebody cannot remember the last time they had the problem, I have just found out in thirty seconds that they do not have it as often as I thought.

And I write the sentences down as they came out, even when they sound untidy. Rewriting them neatly organises them and strips out everything that did not fit my framing, which is usually the part that would have changed my mind later.

How many you need

Fewer than people tend to say. Eight or ten conversations and the pattern shows up, and from there the same phrases start repeating. When the third one in a row tells you nothing new, you are done.

What does not work is doing two and calling the conclusion sound, or doing forty in the hope that the number substitutes for judgement. Qualitative research does not work by volume, it works by saturation, and that threshold is much lower than it looks.

Questions people ask about this

How do I validate a business idea then?

With behaviour, not statements. Somebody leaving an email address, reserving a place, paying up front, using a manual workaround you put together by hand. Any action that carries a cost, however small, says more than a hundred conversations.

How many user interviews are enough?

Eight to ten to see patterns within one profile. If you are covering two very different profiles, count eight of each. What marks the end is not the number, it is running out of new things to hear.

Can I interview people I know?

You can, but discount what they say. Somebody who knows you has an extra reason to be kind and already knows what you want to hear. They are useful for rehearsing the questions, not for drawing conclusions.

What if nobody has the problem?

That is a result, and a good one. You found out in two weeks what building would have taken six months to teach you. The expensive part is not discovering there was no problem, it is discovering it after you have solved it.