Blink twice if you are the type of person who reads every user manual for the products you buy.
I'll go first 👀 👀
Reading user guides makes me feel in control. I think that I can use a product to its full potential.
If you are looking for a growth loop, I would say that documentation is essential for developer marketing. If developers are your target market, just create awesome documentation (looking at you, Stripe), and you are better off as a marketing investment.
And that's what a developer will do: they will google your business to see if you are legit, they want to scan documentation, and they make up their mind really fast.
When you sell to developers, you need technical documentation because even if they are not the decision-makers, they influence the deal (based on the Stack Overflow Developers survey 2020). And even if developers might not make the final decision, you probably won't get far if they say no.
Why do you need to start product documentation as soon as possible?
Documentation refers to any type of information written to explain to the user the functionality or architecture of a product, system, or service. According to a BPTrends survey, 46% of companies claim that their processes are less than 25% or not at all documented.
And I get it. For a startup, documentation can easily get overlooked because it's hard to see an immediate return on investment.
However, any company launching a new product or version, regardless of how large or small, should train its users about it, what it is, and how to use it. Are training sessions for users better than documenting the product? Here are my reasons for believing technical documentation is necessary it the form of a meme:
Users always need handy documentation. This is a form of always available support for them. Basically, it consists of a guide with step-by-step instructions, as well as code snippets. Since this is the case, almost all product-based companies invest heavily in technical writers and in documentation.
Who should write technical documentation?
The chicken and egg question.
Most often, technical writers create documentation with the help of designers, developers, and subject matter experts. In some cases, product managers make documentation themselves or founders in the case of startups.
It's no secret that developers dislike writing documentation. This isn't what they do. Yes, that is correct, but any developer will also tell you they hate reading undocumented code. So good documentation is necessary, but how do you get started?
As part of our recent GitHub App launch (currently in beta), we developed an app to simplify technical documentation by writing it in markdown in a GitHub repository. We'll fetch the repo and the `/docs` by default if you install the app.
So, why technical documentation is important for B2B SaaS
Technical documentation is intended for customers, employees, and curious people who want to learn what they can do with your product.
Still, if you are a technical founder, increasing revenue is one of your goals. There are several ways to accomplish this. Even if you only focus now on growing the user base or just building the product, you need to grow revenue at the end of the day.
Documentation impacts revenue in multiple ways: it reduces support tickets and customer service expenses, increases team productivity and developer efficiency, reduces onboarding time (for customers or employees).
Creating and maintaining product documentation is definitely something that you should do. It should not be "technical" (meaning it should not be confusing) but rather outcome-oriented. It should be designed to assist developers in achieving their goals with your product because it will help retain them since they will see its value.
There is another hidden cost of development that you should consider. Your developers or support team may need to refer back later to technical documentation.
Your team's technical documentation might differ from what you publish externally for customers, for instance. You could provide documentation to new engineers as part of their onboarding process.
Also, having technical documentation readily available benefits developers outside of your company. If you want to outsource an integration or a piece that needs specific skills, they may need more information about how your software functions to create a custom integration.
Therefore, writing technical documentation takes time and effort. It may be helpful to think about the audience of your documentation (internal or external), what they will need from your documentation, and how they will use your information. Once you've done that, just try to avoid common documentation mistakes.