As a company that makes knowledge base software, we’re innately biased towards the value of good documentation.
And yet many, many startups barely have any documentation at all. It’s just not a priority.
There is no room in any startup for any wasted effort, and yet we waste a huge amount of effort every day duplicating information, and searching for information vital to do the job. It turns out that what first seemed efficient is actually significantly hindering productivity.
It’s like being inside a labyrinth and believing there is a way to get to the end, when really you are inside an endless maze in which you’ll be wandering lost forever.
That’s what not having appropriate documentation is like. It’s impossible to scale a startup without proper docs. So why are companies failing to document?
There are many reasons why startup founders neglect their documentation in the early stages. You’re probably doing the job of ten people and flying by the seat of your pants. Here are some of the most common reasons.
First and foremost, the main reason that companies lack documentation is that they place no value in it. Instead, their focus is on departments that seem to relate more closely to the product, like engineering, product, and sales.
The truth is, documentation has the ability to help every department function more effectively.
Associating Documentation With the “Waterfall” Approach to Development
Many startups working in the agile methodology view documentation as an outmoded way of producing software. They interpret literally one of the four key principles of Agile: Working prototypes over excessive documentation. They believe this means that working software is all that’s needed, and documentation is essentially viewed as a waste of time.
This is a throwback from the days of Waterfall software development, when teams were required to produce a huge amount of documentation including requirements and design documents. Agile documentation covers only what’s needed.
Some startups out there do value documentation, but there are always more things to do. Writing documentation means taking time away from the important tasks that only keep piling up, even if documentation saves you time in the long run.
Documentation is about investing in the future, and many founders only have time to thin about today.
It may seem like a waste of time to document processes that are changing as quickly as you can document them. Documenting a process can also seem “inflexible” in a company that needs to grow and change quickly.
By the time you write the documentation, your team has moved on.
Doing anything as dry as documenting your processes can feel like it is stifling your culture. It’s likely grown organically and is something your company is interested in preserving. Standardisation might seem too official and stifling to an open and inclusive culture.
But being a documentation-first culture can be fun and progressive. Documentation means you favour teamwork and an open culture.
When it comes to software code, many developers believe that it should never require any documentation if it is written well. But there is a world of difference between code comments (which have value in themselves) and software documentation that tells you more about the software.
Useful software documentation includes tutorials, installation instructions, and answers to user questions. Documentation should also tell you why you built the product.
The company agrees that it would like more documentation, but no one is empowered to make it happen. It’s suggested that your support team should get it done “in their spare time”, or you might ask developers to document features after they write the code.
You generally lack a process for effectively producing quality documentation that fulfils a goal.
“The hallmark of successful scaling is knowing when to hit the brakes so you can scale faster later.” – Bob Sutton, Organizational Behavior Expert at Stanford
First and foremost, the majority of consumers agree that having high-quality product content is essential for:
Good customer service
Making it easier to solve problems on their own
Improving their impression of a product or brand
Making them more likely to recommend a product or brand
Making it more like they would purchase more products
Customer-focused startups should value documentation. And agile teams are innately customer-focused.
Here are some specific reasons why documentation is valuable for your business.
Documentation is a crucial part of being able to scale effectively. For one thing, it reduces the number of calls and emails your support team must handle. A single support phone call can cost up to $11 dollars, while a self-service support experience costs just pennies.
If you can convince more of your software customers to self-serve, this means you can hire fewer support agents to handle the same volume of customers.
Many startups sell products that are innovative in their industries, and customers may not be used to consuming your products using the “newer” model.
For example, Netflix was a pioneer in video streaming, when many customers had been using to renting DVDs from physical stores (oh, hey, Blockbuster) or even video cassette tapes. They couldn’t see why a service like Netflix was valuable.
Many customers wouldn’t immediately understand the new streaming model and why they should keep paying a monthly subscription. Documentation can help educate new customers and explain how the product works.
Many startups are highly focused on attracting new customers to their products. They are by definition breaking into new markets.
Unlike more established companies and brands, startups need to improve the offering for their customers. Studies show that 69% of customers believe that clear instructions indicate companies care about them, and their ability to use the product.
Documentation is a powerful way to increase consumer trust. Documentation can be about engaging with your community and investing in your existing customers.
Standard Operating Procedures (SOPs) are also important for startups that are growing quickly. Producing informative documentation internally allows you to delegate more effectively, and avoid the trap of relying on “gatekeepers” to disseminate vital knowledge.
SOPs make more of your assumptions explicit so you can decide to improve the way you do things more easily. It shows more clearly that the way you have been doing things has become, well, crazy!
Having comprehensive internal documentation shortens the onboarding process, reducing the need for in-person training. New employees can also refer back to the handbook as needed, without being afraid to ask “stupid” questions.
The handbook can inform an important part of your culture, and everyone has a resource to refer back to. Companies like GitLab have made their handbooks public to help others.
There is no way to improve documentation’s standing in your company unless you instill a value for docs at every level. Employees need to feel empowered to take the time away from other tasks to write documentation, or you must hire dedicated writers.
The amount of documentation you need should be weighed against the position you are in as a company.
A brand new company with only a couple of employees doesn’t need a ton of documentation. On the other hand, as your team is starting to scale, and you are possibly hiring many remote team members, it’s important to start capturing company knowledge in a more formalised way.
You need to find time to define what kinds of documentation you need and why. Not all documentation is the same.
It’s important to make a distinction between internal documentation that can help you standardise processes, software and API documentation aimed at making developers’ lives easier, and customer-facing product documentation.
You’ll need different types of writers to produce each type.
We would argue that end user documentation should always be considered as an essential part of the final shippable product. It is therefore the most important type of documentation to invest in.
Both working software and customer documentation are part of your Minimum Viable Product. End user documentation can be produced by support agents, dedicated technical writers, or by everyone in the company.
In the early days of a company it can be useful to produce content through a wiki, like Splunk talks about in their book The Product Is Docs.
What Splunk found is when their company was smaller, more people actually contributed to content in their wiki than after the docs team grew in size. Today, Splunk has a 20+ member documentation team, and hardly anyone else in the company contributes to the wiki.
When roles are more fluid in the early days of your company, it’s easier to convince the team to pitch in with documentation.
Adopt a Just In Time approach to documentation.
Instead of documenting absolutely everything, identify which support conversations can be turned into help articles and document them as required. And if you’re worried your documentation won’t be comprehensive enough, remember that the top 5 articles in a knowledge base account for 40% of total daily views.
Customer documentation is highly compatible with the agile methodology because it is about putting customers first. Any technical writers you have should be part of the scrum team. Any documentation tasks you come up with should be recorded in the same issue tracking software as your code.
Software documentation can be best produced in the same tools and methodologies as the code. If you are documenting the code for an intended audience of engineers, it’s best to use the same tools for documentation and code.
Using tools like JIRA or Git for documentation also means it may be easier to get content reviews from engineers in your team. They can more easily share their feedback in the tools they are familiar with.
Your engineers will be more motivated to contribute to the docs when they learn its value through experience. The docs process can act as Quality Assurance, throwing light on potential bugs before the product is released to market.
API and other software documentation is extremely valuable for developers learning the software for the first time, or even for engineers coming back to work they finished “ages ago”.
Some rapidly growing startups don’t have the money to invest in hiring technical writers. As the needs of your team change, budget allowances might fluctuate and your need for documentation might rise or fall.
Hiring freelance technical writers can be a good compromise. Many startups choose to contract experienced professionals to deliver a particular documentation project, and aren’t committed to hiring another full-time member of staff.
It’s not about producing lots of documentation, so much as identifying the types of docs that you really need. More documentation is not necessarily incompatible with Agile. In fact, documentation is essential to truly agile teams.
When a startup values documentation, it values its people and its customers. Taking the time to document means your company can scale more effectively.