5 lessons I learned after conducting 100+ customer interviews

I’ve spent the past few years of my career conducting numerous customer interviews. Initially, I was worried about spending precious time efficiently, and it was frustrating to realize that I didn’t always get the insights I was aiming for. However, these experiences have been invaluable. Effective customer interviews are crucial for successful product development and strategy. One of my favorite ideas from the Marty Cagan’s famous book Inspired is

“Customer don’t know what’s possible, and with technology products, none of us know what we really want until we actually see it”.

It emphasizes how it’s our job as product managers to make sure the solution we are building solves the real problem, and customer interviews is one of the critical tools that helps achieve that goal. With that in mind, I’d like to share a few lessons I’ve learned to help you make the most out of your customer interviews.

Understanding why you are conducting research and the different methodologies applicable for different purposes is crucial. Advanced researchers might find this an oversimplification, but generally, you might be doing one of the following:

While interviews are primarily exploratory, they can sometimes provide qualitative validation of certain hypotheses when combined with other data. The boundaries between exploration and validation can be fluid, so it’s essential to understand when and how to use interviews effectively.

When crafting interview questions, you naturally formulate them in a way that makes sense to you. However, the people you are interviewing might react differently to your questions. You won’t always guess or predict how everything will work. Questions that make sense to you might not give you the information you want or might confuse the interviewee. So, go ahead and arrange that interview, but when analyzing your interviews, don’t just summarize the answers—go back to your interview guide and see if it worked the way you intended.

How do you identify that the questions aren’t working? Beyond the obvious—when the interviewee doesn’t know what to say—here are some symptoms and how to fix the problem:

Analyzing interviews is more challenging than surveys—you can’t simply build pretty graphs to impress your boss. While visualizing quantitative data is a skill, the analysis of qualitative data from interviews requires careful consideration and planning.

To make interview results actionable, they need to be skillfully summarized and presented. But coming up with an analysis approach after conducting the interviews is nearly impossible. If you’re like me, you’ve probably seen promising research initiatives stall because of this. Therefore, it’s important to think about how you will summarize and derive takeaways, and share them with your team and stakeholders.

Consider using specific techniques for qualitative analysis, such as thematic analysis or coding qualitative data. For instance, you might categorize responses by themes or topics, and then code each interview transcript according to these categories. This will help you identify patterns and trends that can inform your product decisions.

A great starting point is to look at established methodologies or frameworks. Even if your task feels unique, most likely, someone has thought about it before and developed a framework that you can adapt. For example, if you’re looking to uncover market opportunities, you might conduct a jobs-to-be-done interview. There are comprehensive guides on not only how to run these interviews but also how to analyze them. Mike Boysen’s article "How To Get Results From Jobs-to-be-Done Interviews" is a great resource for gaining relevant insights.

The goal of the interview is to gather as much context as possible, so focus on encouraging expansive, detailed responses rather than yes/no answers. It might feel awkward to ask a simple open question without showing that you know what the options are—but fight this temptation. If you ask the customer if they think your feature idea is good, they will most likely say “yes,” either because they believe you’ve thought it through or simply out of politeness.

Techniques that can help you on this journey include the "5 Whys" method, which digs deeper into the underlying reasons behind a user's behavior or preference. You don’t have to literally ask “Why?” five times, but the approach is helpful—prompt the interviewee to expand on their answer. The Jobs-to-Be-Done (JTBD) framework is another valuable tool that helps formulate questions to uncover the user's actual needs and motivations. For instance, instead of asking, "Do you like this feature?" you might ask, "Can you describe a situation where you found this feature particularly useful?" This approach elicits richer, more actionable insights by inviting users to share their experiences and thought processes.

When an interviewee struggles to respond to open-ended questions, provide context or examples to stimulate their thinking. You can gently prompt them by rephrasing the question or breaking it down into smaller, more manageable parts. Another effective technique is to use silence strategically, allowing the interviewee time to think and formulate their response. If necessary, shift to more specific, yet still open-ended, questions that guide them toward the broader topic.

When customers suggest specific features, it’s crucial to steer the conversation towards understanding their underlying needs and motivations. One effective way to do this is by employing the Jobs-to-Be-Done (JTBD) framework, already mentioned above. For instance, if a customer requests a new reporting feature, you can ask, "Can you tell me more about the type of insights you need from the reports?" In my experience working with IT reporting tools, I’ve often seen customers request new reports frequently, even when their needs could be met with slight modifications to existing reports or without any changes at all. Simply implementing their requests might lead to excessive work and a more confusing user interface, as the product becomes overcrowded with unnecessary features.

Alternatively, you should be able to notice patterns in these requests. Returning to the IT reporting example, if customers continually ask for more reports or filters, it might indicate a fundamental problem in interacting with the reports and gaining valuable insights. Recognizing this can lead to a more effective solution, such as redesigning the workflow for obtaining insights rather than adding more reports.

To systematically uncover the reasons behind feature requests, "5 Whys" is also a helpful method. Start by acknowledging the feature request and then explore the underlying motivation. Continue probing until you reveal the core need. You’ll know you’ve reached your goal when you identify a problem that’s not tightly related to your product but is indicative of your customer’s task or pain point. For instance, if a user requests a search function, ask how they plan to use it. The user might respond, "To find documents faster." This response already provides more information, but you can dig deeper by asking what the current document retrieval process looks like and how it prevents the user from achieving their goal. Continue until you uncover the fundamental issue, such as poor organization or high document volume, which might suggest a different solution altogether.

Of course, this is not an exhaustive guide to customer interviews for product managers. However, if you’re just starting your journey as a product manager or product analyst, these insights might help you avoid some of the mistakes I’ve made. Remember, every interview is an opportunity to refine your approach and deepen your understanding of your customers. Keep learning and iterating—your product and your users will thank you. Happy interviewing!