Nordic APIs has long tracked the API-as-a-product trend, where companies expose their products primarily through a developer interface. The companies that treat their APIs as an external product need to reach potential customers, but technical audiences can be difficult to attract. They’re often averse to traditional promotion techniques. So, how do you market to developers?

If you want developers to discover, use, and eventually pay for your API product, you need to change your approach. In my book, Developer Marketing Does Not Exist, I share the philosophy of “education not promotion” to reach a developer audience. In this post, I’ll give you the highlights. But first, let’s make sure your API product is developer-focused.

Are You Developer-Focused or Developer-Enabled?

How you market your API will depend on its intended audience. Many companies trip up on this step because they assume their users are exclusively developers. While that’s a natural expectation, it’s more likely you’ll be courting multiple audiences, with developers the less immediate target.

For example, let’s say you offer customer relationship management (CRM) software with an API. Your customers require a developer to build integrations and automations into their own systems by writing code using your API. Most advanced use cases will need code to make API calls or respond to webhooks. These facts lead you, the CRM company, to aim your marketing at developers. The problem is that most developers are not researching the right CRM API for their use case. In fact, it’s most likely to be another department —such as sales — that picks out a CRM. If developers are consulted at all, it’s to confirm they’ll be able to implement another team’s API integration use cases.

CRM APIs are likely to be developer-enabled, at the far left of this continuum:

At the opposite end are developer-focused APIs. Here you’ll expect to be solving a genuine developer problem. The API may replace code a dev might otherwise create and maintain. Or, perhaps it connects to cloud infrastructure. There is utility for a single developer in developer-focused APIs.

It’s too simplistic to pin APIs as either developer-enabled or developer-focused. The reality is likely somewhere along the developer marketing continuum. Chances are good that you know if you’re on one of the extremes. The risk for the CRM company — and any product with non-developer users — is to assume you need to market your API like a developer-focused company.

To enable developers to use your API, there’s a minimum bar for developer experience, documentation, and support. As you move up the continuum from developer-enabled to developer-focused, API marketing activities increase. As you’ll see in the coming sections, those activities look a lot different than traditional marketing.

Find the Real Competitor to Your API

Just as many companies mistake their audience, they also mistake their largest competitor. As Nordic APIs pointed out in its API-as-Product eBook, developers may attempt to replace your product’s functionality with their own code.

While some products are harder than others to duplicate, this competition is actually something you can use to your advantage. Developers love building. Their job is to solve problems with code and efficient solutions can be addicting. It’s no wonder that when faced with the problems your API solves, many developers will first think about how they would architect it themselves.

Try this with any developer, whether a potential customer or an internal engineer: describe a problem that could be solved with code. They may have a few initial clarifying questions. Quickly, it will be clear how their brains are wired for problem-solving. You can almost see the pieces swirling in their mind, like Sherlock Holmes as he deduces how a crime occurred.

It’s possible a competitor arises as a solution during this ideation process. But that’s only likely if the other company has already shown that they understand the problem space. More likely, the developer’s thoughts go to common platforms and frameworks, open-source tools, and the other elements they are already using to do their work.

The conundrum becomes: how do you compete with a developer’s instinct to use their current tools, many of which are practically or actually free? The answer: you don’t.

Help Developers Solve Their Problems

Rather than fight against this “build it myself” tendency, follow its momentum. Your marketing can speak to the ideas already swirling in developer minds. Take them down the path to build, run, and maintain a service like yours. You aren’t promoting your API with this marketing, at least not directly. Instead, you’re demonstrating your authority as a company that knows how to solve these problems.

I call this approach the Developer Content Mind Trick. It works in all types of content, but especially shines as a deep, foundational guide.

For example, OpenCage Data provides an API for reverse geocoding. Given a location described by latitude and longitude coordinates, their service returns a human-readable description of the place. Many developers appreciate that OpenCage is built on open data. They might also be tempted to piece together their own reverse geocoder using a combination of open-source software and community-generated data. A traditional marketing approach could have been to detail the features and benefits of OpenCage for these developers but hide behind-the-scenes details from view.

Instead, the company published a reverse geocoding guide to help developers architect and build a reverse geocoder. It includes contextual sections on use cases, why this type of geocoding is important, and how open data helps. Throughout, developers will get a sense of what it takes to create a solution (a lot!) and how much the OpenCage team knows about reverse geocoding (a whole lot!). Some developers will read this guide (disclosure: written in collaboration with the EveryDeveloper team) and go on to build a reverse geocoder — they can even follow a tutorial to get started. But, most will be convinced it’s harder than it seems and will use OpenCage instead.

Keep in mind, this type of content is not documentation. Your docs are essential, and they solve their share of developer problems. However, few developers will discover you through documentation, which is by definition focused on your product.

Your API marketing should focus not on your product, but on the business and technical problems your product solves.

Repeat Your Message Across Channels

Not every part of your API marketing can be 10,000-word educational guides. Fortunately, you can use the same educational approach to reach developers in shorter formats like blog articles, webinars, conference talks, and social media posts. In fact, my book includes chapters on open source, events, and tools, in addition to more traditional content.

What you want to avoid in your API marketing is switching into promotional mode. Remind your content creators about the effectiveness of education over promotion when it comes to developer audiences. Aim for consistency by sharing an understanding of your developer audience across your organization.

Remember the problems you solve and the way a developer will lean toward building the solution. Follow that momentum and show developers how you’ve thought through the solution they want to implement. They’ll appreciate the education while gaining respect for your authority in the problem space. The end result is that more developers will opt to use your product.