Almost every engineer I have taught has gone looking for a way out of user interviews. It is very common among technical people and it is not a character flaw, so here is the smallest version that still works: three interviews, recorded, with a script you wrote days earlier rather than on the day.

Three is enough to carry on with. Recording them means you are not trying to listen and write at the same time. Writing the script in advance means that when your mind goes blank in the call, which it will, the next question is already on the page.

I get nervous putting myself out there too. The way I handle it is structural rather than motivational: I do not rely on feeling ready, I rely on having the questions written down before I am in the room.

It is not your work being judged

The thing that makes these conversations bearable is understanding what is actually being tested.

It is not feedback on your idea, because at this point you do not have an idea, you have a guess. It is not feedback on your product, because there is no product. Nobody is assessing you. You are there to hear what someone's life is like, and to decide whether that person is the kind of person you want to build for.

Nothing is being evaluated except your assumptions.

The rules that make the conversation easy to run

Never ask what they want. People do not know what they need, and if you ask, you get surface answers. The single most common mistake I see in engineer-run research is asking people what they need. Listen to their story instead: how do you work, what is your day to day, what happens when someone phones, what do people get upset about, what do you love doing. The problems are inside the story.

Ask about the last time, not what they usually do. Ask about someone's diet and you get "mostly meat and veggies". Ask what their last meal was, then the one before that, and you get the truth. Same for any behaviour.

Do not describe your solution. If you do, everything after that is a reaction to your idea rather than a description of their life. If you want to show them at all, do it after the interview is over.

Steer away from your product. If they already use it, they will talk about it. Keep bringing them back to them. You are asking about their life, not about your app.

What to listen for, since "listen more" is useless advice

The hard part is hearing what they actually said rather than confirmation of what you already believe. People also want to be helpful, which is the worst, because you do not want a helpful answer, you want to hear somebody talk.

Concretely: the workaround they have built, the trade-off they accept and why, the moment their current tool breaks down, and the emotion attached to it. Then translate. Whatever they say the problem is, the problem is usually one layer under it.

The setup that removes most of the discomfort

• Write the script before the day. Open questions, in an order, with the tool-specific questions at the end so they do not bias the story part.
• Record it, video or audio if you can. A transcript gets you 75 to 80% of the way. What you lose is the smile that tells you it is not as serious as it sounded, or the long pause before an answer, which often means they had to think or were about to say something they knew was awkward.
• Take almost no notes. Roughly 5% of your attention on paper. You are not producing insights during the conversation, you are getting them to tell you stories.
• Bring a second person if you can. They will catch things you missed. Keep the same person asking the questions each time, so the questions stay consistent.
• An incentive is fine. Never cash, but a ten or twenty dollar gift card as a thank you is normal. It is a token, not a payment.

What about surveys, or getting an AI to do it?

I know why you are asking. Here is the honest ranking.

Interviews are the most valuable. Surveys cannot probe, cannot hear tone, and tend to produce aspirational answers rather than truthful ones, and it is actually harder to get enough survey responses to be useful than to get a few interviews.

An AI conducting the interview sits in between. You lose the human instinct, the tone, and the ability to steer, but people are often comfortable talking to it and you can tell it to probe. Call it half as good as you doing it, and sometimes half is enough.

The rule I give students is that if somebody will not do a live conversation, you work with what you have. Do not reach for the survey because you do not want to do the interview.

The smallest version, for when you are dreading it

Three interviews. Same kind of person. Recorded. One script. Start with "tell me about..." and let them talk for twenty minutes before you ask anything specific.

If you are nervous but not terrified, do them. You learn a lot from three. And the people you interview are often your first testers and your first users later, because they are already invested.

Keep reading

How Do I Validate an App Idea Without Building It?

How to Find Your First Users for a New App, Without a Following

The Real Reason Developers and Non-Technical Founders Fail at Exactly the Same Step

Learn this with me

User interviews are class 4 of From Passion to Product, my free six-week live course, which is the longest class in it. It covers who to interview, what to tell them and what not to, how to get people to say yes, the difference between direct and open-ended questions, what to listen for, what not to do, and what to do with the recordings afterwards. That is the part that makes it feel less like small talk and more like a job.

There is a live drop-in session timed for the week you are doing your interviews, for the questions that come up while you are in the middle of them.

I teach the same thing to engineering teams, as a one day workshop or a longer program, for the same reason: engineers who can run their own user research are harder to replace.

Join the waitlist, get the workbook, or look at the team programs.