How to Create Great Documentation for Your Business Processes

Jacqueline
9 min readNov 25, 2022

--

Documentation probably isn’t the first thing you thought of when you launched your business. If you want to scale, though, you need to focus on it as soon as you can.

Image: Shutterstock / Built In

Even though I believe in the undeniable value of well-organized and comprehensive documentation for any business, I’m the first to admit documentation isn’t the sexiest thing to spend time on as a startup.

After all, everyone knows an early stage founder’s list is long and other things may have more curb appeal. Building a world-class product, taking it to market, learning from your first customers, forging partnerships, and fundraising may seem like the best uses of your time at the beginning of a startup.

But chances are that you know in the back of your mind that you’ll eventually go from an operation run by you and your co-founders to actually scaling with talented people. When that time comes, having a single source of truth in your organization will be important. In fact, I would argue having great documentation could actually be essential for getting early hires excited about the clean, organized house they are walking into!

If you take a look around and notice a slew of processes that only you and your co-founders know how to do, read on. You can go from a founder-led operation to being able to confidently hand the reins of some processes over to an early hire.

HOW TO CREATE DOCUMENTATION FOR YOUR BUSINESS PROCESSES

  • Clarify what documentation means for your business.
  • Decide on a tool to house your documentation.
  • Create an organizational system for your documentation.
  • Create and maintain documentation.

Clarify What Documentation Means for Your Business

You can think of documentation as a central place where people on your team can go to find out how your processes work. Unlike a current sprint cycle update or quarterly revenue report, your documentation is information storage for elements that don’t change often. This could include things like brand logos, first principles your team follows, brand voice style guide information, or step-by-step instructions for how and when to issue refunds for products.

For our businesses, documentation is essentially a how-to guide on how everything works. Think of it as a manual for the business just like the ones that came with all the appliances in your home. Most of the documentation is a step-by-step breakdown of things we do often. If you’re doing the same process over and over, that’s a good indicator that its description should live in your internal documentation.

Decide on a Tool to House Your Documentation

Our team has a simple rule in the businesses regarding our tech stack: We spend a reasonable amount of time picking a tool, and then we stick with it.

This rule helps us to avoid the trap of ignoring switching costs in favor of jumping onto the latest, marginally better tool. Once we find something we like and know how to use, sticking with it it becomes a forced constraint to keep things simple. If the tool can’t do something we want (like a font change or different background color), we simply don’t do it. Carl Richards talks about how this works in this short video clip.

Many tools may work for storing your documentation. In the very beginning, you might outline everything in a Google Doc. It’s easy to maintain, you’re able to organize the content with headings, and it’s easy to copy and paste everything into another tool once the document is too lengthy. So, if using a Google Doc helps you start the process of documentation today, that’s a great choice.

If you’d like something more robust than a Google Doc, Notion is a tool to consider. In fact, you may find an existing Notion template that you love and that saves you time getting started. You can see examples of how other startups have used this system to build their documentation here.

Our team decided on ClickUp. There were no special considerations other than it’s the tool we had already been using for task and project management. For us, letting our documentation live alongside the tasks and projects made the most sense because team members would often need to reference processes when during work.

As Richards further shared recently, shiny new tech toys are always going to appear, and they’ll probably have some handy additional features you could make use of. But your business is probably fine without them. The initial excitement around new features might make you forget that switching costs time, energy, and capital.

I’d recommend using the tool you have. A compounding effect happens with continual use. If something isn’t working the way you want it to, the problem may not be the tool. For example, if the organization of the documentation no longer feels intuitive to new hires, consider changing a process first, not doing away with the tool to switch to the newest thing everyone is talking about. Maybe making a change in how the documentation is organized or creating a new hire guide for better navigating everything will do the trick.

Create an Organizational System for Your Documentation

Over time, we landed on a two-tiered system for organization.

We primarily organize processes by tool. We found that it’s easiest for onboarding new virtual assistants and getting them up to speed with the processes they will need to know. When a question pops up, it makes a lot of sense to head where you have a question based on the tool you are using, such as Shopify, Kajabi, ConvertKit, or WordPress.

Let’s say for example that a new hire isn’t sure how to add a new product to Shopify. We had two options for where to store this information: under all the documentation for that particular business (for us, this is the Behavior Gap Sketch Store business) or we could list this process under the tool being used to add new products, which in this case is Shopify. Other businesses and projects that use Shopify will also have their documentation listed in the Shopify section alongside the Sketch Store documentation. This may seem like a small decision to make when you are getting started, but once your documentation grows over time, the way you approach such organization is essential for people on the team to find what they need easily.

