How to build a product knowledge base
Last updated: March 2024
Finding what you need, when you need it. It is a simple concept, but can be a real challenge for customers as they use your product. Whether they explore your software with a free trial or are seasoned pros, you want them to have a positive experience.
The ability to access quick, clear answers to any product question that pops up is central to that experience. This is why software companies typically have support teams and a product knowledge base. Establishing a knowledge base (sometimes referred to as a knowledge hub, support wiki, or help content) is a powerful practice in customer understanding and a key part of delivering a Complete Product Experience. You need to be acutely aware of the problems customers are trying to solve when using your product — then help them make the most of your offering as quickly as possible.
Maintaining our own knowledge base is an essential way we support Aha! customers.
Ready to tackle your own knowledge base? Let's walk through the fundamentals together. Use the following links to jump ahead to a specific section:
What is a product knowledge base?
A knowledge base provides self-serve support documentation for customers. Beyond answering how to do something in your product, a great knowledge base functions as a continual source of learning — so customers can become superusers and even loyal advocates.
Components of a customer support knowledge base can include:
Resources for getting started: Enable quick account setup for your customers
How-to articles: Show users how to get the most out of your product
System broadcasts: Keep customers aware of the latest product functionality
Release notes: Track product improvements and bug fixes
Videos and tutorials: Enrich customers' understanding with multimedia
Integration guides: Help customers use your tool alongside others in their tool stacks
Ideas portal: Capture and analyze customer feedback
Support-related contact information: Make it easy for customers to get additional help
A public- or customer-facing knowledge base is different from internal documentation. (By contrast, internal documentation includes things such as market research, team processes, onboarding information, and the like.) Although both types of documentation are essential for product organizations, this article primarily focuses on customer-facing documents.
Related: Internal vs. external product documentation
Why you need a knowledge base
Confident. Grounded. Clear. This is how you want customers to feel when using your product. However, understanding all the functionality of enterprise software is a big ask — especially for a brand-new customer. Helping them chart a successful trial experience can determine whether or not they choose to continue.
Some product builders will say that if software is intuitive enough, you do not need a knowledge base. That might be true for simple products with limited use cases. But if you have (or aspire to have) thousands of customers, folks will come to your product with varying levels of experience and expertise. Building clarity around how your product works best for an individual's role or organization helps empower them to use it well. It is especially convenient for folks who like to learn at their own pace and might not want to reach out to customer support. (Quiet customers can also be the most challenging to understand.)
We like to think of our knowledge base as being useful to customers as well as colleagues and the business. Consider these benefits:
Knowledge bases build trust: Put simply, a well-organized, up-to-date knowledge hub shows customers and colleagues alike that you take pride in their success and aim to provide fast, accurate answers to their product-related questions.
Knowledge bases increase product adoption: Knowing where to find updated product information, how tos, and best practices accelerates your customers' understanding of how to use your software — increasing the likelihood of adoption and usage.
Knowledge bases save time for your support team: When customers are able to access quick answers on their own, the support team can spend more time on trickier issues. Team members can also provide links to more comprehensive resources from your knowledge base when answering customer support tickets, which helps them respond to customers faster.
Another less obvious benefit? Documenting product functionality and best practices requires you to think deeply about what customers need to know and why. This practice pushes you to think through features from a user's point of view. And it helps you draw connections across areas of the product that customers use in tandem.
What to include in your knowledge base
Earlier, we listed common components found in a knowledge base. Let's talk about these a bit more deeply. It is worth noting that your own product's knowledge base might or might not include these components — it will depend on your product portfolio and customer segments.
Type of documentation | Examples |
Resources for getting started | These documents provide step-by-step instructions that make it simple for any customer to begin using your software right away. Here are some examples of getting-started resources from our knowledge base: |
How-to articles | From basic to advanced, how-to articles form the backbone of your knowledge base. Here are some basic examples: And some advanced examples: |
System broadcasts | System broadcasts or notifications include your most recent product announcements and launches.
|
Release notes | Release notes include new or updated functionality as well as bug fixes across products. At Aha! we publish release notes every Friday so customers have access to the most up-to-date information.
|
Videos, tutorials, and more | Go beyond basic support to include engaging content geared toward continuous learning. This can take the shape of how-to videos, live event recordings, best practices articles, and more. Some examples from our knowledge base include: |
Integration guides | Integration guides make it easy for customers to use your tool alongside other applications in their tech stack.
|
Ideas portal | If a customer has an idea about how to improve your content, make sure they have a way to share it.
|
Support-related contact information | Provide customers with phone, email, or live chat support.
|
In addition, you might consider adding these features to your knowledge base:
A search bar that allows customers to find what they are looking for
Accessibility features such as semantic HTML structure, keyboard navigation, alt text for images, and video transcriptions
Localized content for international users, if applicable
Advanced features do not need to be added at the get-go. Prioritize what will be lovable at minimum and enhance from there.
5 tips for building a knowledge base
A successful product knowledge base is structured, streamlined, and current. Follow these tips to build your own:
1. Start with strategy
Before you draft any customer-facing help articles, level-set on the "why," "what," and "when" of your knowledge base. Put together a project brief that includes details such as:
The objectives of your knowledge base
Target audience or customer segments
Success metrics for the knowledge base (such as page visits, number of help documents used in support answers, or the average age of documents)
Sections, categories, or types of documentation you will include
Voice, tone, and style considerations
Technical considerations
Timeline for implementation
2. Outline your document hierarchy
You might or might not need to include all of the documentation types we listed above. A knowledge base is a work in progress. Basic resources for getting started will likely take precedence over more advanced features and functionality, especially at first.
Organize content in whatever way makes the most sense for your customers. Create parent folders and subfolders to arrange the information logically. For example, our own knowledge base is organized by product type. Subfolders that dig deeper into each product area are nested beneath. Basic articles are listed first, followed by more advanced content.
3. Choose a knowledge base tool
A knowledge base tool gives you a centralized repository for organizing, storing, and publishing support content. Of course, we are advocates of our own software because it is purpose-built for product organizations. It includes rich text formatting, guided templates, and an AI assistant to speed up content production.
Whatever tool you choose, make sure it supports both your and your customers' needs. It is always wise to start a trial before you commit.
Here is an example of a support knowledge base created using Aha! software.
You can try our knowledge base article template to get started fast. It includes sections for a concise summary, step-by-step instructions, relevant permissions, and FAQs. You can also embed visuals like screenshots or videos where applicable.
Try this template now — with a free trial.
4. Define internal roles
Who will request, draft, approve, and publish your help content? The team members involved will depend on your organization's structure, size, product types, and release schedule. A knowledge base typically has contributors from product management, customer support, marketing, and technical teams. Many organizations hire technical writers whose main focus is managing, writing, and updating help documentation. At Aha! we release new functionality weekly and update help content continuously. This is made possible through close coordination among our knowledge base managers, the marketing team, and our product managers.
5. Build out processes
Detail how content will go from concept to completion — including ideation, production, publishing, and updating. Document the relevant steps and hand-offs in an internal knowledge base. This way, the broader team has visibility into processes and decision-making.
A note on maintenance
It bears repeating that a knowledge base is a work in progress. It evolves as your products and customers do and is never "done." The trick is finding a balance between new content and ongoing updates.
We recommend the following practices:
Align with product releases: Plan new content based on major functionality and launch dates.
Use a scorecard: Prioritize updates based on factors such as customer impact, time sensitivity, and effort.
Maintain a backlog: Add requests and nice-to-haves to a backlog to address as time allows.
Listen to customers: Encourage users to provide feedback, such as suggesting improvements or flagging inaccuracies.
Integrate with your other tools: Make content production simpler by integrating your knowledge base with the other tools you use.
Add support documentation to internal onboarding: Test the usability of your knowledge base by incorporating it into internal training and onboarding programs for new hires on the team.
Building a knowledge base can feel like a big undertaking. So start small, plan wisely, and roadmap your way to success. Be relentless in showing users that you care — they will love you for it.
