A developer and a marketer are stranded on a remote island… After days of searching, they discover a coconut grove. The developer cracks open a husk, drinks its water, and hungrily devours its meat. The marketer extracts the oil, rubs it on a rock, and exclaims, “just look at that shine!”
Highlighting benefits rather than features is Marketing 101. With technical audiences, some advise against it: “just tell developers what features you support.” Indeed, I’m on the record saying Developer Marketing Does Not Exist, but we don’t need to throw out the entire field. The reason both features and benefits fall flat with developers is they’re often communicated the wrong way. Like the marketer on the island, you need to select the right benefits and share them in a way that resonates.
​​How Marketers Misunderstand Developer Benefits
As a marketer, you don’t miss the mark with a technical audience on purpose. In all cases, it’s your best attempt to position your product to appeal to the right developers. Yes, you’re usually hampered by a lack of development experience. An even greater contributor to your struggles can be your marketing experience.
There are only so many ways to share benefits. Most fall into one of these categories:
- Save time
- Save money
- Better product
When you lean on these common benefits too early, you may awaken developer skepticism. Rather than accept a conclusion, developers will begin a counter-argument in their heads. And that’s if you aren’t dismissed outright.
For example, you may claim “hundreds of development hours saved” or “cut your debugging time in half.” On the surface, that’s compelling—but what if it means they ship lower-quality software? Or perhaps it’s quicker to deploy yet a pain to manage? In engineering, there is always a trade-off. Devs may imagine the worst.
Money is also unlikely to resonate, unless it’s their own. Developers rarely hold the company budget, so they might not have enough information to assess these benefits. Also, they’ve heard enough claims to default to disbelief anyway. Finally, touting a better product is where many dev-focused marketers flounder. It’s a tenuous claim with any product, but can look insincere and “hand-wavy” to devs.
It’s these “benefits” that cause some to suggest that devs only need a list of features. Meaningless benefits aren’t the answer, but that doesn’t mean we need to throw them away entirely with technical audiences. In fact, leaning too much toward features has all the same downsides as non-technical audiences… plus a few more.
Why “Just Show Me the Docs” Doesn’t Work
Many developers themselves will tell you to “just show me the docs.” Indeed, marketers of technical products may turn to other audiences since they can’t contribute to this type of technical content. While documentation is important—and it should be part of your marketing strategy—you’ll want to provide more than simple docs for dev audiences.
When we think of documentation, it’s usually reference material that comes to mind. For APIs, it’s a list of endpoints, with request and response data. Command line tools may include the first and second-level keywords, along with the available flags. Whatever the format, these docs read like a collection of ingredients… with little to no detail on how to put them together.
Reference docs have their place, but that cannot be the end of your developer experience. When developers ask for this type of documentation, it’s because they don’t trust you to know how the pieces fit together. Just as you might be skeptical of a recipe written by someone who has never cooked, developers don’t want marketing docs. However, a portal with only reference is missing the important knowledge of how to properly combine commands and API calls to create an outcome.
You want to include use cases within your documentation. Like a recipe, these are opinionated implementations of your product. They often will only use a portion of the functionality, but with many, you’ll start to tell a more complete story.
Many Google developer tools separate documentation into three sections:
- Reference
- Guides
- Samples
Reference is the list of functionality. Samples package up a use case with code. Guides are the tutorial content that glues these two together.
You need both context and function in documentation content. When developers ask for the reference and nothing more… they’re missing out on at least half the purpose of documentation. Even worse, you miss the opportunity to teach them about the benefits—without the product pitch.
Developer Problems Unlock Developer Benefits
So far we’ve seen how both benefits and features can go poorly with technical audiences. On one hand, imprecise benefits often don’t resonate. But if we simply list the features—such as with reference documentation—we remove our ability to tell the story of why your product matters.
Rather than give up on features and benefits, you can use an understanding of your audience to find the benefits that matter. Let’s start with a couple of assumptions about developers, which we’ve seen to be accurate:
- Developers can’t be experts in everything.
- Developers like to solve new problems.
When you connect your product to one (or both!) of these assumptions, you can discover concrete developer benefits. What’s important is to start your communications from the problem, not the product. For example, consider the problem of user authentication. Most apps need it, which means it’s something most developers have built before. It’s not a new problem. At the same time, most developers are not security experts. User authentication is a perfect place to find developer benefits.
Auth0 uses these developer benefits to attract and engage a technical audience. There are similar opportunities within your product, even if you solve a problem that’s less prominent than authentication. While your homepage messaging is important, you’ll attract more developers with content that is directed at more specific problems. You can create tutorials focused on common use cases or blog posts and guides that educate developers about solutions. Just make sure your product isn’t the focus—that will get in the way of showing that you understand the developer benefits it provides.
Get Help Unlocking Developer Benefits
From within your company, it can be hard to see which benefits will resonate. Internally, the product is the point. That’s natural.
EveryDeveloper has worked with dozens of companies like yours. We’ve helped them connect their technical products to problems that resonate with the right developers. Our proven framework starts with a Developer Content Action Plan, then we move on to help you and your team execute it to attract developers who want the concrete benefits you provide.
Explore a project with EvDev and see how we can help you reach more of the right developers.