Customer Interviews — A Primer
Customer interviews are hard, but they are essential for new product design. This article focuses on why you do customer interviews, what exactly you are looking for, and what to do next.
Why do customer interviews?
When you start with nothing but a hunch, then you need to hit the customer development trail hard. Many people dream up product ideas but few manage to execute on proving their idea.
In most cases, successful new products take an existing problem with an existing solution and they solve it in a better way.
Lean customer development means that you run intensive customer interviews to understand the customers’ problems, the existing solutions, and their current pain points. Lean customer development means you challenge your underlying hypotheses about your customer and product. Lean customer development means no coding. No coding until you’ve proven there are pain points you’re solving for and you can’t disprove your hypotheses.
As Cindy Alvarez writes in her book, Lean Customer Development “improves the odds” and helps startups, investors, and enterprises save on the trifecta — time, money, and resources — by enabling small experiments, a closer relationship with customers, and faster failure and learning.
What am I looking for?
Hopefully, you are now convinced of the value of doing customer interviews. So what are you trying to find out exactly? Here are 5 important components that you need to consider as you plan for your first interview and begin scripting your customer interview questions:
- Identify the problem
- Map out existing behavior
- Understand each persona
- Test hypotheses
- Check interest level
You should clearly define your customer’s problem and their existing solution.
Let’s unpack these:
1. Identify the problem — You should clearly define your customer’s problem and their existing solution.
What job is the person “hiring” the solution to do? People hire a drill to get a hole in the wall, an iPod to listen to music, and a thermostat to stay comfortable. Still unclear? You can learn more about Jobs to be Done (JTBD).
2. Map the customer journey — Your customer’s journey includes the steps, timeline, stumbling blocks, and feelings that the customer went through as they were addressing their problem. What are the actions the person took with their existing solution? What does the timeline for this journey look like? What tripped them up along the way? And how did they feel during each of these steps (happy, sad, frustrated)? Your interview script should directly ask the person the steps they went through to solve the problem.
Simply asking them whether or not they are interested is a poor indicator of willingness to buy or use.
3. Fill out a persona — A persona is a composite of multiple interviewees with common goals, motivations, pain points, and values. As you are scripting your questions, you need to bear in mind that over the course of ten, twenty or more interviews, your goal is to fill out the persona of your target user. A persona template includes each persona’s a) goals (what are they concretely trying to achieve), b) motivations (pain to avoid / reduce or pleasure sought after), c) any pain points with the existing behavior (stumbling blocks) and d) values (what is the underlying reason that explains why they took or did not take an action). In interviews, you should ask how they made decisions and understand what drives those decisions. You can apply root cause analysis using the “5 whys” technique to understand who they are and what values are most important to them.
4. Test hypotheses — Near the end of each interview, you have the opportunity to show a potential solution to the problem and get feedback from your interviewee. Your solution could be just a paper prototype developed with Balsamiq or similar apps. You can test hypotheses by adding features into your prototypes and getting people to react out loud to the solution. An example of a hypothesis might be “A mobile app is the best way for users to use my solution.” You could show a mobile app or web browser solution and ask the user to react. Note this is not a usability test — you’re trying to disprove your product hypotheses, not validate your assumptions.
5. Check interest level — At the very end of the interview, you want to judge whether your interviewee would buy or use your product. As Steve Cohn, Founder of Validately said, “Until you make saying yes cost something to a test respondent, their answer is meaningless.” Simply asking them whether or not they are interested is a poor indicator of willingness to buy or use. You can effectively judge their interest level by asking them to commit in one of three elements: time, reputation, and money. Time: “If we need to do additional interviews, would you be willing to participate again for free?” Reputation: “Do you have friends you are willing to introduce us to for interviews?” Money: “The app will be available tomorrow, are you willing to buy it now?” If the answer to any of the above is ‘no,’ then as the interviewer your job is to find out why.
To create a better solution, you want to eliminate pain points that are important to your customer.
What’s next?
Your primary goal is to understand each interviewee’s existing behavior. After you finish each round of interviews, you summarize your learnings, revisit your hypotheses, and adjust your prototype based on your analysis. Once you have completed a few rounds of interviews and start to see repeated themes with your customers’ problems, existing journeys, pain points, and values, then you will know you are on the right track and you will be able to fill out a more accurate persona template. If you don’t see these repeated themes, then you may want to use the information you have learned to pivot or explore a different idea.
Ultimately, you want to evaluate whether or not there are ways to improve on existing solutions. To create a better solution, you want to eliminate pain points that are important to your customer with their existing solution. A potential next step is to build a “Wizard of Oz” prototype to test your solution without building it. In the coming weeks, I’ll cover how our team simulated a Slack chat bot without coding.
This article was originally published on osvproduct.com.
