Many tech startups, especially open-source ones, treat marketing as a dirty word. Many of these founders were star employees and think that "good work speaks for itself."
As individual contributors, they only had to deliver great features to get recognition for their work. They were not required to promote their work - that was somebody else's job. So the hard work of marketing is invisible until the individual contributor turns into a startup founder.
Once programmers become founders, they realize that marketing and sales are the lifeblood of their business.
The squeamishness of marketing shows itself in the field of the developer relations role. Developer relations is a cross between a tech marketing and a software developer role. Developer relations professionals are called "tech advocates," "tech community managers," and "technical ambassadors," but their part is essentially the same - to bring software developers through a sales funnel.
Sometimes it's at the top of a funnel, at a tech conference where developer relations professionals give talks about their company's product- or it is towards the bottom of the funnel where the dev relations person is answering specific questions about the API.
Software developers can be very cynical about marketing. However, sales are the lifeblood of any business - so how can companies reach out to potential technical customers?
The answer is technical documentation.
As a developer, it's rare that you know how to use a new API or platform right away. A developer usually has to follow detailed instructions before they can build on top of an API. These detailed instructions take the form of documentation.
Documentation can come across dense and unclear. So when a software engineer stumbles across clear documentation - they are usually pleased and often go to places like Twitter and forums to express their delight.
Content marketers can use this to their advantage.
Developers tend to be very vocal about products and tools that make their job easy.
Programmers are constantly building side projects. These ambitious folks need good documentation to get them up within a day or two. If a developer has an outstanding experience with the documentation, they might sneak the API into the production codebase.
This is why many SaaS platforms have a free level.
As Jeff Lawson wrote in "Ask Your Developer", developer documentation is the ultimate form of marketing.
Now that you know the importance of documentation in luring paying technical clients. How do you get started? How do you turn this oft-ignored part of your website into a cash-generating asset?
Make sure that your developer documentation isn't stuck in the engineering team silos. Even if marketing teams don't understand everything in the guides, they should be able to make high-level suggestions.
Marketers can check for readability and flow of content. "Getting Started Guides" and general audience documentation should be scannable, and this is something that marketers are especially good at checking. No one, not even an engineer, wants to waste their time mired in jargon and spec-speak.
Run those guides through Hemingway Editor and push back on any writing that is sporting a Grade 13 reading level.
Not all documentation is created equal. Below are the different types of categories of documentation include:
Getting Started Guide: created for folks who are not familiar with the SaaS platform on a high level.
This should be part of the Top of the Funnel - TOFU - and can be distributed to people who have never heard of your platform before.
Cook Books: For developers who are familiar with the app and are trying to solve a specific problem. For example, if they are using Stripe, they know how to create a checkout, but they want to learn how to handle recurring purchases.
Cookbooks are at the Middle of the Funnel - MOFU. The programmer already knows and uses your platform. At this stage, encourage them to form a deeper relationship with your platform.
API Guide: This is the most low-level part of the knowledge base that gets deep into the code. If the developer is looking up a specific API call, this is a signal that they are building a serious application with your product.
They are officially at the Bottom of the Funnel - BOFU - and are receptive to paying for a solution that makes their workflow easier.
Be curious about the analytics on your documentation pages. It's important to know where your traffic is coming from. If most readers are coming from dev.to read your "Getting Started Guide", become more engaged with the dev.to community.
It's also useful to figure out how much time a reader spends on a page. If a developer spends more time on an API page than another, perhaps that particular page is not as eloquent in explaining a concept in comparison to the other pages. Always approach these results with an open mind and a sense of curiosity.
Note, if you are concerned about user privacy, you can anonymize users' IP with Google Analytics. If you are looking for an even more robust privacy solution checkout Plausible, Matomo, and Simple Analytics.
Once again, documentation should not be tucked away in the engineering side of the org chart. Documentation is a living and breathing part of your website. It should be updated regularly based on the reader's feedback. QA is in an ideal position to tell you what your users are struggling with. Wise companies take this intel and turn it into documentation.
What type of impact are you looking for? Just like with your blog posts, it's not enough to press publish and hope for the best. Figure out what you want your documentation to do for you.
Do you want the "Getting Started Guide" to inspire the user to reach out to a sales representative? Be sure to pay special attention to user flow. Do you want your webinars to funnel attendees to the documentation cook books? Set a goal and pay special attention to the Cook Book's traffic source.
Documentation has the potential to attract the type of business you want. The next step is to figure out what skills you need to write the type of documentation that attracts ideal clients.
Writing well means writing persuasively. Your writing should make readers take action. This action could range from- requesting a demo to signing up to a monthly subscription.
Some of the books I've read to improve my writing includes:
Everybody Writes: Very approachable book that emphasizes the importance of clear and digestible prose.
Ogilvy on Advertising: David Ogilvy is considered the godfather of modern copywriting. Some of his stories are slightly dated, but his lessons on good writing are timeless.
Ca$hvertising: Ca$hvertising is a deceptively simple read. It respects short attention spans and gets right to the point.
Selling is a skill and like any skill it can be learned. It doesn't matter what type of personality you have- in fact, many introverts excel in sales.
If this is your first time dipping into sales, I suggest reading all of the Stacking the Bricks articles. It's a free way to learn that sales is merely an exchange of value from one party to another. There's no trickery involved.
When you're finished reading through Stacking the Bricks posts, check out these books:
The One Page Marketing Plan: Very concise book that gets you from that first cold call to making repeat sales. This books gives you an excellent actionable blueprint to earning sales.
Book Yourself Solid: Fun fact, Michael Port is an alum of the Stacking the Bricks' companion course 30x500 Academy. Book Yourself Solid is a step-by-step plan on how to attract paying customers. And most of his tactics are free and very accessible.
Creating outstanding documentation is an accessible way to attract paying technical customers.
Every tech company should feel empowered to turn their knowledge base into a profit center.
Check out our podcast on remote work.