How to write a great Getting Started Guide

Imagine you've seen chatter about a cool new product on social media or via word of mouth from your friends. You go to the website for this product, you see what it does (generally speaking), you see that it's backed by a real company, you check out the pricing and determine that it's in your budget. This information is the core table stakes that every company website must meet.

This post is about what happens next.

Developers want more. More often than not, they will search your top nav for "Docs" and visit your documentation. This is because developers love to imagine themselves using your product before they actually sign up. What is it like to set it up? Do I need to connect it to my existing infrastructure, data, or software before it does anything useful? Will I need to ask permission from my IT department before I am allowed to use this product?

The importance of documentation

So now, ask yourself this question as a marketing leader: are you spending any time at all on your documentation? Your documentation will act as the core determiner of whether or not a customer goes from intrigued to an actual signup.

I like to tell my teams that documentation is the single most important growth vector for our product. Not only does it have the potential to quickly accelerate a prospective developer's decision-making process, but done well, it can also significantly enhance your SEO.

Of course, your documentation needs to be clean and well-organized. Spend a considerable amount of time on how your documentation is organized. Think about your product roadmap and how your documentation will need to scale over time to accommodate new features, products, and services.

As a marketing leader, I've always taken ownership of documentation as part of my marketing organization. Partly because I'm technical myself and value documentation tremendously, but also because I want to own the developer's decision-making process in its entirety.

The getting started docs

In addition to your broad corpus of product documentation and API references, you also want to focus a great deal on walking developers through how to use your product.

Now, you could (and maybe even should!) embed onboarding tutorials into the product itself. But the problem we're trying to solve here is enabling developers to imagine themselves using your product before they even sign up.

This Getting Started Guide should be prominent in your documentation taxonomy. It should be easy to discover and start using. The Getting Started Guide should be organized like this:

• Setup. Don't skimp on this part. Help developers understand what it will take to start getting value out of your product. What is it like to sign up. Will I have to wait for an email and click on the link before activating the product? Will I need to supply a credit card? When will the credit card be charged? How can I cancel it? Do I need to ingest data to get started? What format does the data need to take? Can I connect your product to my existing systems? Will my IT admin need to do anything to give your product permission?
• The most important feature you have. To borrow a phrase: "don't bury the lede." Get the developer to your most important feature as quickly as possible. Show them how to use it, and help them see that the value they're getting is pretty awesome. Use your product metrics and customer research to identify the "aha moment" in your product where your customers are inspired to turn from trial to paid. This is what you want to highlight as quickly as possible.
• The Guided Tour. Show off your other features. Tell a story with your product (invent a fictitious company or scenario, if you'd like).
• Context and other things to try. Developers have gone through the setup experience and seen all your features. Perhaps most important is to demonstrate to them the combined value of everything you have to offer.

The getting started experience

Embed animations, videos, and other interactive material into your Getting Started Guide. Again, the assumption here is that you're speaking to an audience that is imagining themselves using your product. Help their imagination come to life by making the experience engaging and interesting.

Developers who have already signed up and are going through your Getting Started Guide can skip the interactive content, but they may find it helpful to see your vision for the product as well.