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 process1 — 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 in2.
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.
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 email3, 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 it4.
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.
It’s possible to automatically generate documentation for APIs, making it easy to keep documentation specific and up-to-date. API documents are the most difficult documents for your support team to maintain and improve. Automating this process can empower your support team to focus on end-user documentation. ↩︎
Good help docs can be fantastic for SEO and organic web traffic. Users searching for general advice often land on help docs for products they don’t use. Do what you can to convert these guests into customers. ↩︎
Most live chat tools support case deflection, too. ↩︎
Generative AI will massively improve case deflection; green shoots are already sprouting up in this space. Good documentation will enable generative AI tools to provide automated customer service. ↩︎
24 July, 2023
Subscribe for advice
Free weekly advice covering product strategy, development operations, building teams and more.
Privacy and terms
I care about privacy as much as you do. I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.
The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.