Product documentation 101 for startups

Most startups under-invest in their product documentation — when you’re busy with reactive customer support, it’s hard to justify proactive work like documentation. However, quality user documentation can dramatically reduce support team workloads and free up product development and customer acquisition resources.

Integrate documentation into your ticket lifecycle

The easiest way to build a helpful knowledge base is to enact a policy where you and your team always respond to customer support queries with a link to a document. When a customer asks a question, check if a document with an answer to that question exists. If one does, respond with a link to that document. If one exists, but it doesn’t quite answer their question, improve the doc and respond with a link. If a document doesn’t exist at all, take the time to write one up.

It takes a little more time to write a help document than to reply to a support ticket, but a little effort now will save you a ton of effort later.

Apply this same policy to escalated cases. When the support team cannot answer a question in most startups, they escalate to the product development team. Your engineers should respond with updated documentation.

A genuine commitment to improving documentation with each new support case will gradually transform your company. It’ll be easier to respond to tickets because answers will be readily available to your team. Customers will submit fewer requests because they’ll eventually learn to check the docs first. Training new employees will be easier.

Document new features before you launch them

Major feature releases can cause pain for customer support teams because they dramatically increase the surface area of the product for which there is no documentation.

The easiest time to document a feature is towards the end of the development process. It’s easy to forget the details of expected functionality over time. But, if you write documentation like automated tests — integrated into the development process¹ — you’ll produce accurate documentation for your team with little extra effort.

Documentation written by your engineers might require some finessing by your support team. Your team can improve documentation iteratively, though. It’s better to start with comprehensive and accurate docs than nothing.

Capture feedback and analytics

Great documentation is the outcome of sustained effort, and feedback is fuel for small improvements. Make it easy for customers, staff, and partners to submit feedback for any document in your knowledge base. This feedback should go into a backlog for your support or product team to promptly action.

Web analytics can be another valuable feedback mechanism. If you observe the traffic on your knowledge base, you can understand the areas of the product that people need help with or have an interest in².

Publish everything

Many teams maintain separate public documentation for their customers and private internal documentation for their staff. While there are occassionally good reasons to do this, this is usually a mistake. Teams with internal product documentation tend to publish many new documents internally first with the intention to later polish them and publish them for customers. The problem is, most teams never get around to this. Teams end up with great internal documentation repositories, and underwhelming documentation in production.

To solve this problem, ban internal documentation in most situations. Publish all documentation for customer use by default. It usually only takes a little more effort to polish an internal document for general availability. If you invest this effort in real time, your documentation will be a lot better.

Deflect cases

Training customers to check your documentation before reflexively contacting you about a problem can be difficult. If you require customers to contact you via a web form rather than email³, you can present them with useful user documentation before they submit their query. This tactic is called case deflection, and all good knowledge-base software supports it⁴.

If you don’t have any case deflection capabilities or even a knowledge base, collecting customer support enquiries via a form on your website is still a good idea. It can be excruciatingly difficult to transition customers accustomed to emailing you to a web form. If you start early, you’ll save yourself from pain in the future.

Pay attention to support metrics

Every support ticket you receive is a failure of documentation. When customers submit a case, they implicitly tell you that your documentation is insufficient or difficult to navigate or search.

Every support ticket you receive is also a failure of product capability and user experience. Great product experiences require less documentation (and manual support) than poor product experiences. Documentation is a hedge against product complexity, so the same insights that improve documentation should also improve your product if you pay attention to them.

Footnotes