As organizations and product teams grow, sharing knowledge and keeping everyone aligned becomes increasingly difficult. This lack of alignment on key learnings leads to:
Although most companies try to combat this challenge with knowledge repositories, this solution is far from optimal.
In this article, you’ll learn where the current knowledge-sharing approach falls short and what alternatives to use.
The classical approach to knowledge management in product development usually focuses on documenting learning in some sort of knowledge repository. An example could include a Confluence space with all learnings organized as separate files in a chronological or feature-based order.
The biggest problem with that approach is that hardly anyone reads it. Although it’s sometimes useful, specifically when someone wants to investigate if someone experimented on a given feature in the past, you shouldn’t expect people to proactively go through learnings when designing experiments and features.
It’s simply too overwhelming to be the primary source of knowledge for the team.
You might be thinking If the standard knowledge repositories don’t work, what’s an alternative for knowledge sharing?
I firmly believe a healthy knowledge-sharing culture consists of two parts:
Let’s dig in.
First, you must ensure that everyone in the company has access to the newest discoveries and learnings available.
These must be:
This constant actualization of product knowledge will not only help you by providing fresh insights, but will also serve as a foundation for creating a “current beliefs document.”
User interviews should be one of your primary sources of knowledge about your users and an interview snapshot is a handy tool that helps you summarize and organize your interviews into an easily shareable format:
My interview snapshots usually consist of:
I’d recommend creating a chat channel or email thread where everyone shares those snapshots (or other types of summaries) whenever available to propagate the knowledge captured during the interview with the whole organization.
Like interview snapshots, you should distribute learnings from your experiments as soon as possible. My preferred format for experiment summaries looks like the following:
The main part of the summary consists of name, date, one-sentence summary, and key learnings. This quick and digestible format will encourage an increasingly busy audience to read the summary.
For people wanting to dig deeper, I’d recommend writing down what hypothesis was tested, whether it was validated, what the test configuration was, and detailed results, such as the measured impact on monitored metrics.
Similarly to interview snapshots, use a dedicated channel for propagating and tracking these.
Now, although experiment summaries and interview snapshots create an excellent summary for captured insights, they still experience the same problem knowledge repositories do — they’re often ignored, as people are already busy with their daily responsibilities.
Having dedicated communication channels and updating the whole audience on the go (rather than just generating new files in some folder) does help, but that’s not enough.
What seems to work pretty well, though, are dedicated knowledge-sharing meetings, during which:
That’ll help ensure that everyone receives a fresher dose of knowledge, but will also help to solidify learnings in people’s minds.
Capturing and distributing learnings on the go with interview snapshots and experiment summaries and then reinforcing this knowledge in regular knowledge-sharing meetings is a great way to ensure everyone is up-to-date with the latest discoveries.
However, the knowledge generated in this way often lacks structure. It might be difficult to establish big-picture thinking when bombarded with various atomic insights and learnings.
This is why you also need a tangible, living artifact that’ll serve as a summary of everything we know and believe. Let’s call it a “current beliefs document:”
You create it for every important persona/user segment/sub-product you have, and as the name suggests, you write down your current beliefs regarding that group. The goal is to write around ten of your most important beliefs/insights, which will serve as your guiding principles for further research and product development.
To make it more tangible, here are two examples of different beliefs for two different user personas:
For each belief, you should attach:
I prefer to call them “beliefs” rather than “facts” or “insights,” as the latter tends to give a false sense of certainty and confidence, whereas the former is more inviting to challenging and further validating the beliefs.
Whenever you share a new learning with an organization, double-check it with your current beliefs. Does it provide additional evidence of what you currently believe in? Or maybe it contradicts some of your beliefs, requiring you to update the document?
The current beliefs document is an incredibly potent tool. Some of its benefits include:
Instead of throwing hundreds of snapshots and summaries that no one will ever read, you can just describe your current beliefs about your users with a brief summary of the reasoning behind them to get new hires up to speed.
Whenever there’s a new idea for product development, you can quickly check it against your current beliefs and see whether it aligns with them or goes against them. It’s a great filter tool.
By reviewing your current beliefs and their evidence, you can easily spot which areas are heavily researched and experiment-backed, making it pointless to invest in further research there. They also help you spot those beliefs that don’t have solid evidence behind them and need further research to validate or invalidate them. It helps you keep your research effort focused and organized.
Way too many organizations treat knowledge sharing as a form of nice-to-have or should-have activities. However, a poor knowledge-sharing culture leads to misalignment, wasted efforts, and suboptimal product solutions.
On the other hand, although a robust knowledge-sharing culture requires effort, it helps organizations double down on captured learnings and ensures these lead to actual outcomes, not only extensive research reports.
Start with developing a cohesive way to capture and summarize learnings across the organization (such as interview snapshots and experiment summaries). Then, build a culture of creating and sharing those artifacts on a day-to-day basis. Top it up with regular insight reviews, ensuring everyone understands the current state of your knowledge of your users and product.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Sanjay Modi discusses his role in leading a website security product portfolio through drastically changing customer needs.
The acronym SDK stands for software development kit. It contains platform-specific tools to run and develop software.
If you think about some of the businesses that market familiarity as a selling point, you actually don’t get negative vibes from them at all.