Our secondary organization system is by product. Inside much of the product documentation, we link to processes found under the tool that is being used. This allows us to outline what’s happening inside a product that uses multiple tools. This secondary organization makes the most sense for someone who wants to learn about the product in general but isn’t sure which tools that particular product uses.

Let’s go back to my previous example about the Sketch Store and how to add a new product in Shopify.

If we had organized documentation solely by product, the documentation for how to add a new product in Shopify would have lived under “Sketch Store” and repeated again under other products that use Shopify within their product section of the documentation.

Your documentation is only as strong as the ability of someone to find what they need quickly. Think through the mind of a new hire who is told to add a new product in Shopify for the Sketch Store. We thought it made the most sense to find this process in the documentation listed under the tool, which is Shopify, rather than the business or product that uses the tool, which in this case is the Sketch Store.

But over time, we have found that organizing by business or product is still important in some cases. As a secondary way to organize the information, we created sections in the documentation for each product, and we link to all the processes using different tools. We think of this as a secondary organization tool since it’s used less often than searching for processes by tool.

Here’s how our documentation is currently organized in ClickUp:

Image: Screenshot by the author

Since launching our first go at documentation in 2019, we see that once a new person on the team is familiar with the products, they will spend most of their time inside each tool’s documentation so it was a good choice for the primary way to organize the information. This is where they will find dozens of step-by-step processes and instructions to make their daily tasks clearer and easier.

We also have a section called “Recurring Tasks” that has a table for VAs with all of their recurring tasks’ names, a link to the documentation for that task, how often it should be completed, and when it was completed last. This helps keep VAs organized with their tasks, and onboarding new VAs much easier.

Here’s how the recurring tasks section looks:

Image: Screenshot by the author

Once a new person on the team is familiar with the products, they will spend most of their time inside each tool’s documentation, which is where most of the documentation lives. This is where they will find dozens of step-by-step processes and instructions to make their daily tasks clearer and easier.

Create and Maintain Documentation

It has now become second nature for virtual assistants who work with us to spend about 25 percent of their time creating and maintaining documentation. Anytime a tool changes and a step-by-step guide needs to be updated with a new flow of instructions, they make that change so someone else can follow the new process.

We default to written instructions in a step-by-step, numbered format supported by screenshots if it’s helpful for the reader to see how something looks. We avoid linking to pages outside our ClickUp ecosystem so that we don’t have a risk of 404 errors throughout the documentation. For example, rather than link to a Kajabi page about how to use their software, we would write that step-by-step process out ourselves in our own documentation. It doesn’t take much time, and we may even copy and paste a tool’s documentation word for word, but the added benefit of not having broken links in the future outweighs the extra effort.

We also often use internal Loom video recordings to share a process for the first time with a virtual assistant, which I talk about here. Our documentation always defaults to a written format, however, and does not include Loom videos.

Here’s why…

If a video recorded three years ago is our only record of a process, it will soon become an outdated snapshot. Chances are high that a process has changed since the recording. Maybe the tool we are using went through a redesign to its back-end or the team uncovered edge cases after doing the process a few dozen times. Plus, reading a 10-step process with screenshots is much faster than watching an eight-minute internal tutorial video.

But there’s no need to get too precious here. Because multiple people on the team maintain the documentation, we allow everyone to write in their own style. The only requirement is that any documentation have enough information for someone else to be able to follow it in the future. We’ve noticed that virtual assistants learn quickly what makes for great documentation once they read documentation someone else wrote and they are still left with questions. It starts to become clear what it takes to write instructions that are easy to follow.

We have now started to ask virtual assistants before hiring them how comfortable they are with following processes written by others, documenting processes on their own, making edits when existing processes are unclear, and if they would feel energized by spending about 25 percent of their time working on documentation overall. Having virtual assistants on the team focused on building out documentation using our initial organization framework has meant that our founder, CMO, and I can focus on growth of the companies, new partnerships, and strategy without worrying about the liability of knowledge existing only in someone’s head.

This article originally appeared on October 4, 2022 here: https://builtin.com/operations/create-business-documentation

--

--

Jacqueline
Jacqueline

Written by Jacqueline

Jacqueline Jensen is a COO, former venture-backed startup founder, TEDx speaker, author, and Royal Society of Arts Fellow.

Responses (1)