Different end users of analytics have different needs—from reporting novices who want prebuilt dashboards to data pros who need unencumbered access. To satisfy your end users and see strong adoption, you have to tailor analytics capabilities to the job they are trying to accomplish.
We talked to David Bland, Founder of Precoil, about best practices for interviewing customers to validate new feature requests.
How do you know if you should add a new analytics feature to your product?
David Bland: Behind every tool or feature request you receive is a customer job to be done. It’s a task they are trying to accomplish, but unfortunately, they may not be able to clearly communicate that to you. Most likely you only see the tip of the iceberg as the customer requests come in through your sales team, customer support, email and social media. It’s your responsibility to get to the job behind that feature request, determine if it’s a mutually beneficial feature to build, and then turn that learning into action. Luckily, there are a few ways you can approach this dilemma, rather than simply building what they request.
What are some best practices for conducting customer interviews to get to the job behind the feature request?
First, you’ll need to write down what you’d like to learn in the form of a hypothesis. It may sound trivial, but this will help you anchor your interview in validated learning. Ad hoc interviews can be useful at times, but often they turn into a long conversation that doesn’t help you come to a decision. I recommend using the “We believe that…” format for your hypothesis. For example, “We believe that customers need to sort inventory by stock value.”
Second, you’ll need to write an interview script. The script simply gives you a guideline to follow so that you try to extract as much learning as you can about the hypothesis. I recommend to keep it short and sweet; follow a basic flow to get your customer talking.
Third, you’ll need to conduct the interviews. I recommend doing them in pairs, so you can focus on conducting the interview while your team member takes notes. The scribe should write down exact quotes, instead of paraphrasing. When you paraphrase, the bias starts to sink in early instead of being objective. The scribe should also take note of body language, which is why I recommend doing these in person or over video.
Finally, you turn your interview notes into learning. If you perform 15-20 of these interviews, it can generate quite a stack of notes. Don’t pick out the quotes you want to hear and then go build the feature. Instead, write each quote down on a sticky note. Then put all of the sticky notes onto the wall. Ask your team, “Which of these are the same or are saying the same thing in a different way?” Then group those into clusters and label them. This will help you sort all of the feedback into themes in order to make an informed decision.
Do you then build the feature?
Customer interviews are one way to get to the job behind the feature, but it doesn’t necessarily mean you should rush off and immediately build the feature. Sites like Google often incrementally invest in new features by first running more experiments. They may paper prototype features with customers, show them clickable dashboards without any of the backend infrastructure in place, or release a feature stub on the live site. The feature stub is essentially a link to a feature, but when clicked shows a “We’re not ready yet” message.
All of these options and more are available to you. Remember, there’s a big difference between looking at something versus looking for something. Make sure your investment in new features is built on a foundation of customer evidence.