Your help center is the home of all knowledge about your product. It gives your customers the information they need to break down their learning barriers and hopefully become expert users of your product. This makes it a critical retention tool.

Our product teams sometimes ship more than 100 changes per day. If you develop and ship new features as often as we do, it’s vital that your articles help your customers keep up with the changes.

As a writer of help documentation, I know that your work will only ever be as accurate as your last edit. Help articles can quickly become unhelpful, and even misleading, if you don’t review them often enough. At any given moment, I’d estimate that a small percentage of our docs are likely to contain some out-of-date information – it’s my job to bring that down to zero, and more importantly, ensure it never grows.

Focus on the fundamentals

Managing help articles is a process of constant prioritization. Depending on how often your product teams ship new features, you might have to be comfortable with a certain level of out-of-date material while you focus on the most important changes.

When you ship new features, some existing articles will invariably become inaccurate as a result. Whether it’s a screenshot, navigation flow or a complete change in how something looks and works, you’ll have to measure the damage that out-of-date articles could cause.

If you’re having trouble measuring this, ask your yourself: is your article fundamentally broken and confusing customers? Or is the inaccuracy cosmetic, and one that doesn’t harm your customers’ understanding of your product.

It’s like selling them a brand new car, but then giving them the old user manual.

If you’re confusing customers, then your help article is literally doing the opposite job to what it’s supposed to. It has become unhelpful.

But not all inaccuracies are equal. For example, If a “Save” button has been moved from the top of a page to the bottom, and now says “Update”, or if your product now auto-saves and the “Save” button was removed, these would be fundamental shifts in how your customer navigates through your product.

But, if the “Save” button has just changed color, sits in the same place, has the same name and performs the same function; this isn’t a fundamental change. Your article will still show your customers how to “Save” their work, in the right place, even though it might look a little different.

Visual changes, however, can be fundamental too. If you’ve refreshed your product’s interface, showing the old interface in help articles will disorientate your new customers. It’s like selling them a brand new car, but then giving them the old user manual. It might show them similar instructions, but it looks and feels completely different.

Ideally, if you have the time, you’d update your article in all of the above scenarios. But if you’re in a company where a high volume of product changes is as certain as death and taxes, a greater level of prioritization will help you keep your help center helpful.

Create a feedback loop that keeps on giving

Even if you’ve got a team of writers, fundamentally broken articles will nearly always be noticed first by the people reading them – your customers. They’ll notice when an article is out of date, if it doesn’t explain a process clearly enough, or if there’s a knowledge gap in your help center.

Almost all of our article updates are surfaced by our customer support team.

How do you get feedback from thousands of eyes instead of dozens? By building a feedback loop with your support team. Keeping your ears close to your customers is one of the most impactful ways you can keep your help center fresh. If you create a feedback loop with your customer support team and implement their suggestions, your help center will become a much more valuable resource in a matter of weeks.

If a customer finds something out of date on Intercom’s Help Center, our customer support team can easily let me know through the Messenger on our internal Product Education wiki page. I ask them to send me a link to the article, a screenshot of the specific issue, and a brief description of the problem and solution. I review their request and ask them a question or two before making the update.

Almost all of the updates we make to our articles are surfaced by our customer support team. Our close relationship with them is crucial to keeping our help articles as accurate as they can be. Instead of relying solely on our own audits, we can instead utilize our customers’ valuable feedback through this channel, and gather quality feedback at scale.

Write as they build

While you’ve got one eye focused on prioritizing issues with your current articles, the other should be firmly fixed on your product team’s upcoming releases.

As a member of the Product Education team, I strive to maintain an encyclopedic knowledge of our products. But true encyclopedic knowledge is never static. So I stay close to the source of knowledge at all times – product managers.

I stay close to the source of knowledge at all times – product managers.

At Intercom, the decisions behind building a feature, as well as building the feature itself, come from our product managers. As their teams plan, build and release in six-week cycles, I sync with them three to five times each cycle to understand the upcoming changes and prepare for these releases.

Our first meeting will generally cover high-level plans and release deadlines. I’ll get a clear idea of what each product team is working on over the next six weeks and why. The “why” is especially important for product writers, as it’ll allow you to firmly grasp why customers need a certain feature. You can then feed that knowledge back into your articles, and elevate your customers’ education with best practice guides.

I’ll meet the PM team again halfway through the cycle, to check on their progress and to see if they’ve scoped any new releases since we last met. We’ll talk about their releases in more granular detail, so I can gain a comprehensive understanding. When the product teams are testing a feature, I’ll try it out, document its functionality and develop best practices for it. Then, when we’re closer to a release, I’ll write and share a draft of my article so they can review its accuracy and help me fine-tune my best practices.

It’s important to ensure everything you write is accurate and that you grasp a feature’s best use before you even start writing. So stay close to the source of truth – grab regular coffees with your product managers (or hot chocolates, in my case).

Publish as you announce new features

Supporting customers with help articles from the moment a feature is released is crucial to getting them to successfully adopt it. If you don’t already publish help articles as soon as you launch new features, you should. It’s immediately after a feature release that your customers will have the most curiosity – and questions. If they search your help center and find no answers or guidance, they’ll get frustrated, and may even give up. Ultimately, publishing timely how-to articles and best practice guides will greatly improve your feature adoption rates.

So co-ordinate with your marketing team to publish the article as soon as you launch the feature. Indeed, go a step further – include a link to the help article in your landing pages and emails to customers, so they can learn about the feature as soon as you show it to them.

Keep it evergreen

Although their job are different, great help articles are like evergreen blog posts – if they provide your customers with actionable value and are periodically refreshed, they’ll continue to benefit your business long after the publish date. It’s challenging to keep your existing collections up-to-date while supporting new product releases at the same. But if you manage to strike a good balance, the benefits will be tenfold – you’ll activate more customers, increase their chances of becoming expert users, and eventually help them become advocates for your business.

At its core, product design is about cost-benefit analysis, and it’s key to determine how useful a certain feature will be versus how hard is it to build. Here is a useful framework to help your analysis.