Rebuilding a Knowledge Base for a High Growth Startup

When I started my job at Drift, I was there for many different reasons: To learn everything I could about our product, to disperse that knowledge internally and externally, and to set the tone for the rest of the customer advocates to come after me.

We were a team of 35, and little did we know that in 6 months we’d be a team of 100 with two offices on separate sides of the country with our knowledge base the go-to resource for customers and new hires alike.

So we laid out a game plan to take our little outdated knowledge base and make it into a library for all things Drift.

Here’s How We Started

The first thing we did was whiteboard everything that was wrong with our current library of docs.

They were all written by different people, using different formats, none of the docs were tagged to make them easily searchable, and some of them didn’t have any screenshots or directions that matched what our app looked like at that time.

That’s where we knew how to start: Taking the content we had at that time and streamlining it.

We’d use the same screenshot tool, use the same format for directions, and most importantly we’d add as many tags as we could to the docs to make sure that our customers could always find the answer to their questions.

Building the Backbone

In order to build a knowledge base from scratch, we had to learn everything we possibly could about how our product works. This is the most unglamourous part of the process.

We couldn’t back ourselves into a corner and try to bang out help docs without any background into how the rest of the organization describes and markets the product.

We had to talk to our customers, to come across the most outlandish use cases. Once we saw something we’d never come across before, we wrote it down and walked ourselves through the process so we could write out the process for our customers.

We talked to the product managers to understand how the product is supposed to be used, and the marketers to make sure that the image the rest of the world sees is reflected in the actual product itself.

Support isn’t a one dimensional position, being aligned with the rest of the company will ensure that our customers are getting a consistent experience from start to finish.

A New Help Doc For Each Product Release

We do things a little differently at Drift: We release a new product every month. That means our help doc library has the possibility of becoming outdated every. single. month. 😅

As a Customer Advocate, we are directly embedded on the product team. The role teeters on the edge of customer support, customer success, and product management.

We cannot dissociate ourselves from the rest of the team, in fact we communicate with almost every single department to make sure our documentation falls in line with the same messaging across product, marketing, ops, and customer success.

The week before every new “Marketable Moment”, as we call them, Customer Advocates sit down to write the documentation for the new product. After watching the dev team build, test, code, and retest the new product, we’ve watched the new feature evolve from the most rudimentary template to a well designed function, and can understand how the product works and how it doesn’t yet work.

This background helps when writing the documentation as it helps articulate how to use the product while mapping out directions on how to set it up.

Taking it to the Next Level

Now, we’re at a point where we have a pretty solid help doc library that doesn’t have much organization at all. So we're taking it back to the whiteboard to map out Drift Help Docs 2.0.

Building and maintaining a knowledge base isn’t a project that has a specific end date, which makes it all the more fun and exciting to keep learning from customers, understanding how our product works, and adding information to help empower and educate our users.