Build it and they will come. That might work for ghosts and baseball fields but, sadly, it’s not true for APIs. There’s nothing worse than spending months developing an API, or any other product for that matter, only to see it flounder after launch.

When it comes to API marketing, we’ve previously written about how compelling demos, API sandboxes, and evangelism strategies can turn people on to your API, but what you really need is something that users can’t help but become advocates for themselves.

That will probably sound familiar to those of you who deal with marketers or work in startups, and are used to people singing the praises of MailChimp and covering their laptops with stickers from brands they believe to be the next big thing. And we all know that one guy from the conferences who won’t stop talking about how much they love Twilio!

Speaking at our 2016 Platform Summit, Adam DuVander, formerly of CenturyLink Cloud and now in Developer Marketing at Zapier, shared some of the lessons he’s learned from his time in developer relations and covering APIs for ProgrammableWeb. And, umm, it all comes back to pie…

Wait, Did You Say Pie?

Adam talks a lot about about PIE in his presentation, both the type that you eat and a neat acronymic breakdown for the types of API users:

• Partners
• Internal
• External

The pie analogy works well in Adam’s presentation, thanks in part to great image selection, but can seem a little crusty (sorry!) in text form. That’s why, for the most part, we’ll be focusing on the acronym above when we talk about PIE in this article.

An obvious first step in thinking about how to promote your API is to look at who currently uses the service. If your pie chart shows that 80% of calls to your API are from those within your organization you’ll be taking a very different approach than if you had, say, 70% use by partners only. We’ll talk more below about how this can shape your advocacy strategy.

Regardless of who you’re promoting your API to, one tip provided by Adam always applies: “The way that you tell people your API is good matters.” In particular, he advises developers to share knowledge, not features. That link will take you to some of Adam’s (very useful) thoughts on the subject.

Who is Your Competition?

While it’s certainly worth thinking about services you’re directly competing with, Adam suggests “your most common competition is probably [not other competing companies, but] that developer.”

In other words, it needs to be obvious why your product is more effective than accessing the database directly (internal), entering data manually (partners), or using another service (external).

So how best to do that? One example Adam provides based on his experience with previous companies is that you can use a guide to demonstrate potential users that using your service is a lot easier than building something internally to take care of it.

Adam also highlights that, despite what many might think, competition is also a factor internally. When potential API consumers have direct access to the database, or can find a convenient workaround to scrape data, you need to distill the reasons they should use your API instead very potently.

Show Your Face

Adam notes that if “you’re at an API conference, that means you are the face [of your respective APIs].” By similar logic, if you’re reading our API focused blog, it’s very likely that you’re also the face of your API. But what does that mean exactly?

It means that, in addition to creating a stellar API, you also need to be the person raving about it to your colleagues, tweeting about interesting stuff it can do, or maybe even talking about it with customers directly, as appropriate. Even if the spotlight makes you uncomfortable!

Below are some ideas on where you’ll probably want to talk about your API, depending on what type of service it is:

Give People a Fork

An incredible API without any useful information or promotion is like putting a delicious pie on the table without any forks; only those who are really hungry, and willing to make a big mess, will try it.

Again, how you approach this will depend on whether your API is designed for Partner, Internal or External use. Technical data is useful for API consumers who work at Partner companies and are developers themselves – and speak your language as it were – but it’s less helpful for folks within your organization who may have limited technical knowledge.

In most cases you’ll want to provide more information than just technical documentation, particularly if you want to enable as many people as possible to use your API. Examples of getting started materials include:

• Integration into frameworks (“SDKs/wrappers are great ways to get someone started.”)
• Example real world use cases
• Complete sample apps
• Tutorial walkthroughs of applications
• GitHub repos with ready to deploy code
• Clear instructions for low friction code deploy

One really neat example of this is Box’s API Navigator, a productized tool designed to make using the Box API easier. Another example, highlighted by 3scale.net Developer Evangelist Nicolas Grenié in the comments of that page, is that Stripe now integrates working Runkit examples in their API documentation.

Look Ma, I’m an API Evangelist!

As recently as ten years ago, a job description like “developer advocate” or “developer evangelist” might have raised eyebrows. In 2017, however, it’s a position that more and more companies are eager to fill.

Skyscanner, for example, has their own developer advocate whose LinkedIn and Twitter pages they link to at the end of blog posts relating to APIs and the like. Google is another company that has taken steps to create dedicated developer advocacy positions.

If you’re doing any of what we talked about in the section directly above this one then, odds are, you are an API evangelist…whether you realize it or not. The interesting thing about developer/API advocacy and evangelism positions is that, as Google’s Mark Mandel highlights in his blog, the job description is still extremely fluid:

“The whole developer relations space, and the various roles that are found in it, seems to vary quite greatly as you move from company to company, team to team, and even within individuals within teams.”

Just because you weren’t hired to be a developer/API evangelist doesn’t mean that it doesn’t, or shouldn’t, fall under your remit. It might, however, mean that you need to see about getting a raise if you’re doing a ton of extra work to promote your company’s API…

Final Thoughts

Evangelism and advocacy are, to a certain extent, two sides of the same coin. In many cases, the terms are even used interchangeably. But the bottom line is that the better job you do of evangelizing (or advocating, if you prefer) your own product, the more likely that your users will become advocates too.

If you take one thing away from this post, let it be this: creating a simple and effective path to using your API is as important, if not more so, than creating a great product…although, obviously, you should always be aiming to do both. It really doesn’t matter too much whether you call that evangelism or advocacy.

API experiences that are truly compelling are few and far between – you might think here of services like Twilio, Flickr, or Google’s suite of APIs – while others like Facebook and Twitter have muscled their way into popular developer consciousness purely because of how indispensable they are.

If you can make yourself indispensable then that’s great. If your API is more of a luxury, then building something that’s easy to connect to, is well-documented and provides great use case examples is the best way to fast track your users – whether they’re Partner, Internal, or External – on the path to advocacy!