Customer Interview

For a long time, what to build got decided inside the meeting room. A line sales heard from one account, an idea the founder had over the weekend, and an annoyance an engineer felt all sat side by side, and with no way to tell which one was right, the loudest voice won.

Meetings kept stalling in the same spot. Someone says "customers want this feature," someone else asks "which customers," and the answer comes back as "one of them mentioned it last month." A single remark and a widespread need were never separated, quarterly plans got built on top of that, and features nobody opened shipped anyway.

Customer interviews exist to put a record in that gap. You meet the people who use the product, hear what they went through, and bring their words into the meeting with a source attached. Within user research, this sits on the qualitative side — the qualitative research branch that works out why people behave the way they do through what they say and what you watch them do.

The direction of the questions is what makes the method work. You don't ask whether someone would use a feature if it existed. You ask how they handled the task the last time they did it, which was probably last week. The first question gets an answer about an imagined future; the second gets an answer about something that happened. The same person answers those two with wildly different accuracy.

One round usually takes two weeks and breaks into five steps.

1. Write down what you want to know as a single question. "Understand our users" doesn't tell you what to ask. Narrow it to something answerable, like how teams that create folders and then ignore them go about finding a document.
2. Write the criteria for who to ask, then go find those people. Something like: managers of teams of five or more who created ten or more documents in the last month. Finding participants who match is called research recruiting, and half the schedule disappears into it. Book two or three more people than you need, because some won't show up.
3. Write the questions in advance. Replace anything that ends in yes or no with questions about how they handled it at the time, and prepare roughly ten of them.
4. Run the sessions. Each one runs 45 minutes to an hour, and one person leads while another takes notes. Alone, you lose what you just heard while picking the next question.
5. Synthesize, then connect it to a decision. Group the quotes by theme and write down how many people each theme came from. A theme from six of eight people and a theme from one person get handled differently. End with what you'll change, what you'll investigate further, and what you decided not to change. Without that last line, all you have is a report.

The value peaks before the decision splits. When the direction has forked and nobody knows which branch is right, or when a shipped feature sits unused and nobody knows why, interviews earn their two weeks. Both are "why" questions, and the answer only exists inside someone's head.

Other methods answer some questions faster. If you need a percentage, that's a survey — the same question put to many people so you can see the distribution — or quantitative research more broadly. Questions already answered in your own records aren't worth recruiting for either. The share of people who abandon the signup screen is one query away, and eight people in a room won't reproduce that number after two weeks of work.

The limits come from memory. Few people recall exactly what they did last week, and everyone shades their answers toward whoever is sitting across from them. Answers about future behavior are close to worthless: of ten people who say they'd use something, two typically do. Where words and behavior might diverge, confirm by watching instead. Field research, which goes to the place the product gets used and takes in the whole context, and diary studies, where people log their own usage over a couple of weeks, cover that ground.

Sample size is a limit too. Meet five to eight people who match the same criteria and the same statements start repeating; past that, twenty people teach you almost nothing new. What you can't do is turn any of it into a percentage.

"That's not a decision for this meeting. Let's run five or six customer interviews and then decide."

We're splitting on opinion with no evidence, so go talk to people.

"Six of the eight said the same thing. This isn't one person's complaint."

The problem repeats; it isn't a single unhappy account.

"They told us in the interview they'd use it, but it isn't showing up in the logs."

Words and behavior disagree, so stop treating the words as evidence.

At Pagedeck, Mia runs a round once a quarter. After seeing that half of the teams that convert to paid barely create documents in their second month, she pulled together eight managers who matched that pattern and met each of them for 45 minutes. The question wasn't which features they wanted — it was how they found a team document the last time they looked for one. Six said they skipped search and asked for the link again in chat.

Noa took notes, capturing the wording as spoken, and after all eight sessions the two of them grouped the quotes by theme. That grouping is why search improvements moved up the roadmap the following quarter.

The first mistake is thinking you ask customers what they want. "Build what customers want" gets repeated so often that asking it literally sounds like the method. People can't describe something that doesn't exist yet with any precision, though. Building the requested feature exactly as described and watching it land at three percent adoption starts here. The thing to ask about isn't the feature they want but what they were trying to do and where it stopped working.

The second is converting interview findings into percentages. "Six of eight" turns into "75 percent" somewhere between the notes and the report, because a number reads as more persuasive. But eight people were never a sample drawn to represent everyone — they were eight people who matched a set of criteria. That a feature funded by that 75 percent was a 10 percent problem for the whole user base only becomes visible after launch. When you need a percentage, the order is to build the hypothesis in interviews and measure it in a survey.