"The best research output is the one that will ensure your findings have a hope of influencing future decisions."
— Erika Hall
Before we look at how to organize your research, we need to revisit why: Why is it important to organize it at all?
In a growing company, three things are usually in short supply: time, money, and personnel.
So it’s no surprise that, in the midst of mad project dashes, bits of research get scattered between Slack channels, Google folders, emails, desktops, and post-it notes taped next to “don’t forget to pick up dog.” It’s good enough that you’re doing the research, right? Who has time to organize it too.
This is normal...but not ideal.
When research notes are this scattered, it’s very difficult to put them to good use. Meaning they’re often put to no use at all. If actually doing the research is the first major hurdle to effective product discovery, leveraging the research is the second. Too many companies invest hours of time talking with customers only to put the data on the shelf.
While upfront organization does take some additional time, the benefits are well worth the effort:
You may have heard the parable of the blind men and the elephant. In case you haven’t:
A group of blind men heard that a strange animal, called an elephant, had been brought to the town, but none of them were aware of its shape and form. They said: "We must inspect and know it by touch". So, they sought it out, and when they found it, they each felt around it.
The first blind man’s hand landed on the trunk. He said "This being is like a thick snake!" The second blind man’s hand fell upon the ear, and it seemed to him a kind of fan. Another placed his hand upon the side and said, “it is a wall.” Still another felt the tail and described the elephant as a rope. The last blind man felt its tusk, stating the elephant was hard and smooth, like a spear.
When each member of a product team has access to a piece (but not the whole) of research, building a product looks the blind man parable. Each team member’s recommendation may be logical in the face of what they know, but grossly inaccurate in the face of the overall context.
Even if the team does succeed in piecing their information together and forming a coherent context, this is a slow and ineffective way to build.
To prevent this scenario, ensure everyone on your team has access to the same context, raw data, and insights, e.g. in document report, one Airtable, or one Google Drive folder. In addition to increasing project speed, this increases the likelihood of discovering a helpful and creative solution in a short time frame.
Founders often leave interviews with “rich insights” the customer never said. Rob Fitzpatrick provides a humorous example of this in his book The Mom Test, excerpted and condensed below:
Son: “Okay, so would you every buy an app which like a cookbook for your iPad?” I am optimistically asking a hypothetical question and you know what I want you to say.
Mom: “Hmmm.” As if I need another cookbook at my age. ...
Son: “And you can share recipes with your friends, and there’s an iPhone app which is your shopping list. And videos of that celebrity chef you love.” Please just say “Yes.” I will not leave you alone until you do.
Mom: “Oh, well yes honey, that sounds amazing. And you’re right. $40 is a good deal. Will it have pictures of the recipes?” I have rationalised the price outside of a real purchase decision, made a non-committal compliment, and offered a feature request to appear engaged.
Son: “Yes, definitely. Thanks Mom—I love you!” I have completely mis-interpreted this conversation and taken it as validation.
This is a fictional account—not to mention a terrible customer interview—but it captures how easily a founder projects their own context, beliefs, and assumptions onto any conversation.
Conducting better interviews and picking better interviewees (see “Conducting Customer Interviews”) is the first way to improve here. But even then, you’re prone to walk away with your own assumptions. That is, if you’re not recording and transcribing your conversations.
To make sure you walk away with actual customer insights you can reference down the road, keep a record of raw data in a centralized location. Storing audio recordings and text transcripts ensure you’re looking back on what was said, not what you think was said or what might have been said.
With research, you should always be questioning how broadly you can apply insights. To pick out a high-value insight, you want to look for volume, repetition, and where the insight came from:
You can easily note who said what in the file name, but the only way to accurately gauge volume and repetition is to track insights in a centralized location over time.
This is why I recommend teams create and then never delete a research backlog. Research insights rarely decay, and the value of customer interviews compound as you build an insights library to draw from.
For starters, make sure you record and transcribe all your interviews as opposed to taking notes. This ensures you have plenty of bandwidth to listen and respond during conversation. Next, make sure you store the recordings and transcripts in a centralized location (e.g. a shared Google Drive folder labeled “Customer Research” with sub-folder for “Customer Interviews.”)
Beyond that, here are two methods I’ve seen work relatively well for organizing research:
What is it: A condensed and easy-to read document that highlights key customer insights. This could be Google docs, Microsoft word, or some other collaborative tool like Notion. Whichever document service you choose, make sure it’s text-based and collaborative.
When it works: This method is useful when you need your team to read and digest insights; it’s much easier to present and discuss than a spreadsheet. Because a document is not easily filtered, this method is best for a one-time report as opposed to ongoing research collection.
How to do it: Organize insights into JTBD big buckets. For example, put all quotes about struggling moments onto one page and all quotes about motivations onto another. (Tip: it’s helpful to re-define struggling moments, motivations, and other JTBD pieces when doing this.)
What is it: A spreadsheet of raw customer insights, categorized by JTBD, and tagged for further organization.
When it works: This method is ideal for collecting research over time. Think of it as creating a filterable research repository. It’s great for storage, poor for presentation.
How to do it: Use this airtable or Google Sheets template as a starting point. In both templates, the first two tabs are for storing interview data and survey responses. The third tab is for tracking insights according to customer type and JTBD, and the fourth tab is for researching competitors.
Whether or not you wind up creating a report (these have their time and place), I recommend starting a research database. It’s a living document and reinforces the idea that, while you may do research in spurts, you’re never done learning.
Plus, it’s especially useful when you want to filter for something in particular or identify how often an insight occurs. For example, imagine you’re a data analytics tool such as Amplitude. One of your competitors, Mixpanel, just updated their pricing. To understand how this might affect your customer base, you could filter Airtable to show you all insights where people mention Mixpanel as an alternative.
I’m a big proponent of giving team members access to all raw customer data. However, it’s not always wise to present research as a large pile of data.
On the one hand, if you share too little information, teams may duplicate research, arrive at poor decisions, or (at best) simply suffer from different contexts.
On the other hand, if you share too much data, you risk team members not using the information (out of pure overwhelm) or facing a different kind of efficiency problem, e.g. wading through 10 hours of recordings for 3 hours of useful information.
The sweet spot is somewhere in the middle. When you present research, likely using the Google doc method above, my rule of thumb is to focus on sharing insights—specifically those that relate to JTBD. If you’re tagging your research as you go, you’ll easily amass snippets of customers talking about triggers, alternatives, desired outcomes, and so on. These are what you want to highlight, bucket, and share with your team.
One very important note: When you share your research, make sure you separate your opinion on the research from the raw pieces of research. Ideally, make these separate sections or reports. Because while the data is hard to argue with, your interpretation is very much up for debate. So be selective how and with whom you share your interpretation, and keep in mind it may be entirely unhelpful in some scenarios.