Building a customer insights repository
Imagine if at the start of every new project, you had to forget everything that you know about customers within that domain. Everything you know about what’s important to them. The products and services they use. The pain points they experience. The challenges they face. Rather than building on existing customer insights, you’d have to start from scratch every time. It would be a crazy way to work, and yet many teams do such a bad job of consolidating and communicating pre-existing customer insights, that they may as well take this approach.
Trying to locate existing customer insights can all too often feel like hunting for fossils. Most of the time you’ll just find tiny fragments, which on their own really aren’t that insightful. Every so often, you’ll hit the jackpot in the form of some fossilised insights, a customer persona, or perhaps a long-lost customer research report. Like the fragments of a dinosaur skeleton there will be missing details and elements that you’ll have to piece together, but slowly over time a more fully formed picture will start to form. Whilst hunting for fossils might be fun (if you’re into that sort of thing), hunting for customer insights certainly isn’t.
To ensure that what is already known about customers doesn’t remain buried deep in the ground the DB DevOps teams at Redgate have started building a customer insights repository place to better store, share and utilise customer insights. That one place is the Database DevOps customer research dashboard.
Introducing the Database DevOps customer research dashboard
The Database DevOps customer research dashboard is the Natural History Museum of customer insights. A place where everyone within Redgate can go to learn about DB DevOps customers; to discover and explore customer insights and to access the vast collection of customer insight fossils available within.
Like the floors of a museum, the dashboard has different levels of information about customers. This allows the wood to be seen, along with the trees. The different levels are as follows:
- High-level insights
- Individual observations
- Raw research data
1. Insights
At the top are the high-level insights that have come out of research activities, such as research calls and customer feedback. Insights are often in the form of documents, such as personas, empathy maps, job maps and value proposition statements.
2. Observations
In the middle are individual customer observations and pieces of feedback, such as observations from customer calls, usability issues identified during usability testing and survey responses. Importantly these are date stamped and tagged to allow observations to be easily searched, filtered and grouped by topic.
3. Research data
Forming the foundation of the customer research repository is the raw customer research data. This includes notes from customer calls and visits, and full unfiltered survey responses.
Building a customer research repository
There are a growing number of platforms out there which promise to provide a quick and easy to set-up customer insights repository, such as the excellently named Nom Nom and Dovetail. However, the team felt that none of the platforms out there ticked enough of the boxes to warrant paying for yet another tool, so instead we have built a repository using the following pre-existing or free tools.
Confluence
Confluence is used to present the high-level insights as an easy to navigate Wiki (at least that’s the idea) and to store some of the raw data, such as customer interview notes (OneDrive is also used to store raw customer research data).
Refamer
Reframer is a splendid qualitative data analysis tool from Optimal Workshop. It allows research observation notes to be entered (or imported) and tagged with a pre-set taxonomy. Tagged notes can then be browsed within Reframer and exported as an Excel Spreadsheet.
Reframer is used to slice and dice the raw customer research data into individual observations and to add consistent tags which reflect the topics covered by the observations. This is important to allow the observations to be easily searched, filtered and grouped within airtable.
Airtable
Airtable is like a cross between a spreadsheet and a database. It allows the information to be easily cross-referenced, filtered, searched and grouped by topic. Observations are exported from Reframer and added to Airtable along with details of the research participants.
Slack
Slack is used to communicate updates, such as new customer insights being available. Importantly Slack isn’t used to deliver the customer insights themselves as insights delivered via Slack tend to be very transient. They don’t persist very long and invariably get lost in the Slack-hole that forms over time.
Populating the customer research repository
Having a customer research repository has meant that there is a little bit more work when it comes to recording customer research, but trust me, that extra work has been well worth it in the long run. The process for populating the customer research repository is as follows.
1. Capture & upload customer insights
Raw customer research, in the form of usability testing sessions, research calls, survey results etc… are captured and uploaded to Confluence, or OneDrive.
2. Record details of customer research
Details of customer research undertaken, such as research calls and usability testing sessions are recorded within airtable, along with a link to the raw customer research (e.g. research notes). The table within airtable provides a record of the research that has been undertaken, and the customers that have been involved.
2. Identify and tag individual observations
Individual insights and observations, such as usability issues, quotes, survey answers and research observations are tagged using Reframer. The raw data is then downloaded as an Excel spreadsheet and pasted into airtable.
3. Update high-level insights
High-level insights are updated. For example, details of jobs to be done, personas and key usability issues. Where possible high-level insights are referenced back to the originating customer research (e.g. call notes).
Conclusion
Establishing a customer research repository has not only provided a home to customer insights, but the process of extracting and tagging individual observations has helped to more systematically build all important high-level insights, such as personas, jobs to be done and value propositions. The repository has already proved useful for better answering research questions and for ensuring that the DB DevOps teams are making informed product decisions based on genuine customer insights.
