Use One Knowledge Base for End-to-End Product Delivery
There are real business risks that come with operating in silos. See why your company deserves a true centralized knowledge base in order to be efficient.
“I know they do stuff, I’m just not exactly sure what that stuff is.”
How many times have you heard (or let’s be honest, said) those words from one of your colleagues in reference to another team or department? It’s easy for us to get lost in our own corners of our company in our day-to-day work, which sometimes leads to a lack of understanding of what our peers on the other side of the house do to help our business function. And for good reason: staying focused on your own areas of expertise and responsibility helps everyone grow in their own functions. But what happens when that view gets so narrow that teams struggle to see the ways in which their work impacts the rest of the company?
Company knowledge wants to be cross-functional
When teams see their functions in a vacuum, they often see their team’s knowledge in a vacuum too. For marketing teams, this could mean buyer personas or feature positioning descriptions. For engineering teams, this could mean technical documentation or environment set-up instructions. And for support teams, this could mean responses to FAQs or troubleshooting guides for feature bugs. These resources might be living in any number of tools that individual teams rely on, like Google Drive, GitHub, Intercom, etc., and can be owned collectively or by a leader/specialist on the team that focuses on documentation.
At surface level, it makes sense that different teams need different documentation tools to best suit their workflows, but as we dig deeper, we uncover the real business risks associated with operating silos.
How siloed knowledge impacts operations
Most documentation involves cross-functional collaboration in some way. Let’s walk through an example of a support agent updating a help center article about a feature. The agent might get started with FAQs that have been gathered by their team, and will then need to partner with the engineering team to get the answers. Some of those answers are documented in GitHub, but most of them live in one subject matter expert’s head.
Once the support agent has those answers, they may also need to check in with their product marketing team to ensure that they’re using the correct terminology for the feature’s benefits. The product marketing team might then send over a one sheet from their Google Drive, which has some messaging from last year’s launch of the feature that might be outdated. Finally, the support agent checks in with the sales team to see if they have any additional questions to add, and if they do, they must then check back again with engineering.
By the time that support agent has their new help center article built out, they’ve had conversations with teammates across the company, who have all had to go into their own separate knowledge channels to find the supporting information. And that’s assuming that everything runs smoothly along the way. What might happen if the engineer who is the subject matter expert on the feature is on vacation that week? Or if the sales team realizes they have additional questions to add, but they’re scattered in various Slack channels? With every bump in the road, the timeline is stretched, and more and more opportunities for knowledge leakage and miscommunication present themselves.
Now, let’s consider an alternative scenario—one where all teams share a place to document and access important up-to-date product knowledge. When the support agent reaches out to the engineering team initially with questions, the engineering team doesn’t need to worry if the SME is on vacation that week—they would have previously shared their expertise with the rest of the team via the shared knowledge base.
Instead of the product marketing team sending over possibly outdated information that was written a year ago, they access their updated messaging and positioning information that they verify for accuracy every quarter. And instead of the sales team scrambling across Slack channels to find questions they’ve previously sought answers to, they have them all documented in a shared platform that’s then easy to send over.
What’s better about this entire process is that the support agent could even find a lot of this information on their own, without taking others out of their workflow, simply by searching.
When all of this information is kept in team-specific, siloed tools, self-service knowledge retrieval is simply not possible.
The role of real-time collaboration between colleagues will never be eliminated; after all, those interactions are what help us form connections with and empathy for each other. But in many phases throughout a product delivery and enablement cycle, there exist tasks that could be completed much more efficiently when knowledge is democratized across all teams. Both the knowledge-seeker and the subject matter experts can continue in their workflow uninterrupted, and can save their real-time collaboration bandwidth for more meaningful and creative work.
“I know they do stuff, I’m just not exactly sure what that stuff is.”
How many times have you heard (or let’s be honest, said) those words from one of your colleagues in reference to another team or department? It’s easy for us to get lost in our own corners of our company in our day-to-day work, which sometimes leads to a lack of understanding of what our peers on the other side of the house do to help our business function. And for good reason: staying focused on your own areas of expertise and responsibility helps everyone grow in their own functions. But what happens when that view gets so narrow that teams struggle to see the ways in which their work impacts the rest of the company?
Company knowledge wants to be cross-functional
When teams see their functions in a vacuum, they often see their team’s knowledge in a vacuum too. For marketing teams, this could mean buyer personas or feature positioning descriptions. For engineering teams, this could mean technical documentation or environment set-up instructions. And for support teams, this could mean responses to FAQs or troubleshooting guides for feature bugs. These resources might be living in any number of tools that individual teams rely on, like Google Drive, GitHub, Intercom, etc., and can be owned collectively or by a leader/specialist on the team that focuses on documentation.
At surface level, it makes sense that different teams need different documentation tools to best suit their workflows, but as we dig deeper, we uncover the real business risks associated with operating silos.
How siloed knowledge impacts operations
Most documentation involves cross-functional collaboration in some way. Let’s walk through an example of a support agent updating a help center article about a feature. The agent might get started with FAQs that have been gathered by their team, and will then need to partner with the engineering team to get the answers. Some of those answers are documented in GitHub, but most of them live in one subject matter expert’s head.
Once the support agent has those answers, they may also need to check in with their product marketing team to ensure that they’re using the correct terminology for the feature’s benefits. The product marketing team might then send over a one sheet from their Google Drive, which has some messaging from last year’s launch of the feature that might be outdated. Finally, the support agent checks in with the sales team to see if they have any additional questions to add, and if they do, they must then check back again with engineering.
By the time that support agent has their new help center article built out, they’ve had conversations with teammates across the company, who have all had to go into their own separate knowledge channels to find the supporting information. And that’s assuming that everything runs smoothly along the way. What might happen if the engineer who is the subject matter expert on the feature is on vacation that week? Or if the sales team realizes they have additional questions to add, but they’re scattered in various Slack channels? With every bump in the road, the timeline is stretched, and more and more opportunities for knowledge leakage and miscommunication present themselves.
Now, let’s consider an alternative scenario—one where all teams share a place to document and access important up-to-date product knowledge. When the support agent reaches out to the engineering team initially with questions, the engineering team doesn’t need to worry if the SME is on vacation that week—they would have previously shared their expertise with the rest of the team via the shared knowledge base.
Instead of the product marketing team sending over possibly outdated information that was written a year ago, they access their updated messaging and positioning information that they verify for accuracy every quarter. And instead of the sales team scrambling across Slack channels to find questions they’ve previously sought answers to, they have them all documented in a shared platform that’s then easy to send over.
What’s better about this entire process is that the support agent could even find a lot of this information on their own, without taking others out of their workflow, simply by searching.
When all of this information is kept in team-specific, siloed tools, self-service knowledge retrieval is simply not possible.
The role of real-time collaboration between colleagues will never be eliminated; after all, those interactions are what help us form connections with and empathy for each other. But in many phases throughout a product delivery and enablement cycle, there exist tasks that could be completed much more efficiently when knowledge is democratized across all teams. Both the knowledge-seeker and the subject matter experts can continue in their workflow uninterrupted, and can save their real-time collaboration bandwidth for more meaningful and creative work.
Experience the power of the Guru platform firsthand – take our interactive product tour
.webp)
