On Developer Marketing

What does great developer marketing look like?

1. Teaches how to build great products

When developers use a great tool, they're curious about how it's built. The best developer marketing taps into this curiosity.

What technology choices helped craft this product experience? It often comes down to the implementation (even great tools can be paired with skill issues), but they want to learn more.

Your product is your best marketing. Explain how you built an exceptional product with your own technology. Share how your customers were able to do the same.

Once you've captured their interest with your product, you keep developers engaged by focusing on the developer experience. Write docs worth sharing, filled with helpful diagrams and detailed descriptions. Create code examples and templates that help them get started quickly.

2. Builds and retains trust

Building, growing, and retaining developer trust is your most valuable asset.

Developers won't try your product the first time they hear about it. They need to hear positive feedback several times before they trust it enough to give it a try.

Experienced developers are skeptical of almost everything. It's hard to earn their trust. They don't want to contact sales, jump on a quick call, or get junk emails.

Trust is built by sharing helpful content (sometimes unrelated to the product).

• Be ruthless with your content editing and quality bar.
• Don't publish anything you wouldn't share yourself.
• Avoid buzzwords, acronyms, and vague explanations of the technology.
• Make sure every code example and link works.
• Be careful about overpromising simplicity.

This is often the job of Developer Relations.

3. Concise and precise

Great marketing values your time—every word matters. Show them how to build interesting things; don't fill a post with 1,000 words of garbage.

Imagine you're writing an email to announce a new version of your product. Perhaps pricing has changed, or there's a data migration.

• Put the bottom line up front: If I stop reading after the first paragraph, did I get what I needed to know? Is there action required? Put that in the email subject line.
• Make it easy to scan: The visual flow of the content is as important as the words you choose. They should be able to quickly scan for landmarks (like code examples or commands they need to run).
• Address their fears directly: This email mentions a migration. Am I going to lose my data? Do I need to make changes right away? By what date? Am I going to be charged more?
• Personalize the content: Show them their team name, the date the migration starts and finishes in UTC, exactly how much their price was before and after, and how they can take action (maybe a CLI command that shows their usage).

4. Builds a community

Developers are more likely to trust open-source tools. These tools likely have a community of other developers learning together. They can take their knowledge of the tool from job to job as they grow in their careers.

Community is built on trust and transparency. When something sucks with your product, own it. Don't try to hide the failure—lean into it. Bring the community along for the continuous iteration of your product. "You told us this was bad, and we fixed it." Follow up with people after you ship.

You should host hackathons or meetups. Spend time talking to developers 1:1. Their feedback drives product improvements and content ideas. Where are people struggling? Write about how you fixed that.