Targeting your API developer relations program with personas

So you’ve built an API — can you work with Marketing to promote it?

It can be difficult to design a marketing strategy for an API-based software-as-a-service business. Some developer focused companies de-emphasize marketing in favor of organic growth, and some developers dislike the common conventions of marketing and advertising.

But marketing is a simply how you tell people about your products, and you’re going to have to do it even if some of your engineers are skeptical. Let’s find ways to build a bridge between developers and marketers by using language that both sides can understand.

So how does someone design a marketing strategy for an API?

Developers look for an appealing presentation of code and low-intensity sales process (Wikipedia)

What is a developer focused persona?

Many marketing professionals like to start by identifying the personas of the people who will be your customers. Traditional marketing practice asks us to define attributes about a customer such as their income levels, hobbies, favorite brands, and daily habits.

Identifying such attributes for developers can sometimes be helpful. You might discover that all your developer customers are into a specific type of game, and then you could have a board game table at a fintech conference or hand out Steam gift cards over Twitter.

It’s also possible to turn off developers by trying too many gimmicks. When a developer is under time pressure, they just want to get to the toolkit, look at its technical details, and determine if it’s right for them. If you add any friction into the process, they might just quit and go to a competitor that doesn’t have those same roadblocks.

The alternative I recommend is to identify developers’ working styles, and to create resources in a form that is useful for each working style. When developers find your tools and technologies on their own, they’ll become lifelong customers and they’ll recommend your solutions to others. You can still do traditional marketing — but you’ll know that an engineer who wants to use your product won’t be stopped cold by an artificial barrier.

Let’s break down a few personas that reflect different working styles.

Reading Ron: I only use reference documentation

Whether a developer is overworked or just introverted, sometimes a detailed explanation of an API is more approachable than a marketing pitch. When Ron gets busy, he doesn’t want to watch a sizzle reel, read customer testimonials, or talk to a salesperson. He just wants material he can use to solve his current problem.

Let’s consider how people complain about the lengthy stories that precede an online recipe. The blogger who published the article is a marketer: They had a great story, and they took the time to polish it and tell it vividly. But the poor overworked chef just wants to know how many onions to chop. Developers like Ron have the same challenge.

Let’s make it possible for Ron to bypass the fluff and get right to the details he needs. Here’s how to help Reading Ron:

• Give every API and data schema its own URL. This allows you to share a link that exactly answers a developer’s question, and it doesn’t risk distraction with unnecessary material.
• Every field in your data schema needs a definition, no matter how trivial. It’s hard to tell which fact will make the difference between a customer and a cancellation!
• Add URLs to your error messages that send your developers to a documentation page. Even better, add a forum discussion on the error discussion page so developers can ask questions about why something went wrong!
• Don’t put your content behind a registration or login barrier. Allow Ron to read all your technical material without creating an account.

Ellie Example: I like to tinker with a working sample project

Another type of engineer is one who wants working code upfront. In today’s complex software-as-a-service world, it’s reassuring to know that you have a working tutorial program and you can try changing one parameter at a time to see how its behavior changes.

Why does this happen? Modern systems can sometimes require lots of setup before you can begin making the API call that you really want. If Ellie tries to write the code from scratch, she may get discouraged and switch to a competitor’s solution before she creates a working application.

When you give Ellie some working example code, she can execute it and see its results right away. She can step through the code in her debugger, watch it execute, and start making changes so that the example will match her use case.

Example code can be useful for more than marketing:

• A good coding example will prove that your system works as expected. Example code can be used as an integration test suite, or vice versa.
• When you ask your developers to create an example, they will often discover little nuisances that were invisible to them before they tried to create a tutorial. It can force engineers to think through the usability of their API design.
• Open source example code can help an audit company construct robust security testing plans.
• Good examples provide business development teams with support to help them approach a new market segment.
• Hackathons, interns, and student outreach programs can be an excellent source of collaborative development for example apps.

Tommy Tutorial: I want to write my own code using a how-to story

The opposite of Ellie’s approach is Tommy’s preference. He doesn’t want a solution delivered on a platter, but he does want to read a step by step walkthrough while he writes his own code.

Tommy likes the experience of doing things on his own; he feels it gives him a better feel for the integration work. He may search for a tutorial that exactly matches his use case or he may be able to accept something similar that he can adjust on the fly as he works.

