Documentation: The Ultimate Marketing Tool for Developer-First Products

Building a kickass developer-oriented platform quickly became a personal, gripping challenge for us. Being geeks and developers at hearts, we had to create something our own team would be thrilled to use. Most importantly, it had to be presented the way we would’ve liked it to be presented to us: no loud marketing push, no bright flashing signs. Yes, digital and traditional marketing efforts can indeed help build buzz and traction for products. But we think we wouldn’t be great at all that marketing stuff—we’d rather code. That being said, we’d be lying to you if we told you we didn’t use any marketing tools (to be fair, we’ve also got a marketing-ish guy). As a matter of fact, since our launch, we’ve been using the ultimate marketing tool for Snipcart: our documentation.

After years of extensive research done on unsuspecting, productive developers (read: our team and friends), we came up with four principles justifying why documentation is an effective marketing tool when selling a developer-oriented product.

A developer’s mind: four starting principles

1. Developers hate being sold to

Don’t push clever copy and optimized CTAs down a developer’s throat. It’s not worth the try. Don’t try selling products to a developer. Instead, show them what you’ve built, or what they can build with it. Developers are paid to solve problems. Most of the time, they are smart, sharp-minded individuals: they like forging their opinions based on their knowledge and information. They rightfully want to decide and figure out on their own if a product is good or not, and why. For them, rationality trumps emotion: old-school marketing manipulation probably won’t do the trick.

2. Developers value geek talent

On one hand, developers have a tendency to despise blatant marketing manipulations, but on the other, they crave intelligence and geek talent. You’ve built a useful product that’s technically impressive and reflects a smart, well-crafted train of thought? Now that’s something they can get behind. When discovering some new product or technology, they’ll tend to judge its value on the cleverness of the idea and the required talent to execute it.

3. Developers love code

When evaluating a web platform requiring any kind of coding, their primary reflex will be to look for code snippets. Talking about code won’t get you far. They need to see it: show them the code! That's why we try to get pretty technical in our content efforts (see this post on Node.js/Harp as an example). Showing them code samples will allow them to understand and judge the quality of your programming skills: the languages and standards you’re using, how you’re naming your variables, your indentation, etc. Esthetics must be refined; nothing should be overlooked. When showing code, you will be judged.

4. Developers don’t get fooled by online advertising

After all, they’re the ones who’ve engineered it. They’ve been on the Internet for so long that the rare ones who aren’t using AdBlock are almost immune to any kind of banners. We believe that, at this point, developers’ brains have been rewired to automatically ignore advertising banner throughout the web. While this doesn’t mean you’ll get no results from your PPC campaigns, it might mean your efforts/results ratio won’t be legendary. You can read about our thoughts and lessons learned from running an online ad campaign targeting developers on the blog.

3 reasons why documentation is a killer marketing tool for developer audiences

So we’ve exposed what a developer’s mindset and product-searching behaviour look like. Now, let’s dive into why exactly documentation will help you get developers onboard:

1. Documentation is bullshitless

Writing a good documentation requires technical depth and product knowledge. Straightforward, actionable content with no makeup reigns supreme (if written by sales people, it will inevitably show, turning off your audience). At its core, documentation is bullshitless: you can’t document features and APIs that do not exist.

2. Documentation is proof that you value customers, not only prospects

The amount of effort and time invested in your documentation will show that you actually care about your true customers, not just your prospects. Documentation is a well-organized bundle of resources dedicated to users actively using your product; it’s evident aim is to make their lives easier by providing them with the information they need to make the most out of your product. It’s not about conversions, hooking strategies and new signups: it’s all about the service/product you’re offering.

3. Documentation is a dynamic representation of your platform

You can easily build an ass-kicking, conversion-optimized product homepage that you won’t even have to touch every time you build a new feature or fix a bug. An ass-kicking documentation, on the other hand, is a dynamic initiative; it must match the evolution of your platform. Every added value, every new feature must be continually integrated in your documentation. It requires steady effort, and it will evolve throughout your development process, reflecting the care and effort you put in your own platform. At the end of the day, an unmaintained documentation is the reflection of an unmaintained platform!

Discovering a new product: a developer’s journey

We’ve poked our busy designer a few times and got him to create this quick infographic showing the typical behaviour of a developer discovering a new web application. Hopefully, this can give a clearer picture of their thought process, and highlight why your documentation will play a major role in it.


Bottom line is that developers hate being treated like idiots. They want the raw facts, and product documentation is by far the best way to give them what they want.

As for ourselves, we took the time to improve our documentation a while ago. We know it’s far from being perfect, but hey, it’s a continuous effort, like we said!

We sincerely hope you enjoyed the post. If you did, please share it wherever you see fit! Your thoughts on documentation and developer-first products are, of course, more than welcome in the comments below. :)

Suggested posts: