The last thing startup founders want to think about is knowledge management.
It’s way less exciting than shipping new products and features. It’s way less sexy than perfecting that design and brand. It’s most certainly way less exciting than fundraising and negotiating a term sheet. But, consider these situations that will be on the horizon for you and your team:
- What are you going to do when you hire your first sales team member and they need to get up to speed? Are you going to be the one that fields a million questions they’re going to have before they make their first call?
- What happens when you gain traction and you start getting customer support queries? Will the founders have to make themselves available to field every question that requires clarification, day and night?
- How will you ensure that your product, support, and marketing teams are all on the same page when using branding, messaging, and promotional pricing?
If it isn’t obvious from these questions, startups face a shortage of time and resources. If you want to get the most out of your runway, you’ve got to have a plan that doesn’t depend on the founders and employees providing non-stop support to the team. So as unsexy as it may sound, it’s a knowledge management problem. Your team cannot afford to waste time or resources on getting new and existing employees up to speed on the ever-growing, perpetually-changing body of knowledge.
To propel your startup forward toward success, the team will need to be able to self-serve support from a comprehensive knowledge base for the purposes of getting individual work done as well as helping others. But, that knowledge base won’t just magically appear; it needs to be built. It will need to be easy to capture knowledge on the fly and shared with ease.
Building a knowledge base involves more than just choosing a knowledge base software and running with it; it takes more deliberate planning and it pays dividends to research your options thoroughly so that there is a good fit with your workflows.
Before you start building your knowledge base, you might ask yourself some of these questions:
- What kinds of information do we want to store?
- What kind of problem the knowledge is meant to solve?
- What format it is optimally stored in?
- How it will be accessed?
- How often it will it need to be updated, and who will do that?
Taking the time to be rigorous about your knowledge management strategy will feel difficult at first, but it will bear fruit in the near future. In the following sections, we’ll outline the common structural considerations that startups must take to build a powerful self-service support engine.
Periodicity: Frequent vs occasional access
Do you think that a customer support resolution script is a piece of knowledge that you might access more often than, say, the company’s vacation policy? If you work in customer support, chances are that it is. It’s something that one might copy and paste into multiple emails a day. Planning for knowledge that is frequently used should be an important structural consideration.
It is up to individual users to decide what level of frequency is excessive for accessing knowledge, but if you are keeping a browser tab open or accessing a specific customer support script one or more times a day, that’s a strong indicator that you use it a lot.
The more frequently you access knowledge, the more it pays to isolate that data or information into its own focused knowledge base entry. Some knowledge base software tools are designed to utilize dedicated formats for frequently asked questions, and this is to simplify access, deliver faster results and improve focus. Sometimes it helps to remove text styling (eg. bold, bullets, italics, etc.) if it enables faster resolution.
Some examples of knowledge that is frequently accessed are:
- Instructions for common customer queries like “How do I reset my password?”
- Programming or deployment scripts
- Addresses or contact information
For less frequently accessed information, you may choose to continue to use a simpler format as described above, but if the goal is more for learning or covers more broad sweeping topics, you may choose to store knowledge in a long-form document or wiki format.
Examples that suit long-form knowledge that is occasionally accessed are:
- Standard Operating Procedures (SOPs)
- Culture documentation
Situational use: holistic learning vs issue reference
When a new sales team member is onboarded and looking to consume a broad body of knowledge, their goal is learning. But when the same sales team member is preparing for a sales call, they may require a competitor battle card to have access to the most salient points and potential objections expected in the conversation. The context in which you plan to use knowledge should be incorporated into your knowledge base structure.
Not every piece of content in a knowledge base is optimally stored in a long-form format. Often the distinction between choosing formats is deliciated between the knowledge seekers intent to either for learning or for reference. In situations where the user is simply looking for knowledge that is used for reference, consider retaining it in a snippet format, as in the competitor battle card example. In other cases, such as learning environments or when more than one concept/idea is required, long-form composition would be a better fit.
Examples that suit long-form knowledge intended for the purposes of learning a broader topic are:
- Standard Operating Procedures (SOPs)
- Culture documentation
Collaboration: static knowledge vs dynamic collaboration
Does a job require the participation and contribution of numerous stakeholders, such as when aligning product, marketing, and customer support need to deliver in each of their own roles? How about when a customer support agent needs to offboard a churned account – what Standard Operating Procedure will they follow to avoid any additional customer satisfaction? These situations both involve similar parties, but in one case, the knowledge used it standardized, and in the other, it the knowledge may depend on strategic, seasonal, or other subtleties.
With this in mind, another important consideration is to decide on whether a document will be static or dynamic. Static documents change infrequently, if ever. Often, the key distinction between static and dynamic documents is that dynamic knowledge is often collaborative in nature, so it important to track who contributed the knowledge and when. The most common knowledge format for dynamic knowledge is a wiki.
Declaring a document static implies that it the reader can expect that the content was created by a central subject matter expert and that the content shouldn’t be edited on the fly. In the dynamic use case, a team member might want to contribute some suggestions, context or feedback to a document to help improve a knowledge seeker’s understanding of the current state of affairs. From a structural perspective, you might want to have both in your organization. Be prepared to invest in a knowledge platform that is suitable for each use.
Examples of static documents include:
- Culture documentation
- Onboarding instructions
- Policy documents
Situations where documents are better suited for dynamic use-case are:
- Projects that are collaborative in nature where the content changes from day-to-day
- Strategy or marketing documentation
Fragmentation: Silos vs Centralized
Is it possible to keep all of your documentation, knowledge and collateral in Google Drive? Will the developer team prefer to use Confluence and Jira for their collaborative purposes? Why exactly do sales teams prefer to use Dropbox for sharing files? These are all questions involving the platforms that you choose to house your knowledge. Often there are competing priorities, even in small companies, that influence where knowledge gets compiled and stored.
For very early stage startups, aiming to build a centralized knowledge base is an attainable goal. Founders often begin storing knowledge and a variety of documents in Google Drive. In a way, this creates simplicity and elegance because it makes it easy to know where to look. This, of course, assumes that users maintain rigor when it comes to file structures and naming conventions.
Invariably as your startup scales, your needs evolve and different technologies are more appropriate for various purposes. Maybe Zendesk fits into your customer support strategy better, and maybe Confluence is more suitable for your product and engineering teams. Whatever the case, this increases complexity in your knowledge management structure, and this complexity is what is commonly referred to as siloed knowledge.
There can be a number of challenges associated with silos, but the most pressing issues involves universal search across all silos (often called “federated search”). Knowledge seekers productivity can be impeded by a lack of a single source of truth when being confronted by the complexity of silos.
In the end, you want to aim for the simplicity of centralization, but when you are scaling towards a more complex knowledge structure, seek out solutions that are federated search compatible to deal with the productivity lost by these hurdles.
Integrating your knowledge with your workflows and operating systems should also be an important part of planning for the structure of your knowledge base. Take some time to carefully consider where knowledge will be captured, accessed, and shared. For many startups, this will happen in all the platforms where they communicate and collaborate internally, like Slack. Whatever your work platform is, the internal knowledge you exchange through collaborative mediums should fit seamlessly into the places where conversations and work happen.
Building a startup is hard, but its even more challenging when you are trying to scale the team without relying on trusted documentation to deliver support whenever and wherever it is needed. Spend time upfront developing a strategy that enables your team to work independently and bring you to product-market-fit as fast as humanly possible.