Did you ever play a game of telephone as a kid? When the final kid in line triumphantly declares what they’ve been told, it usually sounds nothing like the original message.
All too often, the way information is collected and distributed in research interviews resembles this sort of whisper-down-the-line scenario. Our customers’ voices are usually lost somewhere between good intentions and bad execution. And it’s nobody’s fault: the systems we use to collect and distribute interview data cause this dilution (and eventually, poor product-market fit).
It’s not all bad news, though. The best product teams have found a repeatable way to record and share their research interview notes without losing their customers’ intents and beliefs. And we can teach you how to do this, too.
Whether you’re collecting ideas for a new product or gathering feedback about an established one, the data from your research interviews needs to reflect the experience of the interviewee as closely as possible. You shouldn’t aim to just capture what they say but what they actually mean. If the information your product team eventually acts on is inaccurate, repercussions could range from churning customers to bankruptcy.
But no matter how diligent you are at note-taking or how accurate your transcription service of choice claims to be, most research interview notes actually aren’t helpful for two reasons:
For lack of a better solution, product teams have historically relied on written notes and transcripts of audio or video calls to make decisions. This is all well and good until you remember that bias exists.
Let’s say your co-founder is absolutely certain that your target audience wants your future product to integrate with Slack. They’re going to look for insights from interviews that confirm this. And they’ll probably do so without even realizing it. Everyone has some amount of unconscious bias that leads us to misinterpret the data we’re presented.
No matter how good you or someone else on your team is at taking notes, there is no way to get around the inherent biases we have when we read them. Our experiences, our moods, our ideas — all of these things can influence us to make snap judgments about what we see. But when you hear something being said or see the customer reacting to a question, it’s much harder to mistake their actual feelings.
There’s a big difference between opening an interview transcript and reading the sentence “oh, that’s interesting” and actually hearing a customer say it. Depending on the mindset you have going into the transcript, you might interpret the statement as excitement. Or sarcasm. Or disinterest, or any number of emotions, all of which might lead you to draw a (potentially incorrect) conclusion about this interviewee’s experience.
Listen to the audio of the session, though, and you might hear that the customer was curious, really, and truly interested in what was put in front of them and, in fact, asked the moderator two more questions about the prototype of your product.
Again, when you see or hear a customer reacting to something, there’s an element of humanity that you just don’t get out of the written version. Your team is much more likely to empathize with a customer they can see and hear, and that empathy is what’s going to motivate them to take action.
What’s more likely to make you rebuild your product: reading “he got upset” or actually watching a customer get frustrated to the point of screaming? Easy decision, right?
So, if written interview notes don’t work as we imagine, what does? The best product teams I know are using what I call the literal voice of the customer — the customer’s own words recorded in audio or video form.
The key to using the audio or video from your research interviews is saving it somewhere that your entire team can access. So for each and every interview, you want to have a recording of that session that can be listened to or watched by anyone who needs to use it for decision-making — either now or in the future. Besides sidestepping potential bias, watching or listening to research interviews allows teams to:
But wait, just because you recorded a customer interview doesn’t mean it’s all done. You still have a problem. The inherent problem that comes with recording the audio or video of research interviews — especially if you’re at an organization that does a lot of user testing, or are a super small team in the thick of the customer discovery phase — is that there’s no possible way every single person can listen to or watch every single session.
Plenty of well-meaning product teams have, no doubt, started to record their interviews, only to quickly realize just how much of a time investment it is to play them back. Then it’s either “screw this, we’re going back to notes,” or somebody gets put into a project manager role, and now it’s just their biases potentially controlling what gets built.
Your team can’t feel like it’s a hassle to listen to the literal voice of the customer because then they won’t do it — they’ll go back to notes or some other less-effective half-measure. The best product teams in the startup world already know you have to strike a balance between preserving all this data and sharing it in an easily digestible way.
This is what actually led us to build Grain.
Grain enables you to collect, organize and share insights with lighting speed. Gone are the days of rewatching full interviews. With Grain, clip and categorize insightful moments as they happen in real-time. Spend more time analyzing and sharing, not editing videos.
So if your team wants to share specific portions of these research interviews, Grain gives you the ability to make small clips—again, preserving the full context of the transcript, audio, and video—and share them with anyone you like.
You owe it to your company, your team, your customers (theoretical or actual), and your product itself to collect and preserve accurate data from your research interviews. If you’re not putting in the work to preserve the literal voice of your customers, you need to understand that your interview process is broken, and you’re not going to find product-market fit until it’s fixed. Learn how I created a framework to understand the users better and create the right product here.