As a product manager, there’s nothing more important than having a single source of truth for discovering problems or opportunities. That source of truth is the customer. This isn’t rocket surgery to be honest but with this post I do intend to emphasise on why speaking with customers is an essential part of the product development lifecycle. Over the past year, I’ve averaged at least one customer interview per week and I still feel I should’ve done more. These interviews were in the form of job-shadowing, discovery, UX research and prototype testing. While each of these types of interviews are different, the end goal is always to ensure that you are solving a real problem for the customer and that when you go to market with a product, you ensure some amount of predictability for its success.
We’re all familiar with the product lifecycle development stages, right? Well, here’s a simplified version that I have I created where I mention the various touch-points where customer interviews play a crucial role.
Like any interview you undertake, preparation is important. Here are some of my learnings that I think anyone new or experienced at customer interviews might find useful.
Before talking to the customer/user, it’s important to get as much context about who she is. You want your segmentation research to give you an idea on who she is, how long has she been using your product, how active is she and how much is she paying for it. This will help you make assumptions on what drives her to use (or not use) your product.
Have a script ready
It’s always handy to have a script prepared on what questions you plan to ask the user. This not only helps you bring a structure to the interview but as you interview many users, a script ensures that the same research methodology is applied in the entire set of interviewees.
Avoid leading questions
Leading questions would probably form an entire chapter in a book about doing good customer interviews. However, if I were to extract the gist of it, it could be simply put as - “Avoid questions that can be answered with a yes or a no”. Leading questions do not add value to the research process as you fail to understand factors influencing users’ decisions or their emotional state. The answers you seek in interviews should not be biased by the questions but rather you want customers to open up about their experiences. For example, if you ask a user - “Are you having problems with our product X?” The answer could be a curt ‘no’ or a ‘yes’. But if you frame the question as “Can you walk me through how you use our product X?” The latter helps pinpoint the journey of the user and the “problems” that you seek will be revealed in due course of time with follow-up questions. Refer to the next point below on the five whys.
The five whys
This is a simple yet effective technique to get to the bottom of a problem. It was first conceived in the Toyota production facility for identifying bugs. In the interview setting, it is brutal and unrelenting when used in the right manner. The short version of how this is done is when the interviewer persistently quizzes the user with a “why?” and follows that with another “why?”. At times, insights are derived before the fifth why is asked but it’s the process that matters more. This could be an example of asking the five whys:
Me: You’ve been using our product X for 2 years now. Can you walk me through how you interact with feature Z.
User: I actually don’t use feature Z.
Me: Why don’t you use feature Z?
User: I don’t know, it looks complicated.
Me: Why do you think it is complicated?
User: I visit the page and I see a lot of text that I don’t understand.
Me: Alright, why do you feel that way?
User: English is not my first language and I also prefer to see a tutorial video to understand how to use a new feature
. …and the process continues but I hope you catch my drift.
Don’t listen to the user’s solutions
It’s easy to fall prey to what the user/customer says about your product. The caveat here is that the customer is not always right. It is imperative as an interviewer to understand what problem the user is facing rather than accepting the solution the user instructs you to build. This is a fairly common occurrence where users lay out feature-flows and solutions down to the tiniest details. But as a product manager, you are solving problems for an entire customer/user base, not just one person who gives her version of the solution.
Record, record, record
Record your interviews in one way or the other. If it’s an interview that is happening over video call, then you can ask the user’s permission to record the session. Or else if you have a co-interviewer who can observe and take notes during the interview, that is another good option. If all else fails, you need to brush up on your note-taking abilities. You wouldn’t want to miss out on key insights during the interview process that you can revisit at a later time.
When do you stop interviewing
This is quite a common question that comes up. Just how many customer interviews is enough? The unfortunate answer is that it’s never enough. But my general thumb rule is to interview as many people within a particular time period and you should stop interviewing when you see a pattern developing in your responses. In short, stop interviewing when you stop seeing variability for that set of customer interviews.
On a closing note, these learnings and observations have happened over a course of time and I hope you found them useful. While researching this topic on the interwebz to see other people’s opinions, I also came across a very useful chart on conducting interviews at the Product Tribe which is quite share-worthy.
Until my next post, happy interviewing!