At Soluto, sharing knowledge is extremely important to us. Our teams share updates every morning and at the end of every week, on Slack, in Facebook Workplace, video syncs with remote teams, task boards, morning coffee… you get the point. The amount of information shared is endless, and people that need this information are forced to consume it from multiple channels. Not only that, but since the product managers aren’t the ones marketing our finished product, but clients/sales teams are, so our clients occasionally get only a partial picture, leading to some scary scenarios like promising a feature that is not ready yet, or saying our product does something that it actually doesn’t.
As part of my role as a Product Delivery Lead, I serve as the liaison between sales (folks that need the info) and development teams (folks that have the info). Sales need info, and instead of spending the best years of their life looking for answers about features in numerous channels, they all just turn to me, so you can imagine the effects on my inbox… At some point, not only did I understand that my mailbox is exploding with basically the same questions from different people, but more importantly, that I am a blocker on their way to get the answer.
We needed a clear and concise single source of truth. We needed our marketing staff/clients/partners to have easy access to the most updated and accurate information regarding our product, and to make it easy for them to access that information effectively. We also didn’t want to devote ourselves to that and spend days in updating and rewriting the content we share, as the features develop.
At this point we had a pretty clear idea of what we’re trying to do (create an internal knowledge base), now it’s time to get down to business. First on the agenda – choosing what goes into your knowledge base.
Choose
Not everything should have the honor of appearing in our knowledge base. While we are proud of all the pilots, tests, new feature releases and other decisions we’re making – it’s super confusing to follow us and stay up to date with everything going on.
So what makes it into the knowledge base? Only features that our clients can actually get and use. Think of it like a shop – only the products that customers can actually buy right now are put on the display shelves. Products still in development stay hidden from view.
Another reason for choosing only fully baked features and default settings/features, is that we won’t need to update the information about them frequently. Low maintenance is key for this to succeed.
Side note – we still share our pilots and tests, but not in the knowledge base (that’s a whole different post…).
Organize
The next step was to map and categorize the first batch of features. But why go through the effort of categorizing instead of putting together an FAQ list?
Simple – we are looking to create something that is easy to use. While search is always an option, I want my knowledge base users to find the answer faster than it takes to write an email about it. So I want them to be able to navigate through this ocean of knowledge quickly and easily. Which brings me to the next point – how should I organize and categorize this content effectively?
Tip 1: Minimize the number of categories. 3-5 is an amount that can easily be scanned and acted upon. It’s not a scientific number, but you get the point.
Tip 2: Choose one categorization approach. It can be: user journey in the app, division by teams’ responsibility/business initiative, maybe features available for different customer tiers. You know better what will work for your team. We chose to categorize by a user journey in the service, as this is something that we don’t aim to change in the near future, we share same terminology between teams and it simply made sense for our team.
Tip 3: Use an Excel sheet to create one list of your features and a second list of categories. Then place each feature on your list into the category that fits it best. Some features will possibly end up being remotely related to each other, but somehow still in the same category. It’s just about time to add some hierarchy. Look at each category and the features inside and add few subcategories to group them better. You can add more levels (category -> subcategory -> section -> subsection etc). Here again, don’t go too deep, granularity will get your user lost – 3 levels should be just enough to cover it all. Try to split each category into 2-3 subsections and organize your features inside them. Looks better now? Hope so.
Here is how this part ended up looking on my side:
So now we have a nice excel with all our features mapped and organized, one tiny thing left – we need the actual content.
Prioritize
Remember, we began by trying to stop questions flooding your inbox from all directions. So the best place to start is those items that would eliminate the most questions. You’ll hopefully find some already written content – an email, presentation, etc, that you can use to describe some of your features. Don’t worry about recycling it – you’ll make it pretty later.
For the rest, you’ll have to create content from scratch. To do that, you’ll need to develop a structure that can guide you in describing your features.
Structurize
I found that creating a short and simple template that can be applied to all my features worked best. Try to strike a balance between focusing on the user benefits of the feature without ignoring the technical info too much. To assist in finding that perfect balance, consider the questions you’ve been asked the most (are those the versions that you support or the feature flow that is always not clear?) and work from there. Here’s the template we came up with:
| Title that helps understand what is the post all about
What is it? One sentence to describe the feature. Why should I care and what’s the feature goal (e.g. what KPIs it improves \ pain it solves) Tell your audience why did we spend time developing this feature at all. Make it relatable to a problem we are trying to solve. Full feature flow (if user-facing, add screenshots/video/gif) How is the user exposed to the feature? What’s his context? Technical details: This can include information on availability for different devices/OSs if applicable. If the feature is available by default or can be opened by request. Any important information that the reader should be aware of. |
Wrote a few important items? Share them now – no need to wait until the whole job is done.
Choose your perfect tool
There are several tools available on the market that can give you a solution for building your knowledge base. You can also always build your own website if you have such resources available.
I used Zendesk Guide because I was familiar with this before and it had all I need for a reasonable price. My parameters were:
- User friendly editor
- Customizable templates that look professional
- Ability to embed files from company cloud drive
- Ability to organize and structure my content easily
- I looked at how other services used the same tool (Zendesk) to build their knowledge base and tried to see if it’s easy to find the information there.
Other options can be Salesforce desk, Helpsite.io, Kayako self-service. Didn’t check them out, but they seem intuitive enough.
So now that you’ve chosen your tool and you have some good posts ready to be shared, this has to reach your users.
Reach and engage
Depending on your audience and your company communication tools you should decide on how best to bring this to public.
As my knowledge base was completely internal, I started with a short presentation to a relevant team – showed what we have now, explained the thinking behind it, showed some examples, promised that there is more to come and asked for feedback. I Followed up with an email a summary and a link to the knowledge base. And here’s where the fun starts: you receive a question whose answer can be found in your knowledge base? Just send a link to the relevant page.
If you got some feedback – make sure to implement whatever possible, show you care and you wrote this for them and not to enjoy yourself – you’ll get a higher chance for an engaged user.
For managing knowledge base tasks and feedback, we found that using a tool like Trello helped us a lot. We separated our tasks into three categories – “Items to create”, “Items in progress”, and “Items in production”. Teams can then comment on individual items, propose other posts, or get status updates. The purpose here is to get the main users on board with me, and we both benefit from this: I focus on describing the features that have the highest importance to the teams, and they get what they are really looking for and fail to find.
If you’re writing to an external audience, you can still leverage this by allowing comments under your posts, creating a voting mechanism, use a public Trello board or anything else that makes sense to you.
This is how, in a relatively short time, we created a knowledge base for our teams’ internal use. It’s being used successfully for the last few weeks and the feedback has been extremely positive. And my inbox? Suspiciously quiet.
Leave a Reply