The good news is that Ron, Ellie, and Tommy can all share some of the same written material. If you write good reference documentation, example code, and tutorials, the content for each one will support the others. It may feel repetitive to you, but each type of working style will appreciate having the content available in a form customized for them.

The strategy of unified documentation, examples, and tutorials can be a huge win for everyone:

• When you plan a new feature, make a list of tutorials you will write and ask the engineers to make sure their API designs fit that use case.
• Engineers can write the reference material for each API and schema, and evangelists can combine it into blog posts for your site.
• When you ask an engineer to write example code, their experiences can help you write a great tutorial article.
• Your quality assurance team or SDETs can create example apps based off their integration test suites.
• When you hire a marketing firm to write an article for a specific vertical industry segment, the story should help guide the developer content.

SDK Sally: I want to add your integration from a package manager

The greatest innovation in software development for the past few decades has been the package manager. Tools such as nuget, pypi, npmjs, and rubygems have made it possible for developers to share tested and validated code far more widely than ever before.

Developers like Sally love integration work — but she prefers it when she doesn’t have to write her own integration. She would rather use your officially sanctioned developer kit. If she writes the API call herself, she worries that she might miss something in your documentation. Her solution might work, but perhaps it would miss out on performance-boosting features like compression, SSL pooling, or something else.

If she gets an official library delivered from a package manager, she trusts that you’ll make sure it works correctly. She knows that if you find a bug in the SDK, you’ll ship a fix soon enough. She doesn’t need to worry about whether it implements all your best practices, because that’s now your responsibility and not hers.

It’s tempting to say “REST is simple enough, you shouldn’t need an SDK” — but there are key features that Sally only gets with an official SDK:

• Inline autocomplete and hover-docs for every element and function call within Sally’s IDE.
• Automatic upgrade notifications whenever you change your API and ship a new SDK.
• When you deprecate an old API or field, Sally will get automatic context sensitive help showing which function calls are being phased out.
• Generating SDKs doesn’t have to be costly: If you use OpenAPI, you can generate SDKs for many languages using open source code with relatively little work.
• And, of course, most package managers provide usage statistics you can use to measure the success of your developer program.

Conference Carl: I like to meet people and talk software

Let’s talk about how we can handle developers who are extroverts. These people are perhaps at a different stage in their career, or perhaps they just don’t want to try out something before they are confident it will work. Developers like Carl are skeptical of software until someone convinces them that it will solve his problem.

This happens often when an engineer or analyst is tasked with exploring a new market. The field is big and daunting; and there are too many available options. Carl isn’t willing to just download an SDK or read a how-to article. He wants to talk to the vendor, to make sure they are committed, to make sure their staff is knowledgeable. Only then will Carl invest the time to try out a vendor’s software.

Developers like Carl need access to technical solutions team members, online webinars, or a booth at an in-person conference. Carl potentially hasn’t yet got an exact idea of what question to ask, so he wants to have a dialogue and to explore the problem with a partner.

Carl will certainly benefit from documentation, but he needs:

• A calendar of events where he can find ways to interact with your team members via webinars or in-person events.
• Webinars that have an agenda. Carl likes knowing up front whether the agenda will support his questions. He doesn’t care for office-hours or open Q&A type events.
• That said, if he listens to you talk about a topic and he likes what he hears, Carl really wants a question-and-answer sessions afterwards so that he can speak up and join in.
• When Carl reads a blog post or technical article that seems relevant, he wants a way to get in touch with the author.
• Carl is an eager user of discussion threads whenever he sees technical documentation that is relevant to him.

Bringing this all together: A unified developer marketing solution

It’s important to have sufficient documentation and resources available for developer before you spend the money to market to them. These personas can help you understand how some types of developers might make use of your documentation and resources so that they will stick with you.

This documentation and these resources will not attract developers to your company. You will still need regular marketing outreach, social media, and search engine optimization to find people who are not aware of your company. But when they learn about your company, these resources will ensure that developers can become customers.

I encourage you to prepare documentation and resource materials first, and then to unleash your creative spirit and your outreach efforts:

• Colleges job fairs or internship programs where you can evangelize your product to students before they join the workforce.
• Hackathons to build support among independent developers.
• Referral bonuses or affiliate programs that can encourage independent contractors to develop for your API.
• Fun events centering on logic and puzzles such as escape rooms, gaming cafes, and arcades.

What do the developers in your field find exciting?

Ted Spence teaches at Bellevue College and lives in West Seattle. If you’re interested in software engineering and business analysis, I’d love to hear from you on Twitter or LinkedIn.