Us founders in the B2B world are often in awe of B2C founders, when you consider the beautiful apps they have made and the amazing scale they have achieved with them. You see a lot of talk about the “consumerization of IT”, and see a lot of B2B companies draw analogies to consumer success stories. When done right it works very well. Salesforce is notorious for pointing to consumer analogies as the inspiration behind their product strategy for their CRM. That seemed to work out ok ;).
But most of the time it doesn’t work, simply because the jobs and cares of humans in their personal lives are fundamentally different from their jobs and cares at their work lives. A great example is the wave of companies that wanted to be “Facebook for the enterprise” thinking that people would post things at work just cause its fun. But at work we have jobs to do, so the software we choose to use is chosen because it helps us do our jobs.
Another big reason the analogy fails is scale. There are billions of people on the internet now. The largest enterprises in the world are only 100,000’s in size. Several orders of magnitude smaller. What works in the billions world just won't seamlessly transfer over to the thousands world. We already wrote about Enterprise Q&A tools and why that transference doesn’t work. Wiki’s is another big one…
Wikis aren't where you work
After Google released their Knowledge graph in 2012, Wikipedia saw a 21% decline in page views the following year.
As you can see in the image above, Google now inserts relevant information regarding searches right into the search workflow, so users do not even have to click through to Wikipedia. With an estimated 1 in 4 searches utilizing the knowledge graph, Google is slowly providing information to users in context, which is contributing to the declining readership of Wikipedia. Super helpful because this valuable knowledge is now being brought to us without having to leave Google's search.
In the enterprise, this notion of contextual knowledge is just as important. As the success of the knowledge graph proves, while an enterprise Wiki may seem to be the easiest way to create knowledge, it's definitely not the easiest way to find and consume knowledge. At work we use so many apps throughout our day that unless an app helps us do our job, we just arent going to use it. Its out of sight, out of mind. So many wiki projects get rolled out at work and then are quickly forgotten about for this exact reason; a wiki or knowledge base should not be viewed as a destination, an app, a portal. It is a means to an end. The end is a job we need to get done, our knowledge base helps us get that job done. Read more about how Guru does enterprise-wide knowledge management.
Wikis aren't built for continuous changes
Wikipedia works because there are literally 100s of 1000s of contributors (980,176 English language contributors as of February 2015 alone). There is the notion called the “1% rule”) that says for every 1000 readers on an internet community, you will have 1 contributor. While that ratio works at scale for Wikipedia, it certainly does not work for businesses.
It also makes sense because most content on Wikipedia doesn’t need to change once it gets written. A lot of the content is about discrete things and events that occurred in the past — it already happened.
But in businesses this is totally different. Most content in business will change. It should change. Think about it; do you have the same competitors today that you had a year ago? 6 months ago? Have any of them released new features in the last 3 months? Should your sales team know about those new features? Wiki’s aren’t built for change. They are built for large amounts of long form content. Fantastic for global knowledge sources like Wikipedia, not the best fit for evolving businesses.
Wikis aren't necessarily accurate
In a massive public forum such as the internet, the way you derive accuracy is a huge and complex problem. Wikipedia has a change management process to ensure what you see there is accurate to the best of their ability, and even that system is not perfect.
At work however this is very different. Even at the the biggest companies in the world, it is much more reasonable to know who the experts are on a given subject, and what groups or individuals can ensure accuracy of information about products, people, process, etc. Despite this, company knowledge repositories are silent on this concept of accuracy and verification. Yes, you most likely know when the content was last updated. You may even knowwho last updated. But in your organization which relies on a relative few knowledge creators, your knowledge consumers need a clear stamp of approval to trust this content is accurate.
Imagine a sales team which is using a wiki as their knowledge base. The reps also know how quickly knowledge changes, and while they may have taken a look at the wiki (or not), it is unclear who has verified the accuracy of content they find, or when it was last verified. So just to be sure they message a sales engineer or walk up to a product manager and tap their shoulder. While the rep thinks they are getting to their solution faster, the subject matter experts are cursing under their breath, answering the same question 3 times in a day from different people. And distracting experts costs money; a recent study shows that it takes an average of 23 minutes and 15 seconds to recover from an interruption! One-off messages and shoulder taps don’t scale, especially when a few experts get engaged by tens and eventually hundreds or thousands of colleagues all needing their help. So while the knowledge could be in the wiki, it doesn’t matter. Your employees don’t trust it. Without that trust, your wiki fails.
So what's the solution then?
Context awareness is the future of enterprise knowledge repositories
As mentioned, Google's Knowledge Graph brings key content from sources like Wikipedia and embeds it right along side your search results so you don't even have open a new window. At work, think about the various aspects of knowledge we need to do our job, and then think about when we need it.
I want the latest competitive intel when I am preparing to sell to a prospect that I know is also looking at that company.
I want to know how to use this app when I am trying to use it.
I want to know quick facts about this partner when I am getting asked about them by my customer
I want our latest product messaging when I am updating our various social media properties.
Notice in all of these examples there is a job being done, and referential knowledge is needed in order to complete the task. This context awareness allows the right knowledge to get surfaced at the time of need, right in the workflow of the person doing the job. Knowledge consumers search less, while knowledge experts receive less one-off messages and shoulder taps so they can focus on executing on their role specific tasks.
Verified content builds trust
All content that team members rely on to do their jobs needs to be verified by experts on the team on a periodic basis. For anyone searching and browsing this content, it should be very clear who verified the accuracy of the content, when it was last verified, and how often it is reviewed.
Equally important, experts should be automatically reminded to verify content as it gets stale so they don't have to think to do it. The frequency of verification should be determined by the nature of the knowledge being captured. If a company releases new versions of their products quarterly, then knowledge about that product should be reviewed quarterly as well.
When a team member finds content they need and they can clearly see that it was recently verified by an expert, they are much less likely to do a personal outreach to another team member. This is true scalability.
Leverage analytics to see how this knowledge impacts your business
The last, and probably most important bit is to measure how these knowledge bases impact the key metrics for your business. At a high level, usage metrics should be tracked for each piece of knowledge being stored; how many times they have been viewed, copied, or favorited so you can see the most valuable content your team uses.
Team members should also be proactively notified about gaps in your team's knowledge by showing search terms your team is using that are not returning results. This way you can add this missing knowledge and let your team know once its available.
Finally, think about how you can tie these usage metric to your key business applications. Can we tie the use of content to more closed deals? Shortened sales cycles? Are new team members onboarded faster?
So whether its tactical insights, "are my team members using our knowledge base?", or strategic, "is my team executing better because of my knowledge base?" it's an often overlooked but critical part of your rollout strategy.
Us founders in the B2B world are often in awe of B2C founders, when you consider the beautiful apps they have made and the amazing scale they have achieved with them. You see a lot of talk about the “consumerization of IT”, and see a lot of B2B companies draw analogies to consumer success stories. When done right it works very well. Salesforce is notorious for pointing to consumer analogies as the inspiration behind their product strategy for their CRM. That seemed to work out ok ;).
But most of the time it doesn’t work, simply because the jobs and cares of humans in their personal lives are fundamentally different from their jobs and cares at their work lives. A great example is the wave of companies that wanted to be “Facebook for the enterprise” thinking that people would post things at work just cause its fun. But at work we have jobs to do, so the software we choose to use is chosen because it helps us do our jobs.
Another big reason the analogy fails is scale. There are billions of people on the internet now. The largest enterprises in the world are only 100,000’s in size. Several orders of magnitude smaller. What works in the billions world just won't seamlessly transfer over to the thousands world. We already wrote about Enterprise Q&A tools and why that transference doesn’t work. Wiki’s is another big one…
Wikis aren't where you work
After Google released their Knowledge graph in 2012, Wikipedia saw a 21% decline in page views the following year.
As you can see in the image above, Google now inserts relevant information regarding searches right into the search workflow, so users do not even have to click through to Wikipedia. With an estimated 1 in 4 searches utilizing the knowledge graph, Google is slowly providing information to users in context, which is contributing to the declining readership of Wikipedia. Super helpful because this valuable knowledge is now being brought to us without having to leave Google's search.
In the enterprise, this notion of contextual knowledge is just as important. As the success of the knowledge graph proves, while an enterprise Wiki may seem to be the easiest way to create knowledge, it's definitely not the easiest way to find and consume knowledge. At work we use so many apps throughout our day that unless an app helps us do our job, we just arent going to use it. Its out of sight, out of mind. So many wiki projects get rolled out at work and then are quickly forgotten about for this exact reason; a wiki or knowledge base should not be viewed as a destination, an app, a portal. It is a means to an end. The end is a job we need to get done, our knowledge base helps us get that job done. Read more about how Guru does enterprise-wide knowledge management.
Wikis aren't built for continuous changes
Wikipedia works because there are literally 100s of 1000s of contributors (980,176 English language contributors as of February 2015 alone). There is the notion called the “1% rule”) that says for every 1000 readers on an internet community, you will have 1 contributor. While that ratio works at scale for Wikipedia, it certainly does not work for businesses.
It also makes sense because most content on Wikipedia doesn’t need to change once it gets written. A lot of the content is about discrete things and events that occurred in the past — it already happened.
But in businesses this is totally different. Most content in business will change. It should change. Think about it; do you have the same competitors today that you had a year ago? 6 months ago? Have any of them released new features in the last 3 months? Should your sales team know about those new features? Wiki’s aren’t built for change. They are built for large amounts of long form content. Fantastic for global knowledge sources like Wikipedia, not the best fit for evolving businesses.
Wikis aren't necessarily accurate
In a massive public forum such as the internet, the way you derive accuracy is a huge and complex problem. Wikipedia has a change management process to ensure what you see there is accurate to the best of their ability, and even that system is not perfect.
At work however this is very different. Even at the the biggest companies in the world, it is much more reasonable to know who the experts are on a given subject, and what groups or individuals can ensure accuracy of information about products, people, process, etc. Despite this, company knowledge repositories are silent on this concept of accuracy and verification. Yes, you most likely know when the content was last updated. You may even knowwho last updated. But in your organization which relies on a relative few knowledge creators, your knowledge consumers need a clear stamp of approval to trust this content is accurate.
Imagine a sales team which is using a wiki as their knowledge base. The reps also know how quickly knowledge changes, and while they may have taken a look at the wiki (or not), it is unclear who has verified the accuracy of content they find, or when it was last verified. So just to be sure they message a sales engineer or walk up to a product manager and tap their shoulder. While the rep thinks they are getting to their solution faster, the subject matter experts are cursing under their breath, answering the same question 3 times in a day from different people. And distracting experts costs money; a recent study shows that it takes an average of 23 minutes and 15 seconds to recover from an interruption! One-off messages and shoulder taps don’t scale, especially when a few experts get engaged by tens and eventually hundreds or thousands of colleagues all needing their help. So while the knowledge could be in the wiki, it doesn’t matter. Your employees don’t trust it. Without that trust, your wiki fails.
So what's the solution then?
Context awareness is the future of enterprise knowledge repositories
As mentioned, Google's Knowledge Graph brings key content from sources like Wikipedia and embeds it right along side your search results so you don't even have open a new window. At work, think about the various aspects of knowledge we need to do our job, and then think about when we need it.
I want the latest competitive intel when I am preparing to sell to a prospect that I know is also looking at that company.
I want to know how to use this app when I am trying to use it.
I want to know quick facts about this partner when I am getting asked about them by my customer
I want our latest product messaging when I am updating our various social media properties.
Notice in all of these examples there is a job being done, and referential knowledge is needed in order to complete the task. This context awareness allows the right knowledge to get surfaced at the time of need, right in the workflow of the person doing the job. Knowledge consumers search less, while knowledge experts receive less one-off messages and shoulder taps so they can focus on executing on their role specific tasks.
Verified content builds trust
All content that team members rely on to do their jobs needs to be verified by experts on the team on a periodic basis. For anyone searching and browsing this content, it should be very clear who verified the accuracy of the content, when it was last verified, and how often it is reviewed.
Equally important, experts should be automatically reminded to verify content as it gets stale so they don't have to think to do it. The frequency of verification should be determined by the nature of the knowledge being captured. If a company releases new versions of their products quarterly, then knowledge about that product should be reviewed quarterly as well.
When a team member finds content they need and they can clearly see that it was recently verified by an expert, they are much less likely to do a personal outreach to another team member. This is true scalability.
Leverage analytics to see how this knowledge impacts your business
The last, and probably most important bit is to measure how these knowledge bases impact the key metrics for your business. At a high level, usage metrics should be tracked for each piece of knowledge being stored; how many times they have been viewed, copied, or favorited so you can see the most valuable content your team uses.
Team members should also be proactively notified about gaps in your team's knowledge by showing search terms your team is using that are not returning results. This way you can add this missing knowledge and let your team know once its available.
Finally, think about how you can tie these usage metric to your key business applications. Can we tie the use of content to more closed deals? Shortened sales cycles? Are new team members onboarded faster?
So whether its tactical insights, "are my team members using our knowledge base?", or strategic, "is my team executing better because of my knowledge base?" it's an often overlooked but critical part of your rollout strategy.
Experience the power of the Guru platform firsthand – take our interactive product tour
