Adam DuVander
Developers sniff out anything that smells like marketing. They are a tough audience, because they’ll ridicule you if they sense inauthentic motives. Even when you have good intentions, you can come across otherwise. Developers have high expectations and are extremely skeptical. For both of these reasons, a developer marketer’s job is difficult.
Your marketing messages to developers should not feel like marketing. You need to find ways to promote your product without promotion. With hype comes skepticism. The best developer companies have an authentic developer tone, which starts with really understanding where they’re coming from. Solve developer problems—help them get better—and you’ll have perennial fans.
Share Knowledge, Not Features Through the lens of education, “marketing” fades into the back-ground. In its place, your messages will intrigue developers to click, to dig deeper. You aren’t converting visitors to leads, you’re enrolling them in your class. Each blog post, tutorial, guide, or other piece of content invites them to learn more. The next step could be another lesson or even a signup, as long as it feels natural.
Your product announcements will become much more impactful when you’re sharing knowledge, not features.
Developer experience is not simply a well-designed site, though that can certainly help. It’s the sum of every interaction a developer has with your company, from before they even discover your website through being a veteran customer, assuming they make it that far. Attracting and converting developers requires that you give attention to how they experience your product. If you buy into the educational approach of “developer marketing,” then the developer experience you provide is foundational.
Take the time to understand the elements of developer experience and where you can improve. Then, as you attract developers using the methods throughout this book, there will be something real behind the promises. You’ll show not only that you understand them, but that you can really help them.
Don’t mistake developer experience for just design, just onboarding, or just documentation. It’s all of those things, plus more.
First Impression: Discovery and Reputation
A great method to reach more developers is through problem-focused content, using search engines to help developers find you. These important pieces of content get their own chapters throughout the book, but it’s important to point out it’s a rare first impression that you can control.
For example, let’s say a developer wants to implement an efficient location search feature in their app. To do this, they realize they will need to index their database for geospatial searches. Without the proper database knowledge, they turn to a search engine. Surely someone in the past had this issue and already fixed it. They may find StackOverflow answers and other discussions. If one search result mentions your tool, that may make a good impression. But what if they find your in-depth post showing them exactly how to add indices and some rough spots to avoid? Content like this can help developers discover you first and it goes a long way toward a positive first impression. At a minimum, you’ll endear yourself and your brand to developers. And if you happen to have a geospatial database product, you might even gain a customer. In order to make the problem-focused content approach work at scale, you’ll need to keep topics focused on developer problems, not your particular solution.
Tags: orange
Apply the “share know-ledge, not features” mantra across every message to developers. Your home page, if it is meant to reach developers, should speak to a technical problem. That doesn’t mean it needs to get into the technical solution. For years, SendGrid’s home page called out to developers with its promise to “Increase Email Deliverability.” That message likely resonates with other personas, as well.
One of the first things a developer will look for is your portal, documentation, or other signs of a section of the site specifically for them.
I like to play a game I call “find the API” where I see how quickly I can make my way from the home page to the portal.
First Experience: Getting Started and Onboarding If your developer portal could have only a single element on it, I would choose a big button that says, “Get Started.”
Your getting started guide is the ultimate initial experience. Choose a common use case and walk a developer through what it takes to use your product to solve their problem. You can’t cover everything with this guide, just the most important things to get started as quickly as possible. For a first experience, you want to decrease the “Time to Hello World,” the gap between reading the document-ation and writing the first bit of code on their own machine.
Your getting started experience should be the written form of the car walkthrough, written by someone who understands developers.
Avoid These Common Getting Started Mistakes
Use Cases and Sample Apps Time to Hello World is an incredibly important part of developer experience. Your getting started guide, onboarding, and other content takes a developer from the hypothetical to the actual with your product. Until developers have the first experience, you’re simply a tool that might help them. However, you don’t want them to stop. They must take a next step (or multiple steps) to arrive at the first success.
For developer experience, the first success is when developers have something that feels like a complete app or integration. They might not deploy this first success to production, but it’s an early version of something that could later be used. The most important element of a first success is to understand how developers want to use your product. The more about specific use cases you can include in your developer experience, the more likely they’ll be able to get to first success.
The key is to seed a developer’s imagination with common use cases so they can grow their own ideas. You aren’t stifling creativity or limiting possibilities by sharing the ways others use your product. It’s quite the opposite. For new products or startups, exposing use cases is harder. You probably don’t have a lot of examples to point to in production. However, the project was started, or the company founded upon at least a hunch—if not a bunch of proof—that the market needs your solution. Focus on those early problems you think are likely to be the most useful. Then create documentation and other content around those problems and your solutions.
To brainstorm a good list of use cases, consider some ways you might organize them: By industry By company size By customer segment By business department By type of developer (persona) You may find a single approach can get you plenty of use cases to help direct developers, at least at first. For example, Twilio is able to provide a deep list of 10+ use cases for its communications platform by focusing on business departments, industries, and company types. Behind each of these use cases are one or more products to solve a specific problem within an organization.
Sample applications are a great way to both communicate a use case and give a developer a quick win to get them to first success.
A great sample application will include: Full code needed to run the app Walkthrough tutorial explaining how it works GitHub repository that includes code and basic documentation Working demo to show how it looks when complete (optional) One click installation in cloud hosting, like with a Heroku button (optional) Case study of a customer who successfully runs something similar (optional) Interactive code explorer to pull in tutorial content while viewing the code (optional)
Elements of a Great Developer Experience
Reach More Developers with Frequent, Helpful Articles
The best way I know of reaching developers is through frequent, helpful blog posts.
Figure Out Who You Want to Reach Even if your website messaging and portal experience are developer friendly, it’s easy to let the blog slip into volume over value.
The more you know about them, the better your content can address their problems. And that’s the key which unlocks successful blog content. There are topics that your developers will research, and you want them to find you during the process. If they bump into your blog headlines, you want them to feel it hit a nerve, so they’ll click through to learn more. It’s rather difficult to do this without understanding a bit about the developers you want to reach, even at a high level. As yourself some of these questions: Do they work for big companies or startups? What programming language do they primarily use? Are they early in their career or just starting out? What’s their team structure like and what’s their role? What are some of the common titles they have? What departments do they support with their code?
For example, if your product is an authentication API, how might a senior Python engineer at a startup use it?
Leveraging even a small amount of information about your developer audience helps point you in the right direction. Based on these discoveries, you can more confidently arrive at educational topics that will help developers. In order to endear trust, you’ll want to cover the areas of your product a developer would otherwise need to build on their own. For the authentication API example, you’d want to cover OAuth and other standards, authentication best practices, and modeling potential threats. You could also look at language-specific angles at authentication topics—Python frameworks and libraries, code snippets and sample apps specifically geared toward Python.
Keyword research can help you further hone both your high level and granular topic selection.
Once you’ve determined who you want to reach with what content, you need to make it original. Every company has opinions—the organization was built upon them. There’s a reason your product was needed, and its important differentiators are within that viewpoint. While your blog posts should always be outwardly-focused on the developer problems, each should harness the company point of view. What do you believe that competitors don’t? Make sure your blog posts spread that belief.
With each blog post you pursue, you can return to these three areas and ask the questions: Who am I reaching? How can I share knowledge with them? What is the company viewpoint that will make this message most successful?
Make a Publication Plan
Start with where you’ll publish your technical posts. Ideally, these are on your company blog aimed at a developer audience.
In some cases, you may be starting a new blog. The process of creating a developer content plan is the same, regardless of where the posts end up. For best success, you should: Determine a cadence Constrain your focus Create a calendar Choose initial topics Share your calendar Stick to the calendar
A fewer number of great articles will perform better than many low quality posts.
In addition, I find it helpful to declare types of posts, so you have another way to constrain your topic selection. Here are some post types to consider: Tutorial: Walk through a specific problem and solution Vision: Share your technical thought leadership Best practices: Educate developers with practical tips Interview: Ask relevant questions of a developer influencer Comparison: Explain the pros and cons of two or more choices How we work: A technical look inside your organization Roundup: List of related technical choices with your analysis You may come up with some types of your own. The key is to limit yourself to two or three types, then use those to plot out your calendar. For example, you might choose two tutorials, one best practice, and one roundup per month. You can put that on your developer content calendar as a placeholder for the next three months. Simply drop them in every Wednesday (or whichever day of the
That’s the easy part. Now you need to get actual ideas for those posts. I’ve found this is much easier with a post type to work from. Connect your developer problems to specific post types and you’ll more easily come up with ideas that fit your audience and product.
At a minimum, you’ll promote to your existing channels, which likely include social, email, and on your website. You can also consider other communities that could be a good fit, such as Hacker News or specific subreddits.
The options for republication are always changing, but some popular choices to consider are: Medium Dev.to DZone
You want to reach more developers with authentic, helpful content that educates and inspires. When they have the problems your product solves, you’ll be top of mind.
Teach developers exactly how to solve their problems
Every story has a structure. In fact, Joseph Campbell dubbed it the Hero’s Journey and you can map many famous stories to it, including Star Wars. Tutorials also have a structure.
No content you produce will educate and inspire developers more than with tutorials. By their nature, tutorials are a solution, which means they can always be framed around a problem. Every content type can be problem-focused, but won’t always express the solution the same way (if at all). On the other hand, tutorials are special in that they walk developers through the exact steps needed to reach an expected conclusion. Tutorials are a foundational content type for developer companies.
The Ideal Tutorial Structure Some tutorials are long, some are short.
Here is the tutorial structure in four elements: Explain the context Show the end result Walk through the steps Help them take the next step
The natural question is: what’s next. Help developers take the next step, which could be hosting their project, connecting it to another tutorial, or reading a specific area of the documentation to gain even more context. Include a call to action in every tutorial to keep them on their journey.
Developer Tutorial Best Practices
Famously, Twilio took interactive learning even farther than the browser. The latest version of its TwilioQuest game is a downloadable package.
An individual tutorial may be rooted in a problem, but its details are in the technical solution. A guide takes a much broader view, with less emphasis on tools. It unpacks the details within the problem and best practices that set the context for a solution. Since there’s much more involved in a guide, they are typically longer. While you may produce dozens of tutorials, you’ll typically need fewer guides.
Gremlin provides developers tools for engineering resiliency and backs them up with in-depth guides. The concept behind its products is called “chaos engineering,” which imagines a monkey shutting off servers randomly. A system that can withstand that sort of chaos has built-in resilience. Gremlin’s largest traffic driver is its Chaos Monkey Guide for Engineers, a nearly 20,000 word unpacking of best practices and background. If you’re serious about improving your engineering operations, landing on that guide should build trust that Gremlin can help.
This “gating” of the guide has some serious downsides, especially for developers. For one, developers are notoriously skeptical of marketing. Exchanging an email address to read what you have to say (with no guarantee that it will even be the technical information they seek) is straight out of a marketer’s playbook.
However, when you go this route, there are upsides to open, non-gated content that you leave behind. The search engine traffic that deep guides provide will always outrank the lighter resource landing pages.
Similarly, developers will share a truly helpful guide that is open for anyone to read. You’ll see tweets and forum posts around the best developer content.
You can still use gated content alongside your open content. With this approach there are two likely choices: The exact content, in PDF form Complementary content
For example, an email course or files that help them get started might be something a developer would consider. If there’s a natural case to make for why you’d need their email address to deliver these, that’s all the better.
Similarly, you can bundle and unbundle it in many other ways. The most natural approach is to take pieces of your guide and turn them into blog posts. The simplest way is to use the actual content of the guide, but a more valuable approach is to take a new angle on existing material.
Meet Developers Where They Are with Authentic Interactions
As much as I believe in content to reach developers and connect with their problems, there is something special about events. Many companies use them to generate leads, which may be successful in certain industries. For developers, new business should rarely be the primary motivation. Instead, use the lens of “educate and inspire” to introduce your product to a technical audience in an authentic way.
When sponsoring a developer conference: Have a plan to stand out Be involved in multiple ways Focus on the developer
Some of the best approaches I’ve seen from conference sponsors have included puzzles or similar contests of skill. Developers love to tinker with problems and figure out how things work. If you can inspire them to grapple, you’re more likely to make a lasting impact. Sure, entice them with a prize, but it’s secondary to the experience.
One way to amplify your sponsorship is to find other ways to be involved. The best among these is a speaking slot.
For the companies participating, there are two primary reasons why a hackathon would make sense: Recruiting: Developers who write code on their own time are great hires. Feedback: Hackathon developers will try something new and tell you what they think.
Find Communities to Try Your Product
Build Something the Right Developers Will Want to Use
In a talk at Heavybit Accelerator, Runscope founder John Sheehan identified three rules for using the Runscope playbook: Don’t require a sign up Do one thing well Make it free
Before you or your team dive into code, it’s important to consider other options. There are at least three ways to execute the tool-as-marketing strategy: Build it Buy it Sponsor it
Another API tool, Postman, started out as a simple Chrome extension. The company is now valued at $2 billion based on its 2020 Series C funding. While no longer attached to Chrome, Postman has kept the same free functionality, which allows developers to try out API requests. Its product is robust, breaking the “do one thing well” rule.
With experiences like this all around us, developers put up their guard. It is the job of a developer, after all, to anticipate risks and mitigate against them. Naturally, they live their lives much like Ralphie must have after his secret decoder experience: looking out for the tricky advertising.
Sponsorships Should Be Partnerships Once you understand the type of developer you want to reach, it’s very likely somebody else is already talking to them. There are likely multiple publications, communities, or tools that attract the right developers for your product. Look for ways to partner with these properties in a way to get your developer tool some authentic attention.
You’re buying more than the attention of developers. You’re also renting the reputation of the person or brand you sponsor. When you truly partner with them, you give the best chance to earn some of that trust with the audience.
Among the places you might consider for sponsorship: Independent developer tools Blogs covering specific technologies Email newsletters on relevant topics Individual developer influencers Events with a technical audience Podcasts that discuss developer subjects Popular developer YouTube channels Anyone with authentic access to the right developers Developers support companies that sponsor their favorite communities. Ask existing customers what media they consume and use that as a starting place. Or find non-competitors ranking for your important terms and send off a cold email. Treat the sponsorship like any other important relationship and set yourself up to see results.
As you’ve read many times in this book, you will be more successful if you approach developers in a non-promotional way. For advertising that seems counterintuitive, but it largely still holds true. In some ways, you have more flexibility for promotion with advertising, because developers certainly know when there’s an ad.
While landing pages are a classic tactic to get leads, you’ll find developers are skeptical of any claims within. However, if you can show them authoritative, helpful content, they may be more open to your message.
Run ads with guide content as the promise. In other words, tap into the same understanding of the developer problem and put it forward in the ad copy, as well as the “landing page” a developer will see after you get the click. You can use the existing guide page, or create a special one for ads (which might help with tracking). Gate the guide, if you must, but the same arguments against that apply for advertising. Your blog post content can also do double duty as ad targets. Help your most successful posts reach an even wider audience. Many blog posts can be as useful as guides,
When you promote content, you can still use some of the tactics you might employ with any other landing page: Define goals for each visitor Provide clear calls to action Retarget visitors toward conversion
Here’s a sampling of what is required to build a developer audience: Discover a topic developers care about Express the topic in a way that attracts attention Expand your own understanding of the topic Continue to find new ways to make the topic interesting
Skills of the Developer Marketing Unicorn Developers are unlike any other audience you’ll experience in marketing. You need to understand their situation like you’ve been there yourself, reflect that back to them, and help them understand the next best step to take. The single individual who can fulfill the roles needed for developer marketing are rare. However, it might not be reasonable to hire a specialist in single skills. Instead, look for people who have aptitude for two or more of the common developer marketer needs.
Developer Pains Your team needs to put themselves in the developer’s shoes. This can be helpful while performing research, but also throughout your marketing activities. Of course, it’s easier to harness empathy if you’ve lived the coding lifestyle of your audience.
Growth: Move Your Most Important Metrics In recent years, marketing has created a new role—sometimes its own distinct department—called “growth.” Some use it as a synonym for marketing, without any other marketing department. In other cases, it’s distinct, but one thing that remains in all incarnations: the desire to see the numbers go in the right direction.
Documentation: Share Accurate and Updated Information
You should not expect immediate conversions from attending developer events. Beware of how blindly you track leads from certain events, because that may very well cause tone-deaf follow-ups. Allow your teams that work with developer communities to do their best work. Explore methods that will resonate, then your great developer experience can complete the conversion. Developer relations and documentation should not be expected to directly convert users.
Even content is difficult to track by conversion. Many times, the posts that attract initial attention aren’t the ones that get a signup. You can find fancy tools to distribute attribution, but it won’t catch everything in this multi-device, cookie-blocking world. By all means, continue to instrument your systems, but don’t hold content to an expectation it can’t meet. Instead, look at traffic patterns and whether topics match your developer’s needs.
You've seen how, regardless of the channel, you need to understand and address developer problems. You should seek to educate and inspire, not promote. Teach developers something new and you will earn their trust.
If you use regular marketing with developers, it will fall flat. At best, you'll be ignored. At worst, developers will ridicule your company. You want every message to resonate. Even product announcements should feel developer-focused, not you-focused. To achieve this, in all that you do: share knowledge, not features.
Blog Posts Reach more developers with frequent, helpful articles
Look up your most popular posts by traffic, then create three headlines for potential posts you can write that are similar. Tutorials Teach developers exactly how to solve their problems Make sure you have tutorials for your three most common use cases, with code in your three most popular programming languages. That’s nine tutorials—can you collect them all? Guides Show how deeply you understand what a developer needs Brainstorm a list of potential keywords you’d own if you could, then narrow them to a single topic, so you can begin outlining your Signature Content.
Developer Relations: Connect with Your Audience The soul of a developer company lives in its developer relations team members. Often misunderstood and misused, developer relations plays an important role between your company and the developers you want to attract. In the best organizations, the messages flow both ways—company to developer and developer to company, through the developer relations team. (Location 1642)
When your entire company is an API, it’s really important to easily test API requests. That’s how Twilio ended up buying a little developer project called Hurl. (Location 1289)
The second-most popular tool for Runscope was Requestbin, which was a companion site to Hurl. Also acquired from Twilio, Requestbin showed API requests from the server perspective. Rather than initiating calls from Requestbin, it receives requests, such as from a Webhook. These notifications, used by Twilio and other API companies, are often difficult to debug. With your own unique Requestbin URL, you could have a place to review the payload of each request without a bunch of setup. Some of the other tools Runscope developed, acquired, or sponsored: Authentication testing Embeddable cURL commands JSON object generator API changelog service HTTP status code reference Mock API server Each tool linked to Runscope and also embedded a tracking pixel for retargeted ads. The results were that Runscope was able to acquire the right developers for less than other methods. The company also used content, events, and other developer marketing techniques. But developer tools were the channel that performed the best. (Location 1320)
Developers are more likely to share a tool that doesn’t have a catch—such as a required signup or a paid plan. Just like a gated guide, a simple tool that requires an email address will increase skepticism. Finally, it’s easier to recommend something that solves a specific problem rather than a multipurpose tool. (Location 1343)
As you brainstorm ideas for your developer tool, search to see what else already exists. Often, you’ll find projects left behind by independent developers. You may even be able to acquire it with the promise to maintain it. Keeping a project going is tough, especially when it was started to scratch an itch or simply for fun. Even if there’s only a little traction in a tool, it’ll give you a boost you’d otherwise have to bootstrap. (Location 1371)
On that note, here are two rules, in addition to the three from the previous section, to get the most out of your developer tool: Give it its own home Keep it relevant to your product It can be tempting to include your new tool (either built or bought) on your existing site. You may be able to get away with it if there are many existing links. (Location 1384)
For example, a tutorial that solves a specific problem is likely to encourage a developer signup. You can run ads against the terms used to research the problem, with your content as the result. Just as you likely see conversion to a free or trial account as organic, you should similarly see it with your ads. In general, the more helpful your advertising experience is, the better. Said another way: the less it seems like an ad, the more comfortable a developer will feel taking the actions you want them to take. (Location 1499)