The ‘I wish I had known this before’ of building an insights repository
This article is based on the conference talk Johanna gave at the 2023 ReOps conference. You can get access to the full replay here, including additional advice and hands-on examples Johanna shared during her talk. The following is a condensed version of the most important takeaways.
Managing knowledge effectively is a topic that goes way beyond the work environment and I would argue that it matters for everyone dealing with knowledge and insights in their life in some way. It’s not only something of a quality issue (e.g. the feeling of overwhelm when trying to remember important outcomes of a past project) but also very much a measurable, quantitative topic in the form of hours of lost productivity, costly repeated work, and extensive ramp-up time with low output getting new hires up to speed after an experienced and skilled employee left. While it’s often hard to put a number on such things, we do have estimates for what the knowledge, know-how, education, experience, skills, relationships, and common sense we carry around in our heads is worth:
“The value of physical capital in the US — land, machinery, and buildings (…) — is about $ 10 trillion, but that value is dwarfed by the value of human capital, which is estimated to be five to ten times larger.”
—Tiago Forte, in Building a Second Brain
Insights repositories are a great way to make this tangible. However, what teams in charge often do is to buy a repository tool, throw in all their data and expect to then somehow automatically unlock this huge value. Unfortunately, that’s not how it works which is why I’ve distilled the most important learnings and watch-outs into the ‘I wish I had known this before’s of building an insights repository. To structure these, let’s start by looking at what I call the six areas of struggle:
These can represent steps or building blocks of a repo project. However, they are not to be understood as a timeline of some kind, and neither as a complete list of all the things that can be tricky in such projects. Instead, they are merely a compilation of those areas where I see teams struggle the most and most often, and I will use them to share important things to think about, and, of course, each corresponding ‘I wish I had know this before’.
🎯 The goal
The first thing to think about when creating an insights repository is what you actually want to achieve with it. This is number one not only because it stands at the beginning of repository projects but also because many teams struggle to get this right. There are different goals you can pursue for a repository, e.g. centralizing all customer data in one place, using it as an analyzing tool (tagging, creating themes), or to make insights accessible to stakeholders. While these might all sound great, not all of them are automatically meaningful for your unique set up. Ask yourself questions around what your org’s unique needs around insights are, what you would want a solution to look like in an ideal world, and how and why that’s different from what you currently have.
I wish I had known this before: Focus on the end, not the start
The biggest pitfall around setting meaningful goals is to focus too much on the current state of insights management and processes which are often complex, have grown over the years, and are difficult to understand and translate into something new. I’ve heard countless statements like “We just need to quickly get all our data and processes over to tool XYZ” or have been asked questions like “What’s the best way to upload these 500 research reports into tool XYZ?” These, however, are not meaningful goals as you will likely reproduce a solution that wasn’t scalable in the first place just to some other place. Instead, use this as a chance to move on to create something new that’s simpler, easier to manage, and future-proof.
♟️ The Strategy
After you’ve set a goal, you have to think about how can you reach your goals in the most effective and efficient way. Most teams don’t have unlimited time, budget, and people available, so it’s important to be realistic here. The key takeaway is to focus on your team’s unique situation and to prioritize based on what’s most actionable the soonest, and how you will see value quickly. In this area, teams that struggle think they somehow have to use their new repo app for everything.
I wish I had known this before: There’s no law saying you have to retrofit all into one repo app
This learning comes from my many conversations with teams in charge of repo strategies and it reflects the common conception that they somehow have to use a repository for just about anything — from project plans to taking notes to managing contacts. This is often influenced by the fact that many providers sell this exact idea: If you only buy their tool, you essentially won’t need anything else anymore. Sadly, more often than not, it leads to people getting confused and overwhelmed as they revolve their whole strategy around moving everything insights-related into this new tool. Real-life experience and the ‘backstage view’ into different teams have shown that it’s much more productive to ask yourself these questions first:
- Which workflows and structures already work really well?
- Which existing tools do you love and why?
- What are the opportunity costs of moving something?
These lead to a realization and universal advice I give to everyone dealing with knowledge work: Use the tool that’s best for the job. Even if it’s a spreadsheet, a note-taking app, or a Google Doc — it’s okay to use those as long as you find a good way of connecting them meaningfully in your repository and making the insights they contain available to the people who need them, without having to consult you every single time.
🚀 The Approach
This area is all about how you will put your strategy into practice and what concrete steps you will take to do so. This is where a lot of teams get stuck in ‘analysis paralysis’ and delay starting the actual work in the repository to avoid making mistakes. It’s extremely important to start at all and not spend forever trying to plot the perfect plan. A great starting point for this is to ask yourself: what would creating an insight, a story/nugget, or searching for information be like and look like if it was easy?
I wish I had known this before: Start small, expand later
If we want (others) to keep doing something new, it has to be effortless at first. In contrast, many repo building teams often try to do everything at once, with ‘delegates’ from every team, and ideally be done after one big workshop. This never really works and instead just creates a lot of chaos, long communication loops, and a poor end user experience. It’s always helpful to imagine yourself demoing a first version to the wider business after some time: How would that look like if you had dozens of people mingling around simultaneously without a clear focus or comprehensive use case? Likely, if you try certain key words or search areas, nothing substantial will show, the first version will look and feel very messy, and you’ll lose quite a bit of momentum with stakeholders. Compare this to starting with one area and an MVP based on it, including real data and examples — and then only adding to this one area at a time. This will be so much more compelling, easier to understand, and attractive to stakeholders, paving the way for a more sustainable buy-in and adoption.
📢 The Communication
If you’ve read some of my articles before, you might have noticed that communication is a key topic in my pieces. Without going into too much detail, a reason to cover this in the repository context as well is because it’s an area where a lot of sensitivity is needed, and where unfortunately a lot of mistakes happen.
I wish I had known this before: Get other people’s input, not decisions
A lot of teams get really lost trying to include every team from the start and to shape their insights system based on everyone’s needs straight away. Keep in mind that in order to succeed, every new system you’re building has to be integrable into people’s everyday lives, otherwise it will fail. Nailing this through relying on every team’s opinions is hard to impossible. This is why it’s the person in charge’s job to talk to people as much as they can and to then transform that input into a system that works. This doesn’t automatically mean making a democratic decision. Teams who go down that road will more likely get something like this:
Option 1: A Frankenstein solution where the taxonomy usually suffers the most. Frankenstein taxonomies are huge, look deformed, like someone hastily stitched mismatched individual parts together, and, to be frank, they often look a bit scary too. See where this analogy comes from?
Option 2: A copy and paste version of something people in charge have seen elsewhere and thought it will get them to success quickly if they take over what others have done. I get questions like “How did other companies in my industry solve this?” extremely often and I’m very cautious to share specifics because it will tempt some people to use the decisions others have made and just “plug” it into their company. Getting inspiration is fine and I love reading repository case studies myself. However, simply skipping the part where you create an individual, customized, relevant, and useful solution is a guaranteed recipe for repo failure.
🔄 The Change Management
Similarly to communication, this area is also about the people side of things, and more specifically about how you will establish a process and the right set of tools so you can achieve adoption of your repository. In essence, it’s about helping people leverage the change you’re introducing so they can not only do their jobs successfully, but get an even better outcome.
I wish I had known this before: No matter how you do it, there will be initial resistance
One thing I’ve seen throughout many years in UX and UX Research is that a lot of people feel almost threatened by change. It’s absolutely in human nature to reject things that are unknown to us (also known as Status Quo bias), but of course that’s not particularly helpful when you’re building a solution to change things for the better. The important thing is to acknowledge this behavior as a fact, to plan for and work with it, not against. “How?” you might ask, and this could probably be a whole talk in itself. Luckily, there are many tried and tested socializing principles and strategies out there that I recommend applying that can be adapted to your specific set up and company culture. As so often, I found that NN/G can be a good starting point for your research about this.
🧠 The Mindset
The last big area where a lot of repository building teams get overwhelmed or frustrated is their mindset. This is a tricky one as it has a lot to do with standing in your own way, and I can confidently say that almost every repository team I’ve worked with struggled with this last ‘I wish I had known this before’ at least once.
I wish I had known this before: You will never feel ready
It’s a simple truth: you will never feel ready to put your repository out there, and you’ll also never feel like you’ve finished the project. Surely there are important milestones to define, reach and, of course, celebrate so you get out of that heavy lifting set-up phase. These are for example:
However, insights repositories are like living and breathing systems that will always evolve, you will always add things, remove some, and it will never feel perfect. And that is actually okay! The dangerous thing here is to wait for some magical sign that now is the time to put it out there, communicate it, involve people. I’ve heard statements like “We just need to find the perfect repo app with the perfect feature set!” or “Once we are 100% confident with the strategy, we will start adding data” often enough to know that the underlying reason to not take action is not that the perfect tool or strategy hasn’t been found yet (spoiler: both of these don’t exist!), but that people in charge want to feel more ready and prepared. Instead, I’ve found it much more productive to move to a mindset of seeing a repository as one part of a system made of a reliable set of tools and a strategy you can depend on now and flexibly change later as needed.
To summarize, these are the six biggest ‘I wish I had known this before’s of building an insights repository, based on my extensive work with many different teams creating their own one:
I hope you’ve found these learnings and watch-outs for building insights repositories useful, and I’m very thankful for all the kind and appreciative messages I’ve received about the conference talk. Please make sure to add any questions, thoughts or feedback in the comments below and I’ll make sure to follow up on them.
Hi, I’m Johanna, a freelance Senior UX researcher & UX advisor based in Barcelona. ☀️ I help teams level up their UX game, manage UX without losing their minds, and build powerful insights systems. I also share my tried and tested resources here. More content is on the horizon so follow me on Medium to catch every update!
