Developer Engagement: Braving the Wilds

One of the challenges for any API provider is creating a compelling and meaningful developer engagement model. At its core, any engagement model is considered marketing. But everyone knows developers don’t like to be marketed to. That doesn’t mean they don’t want to be engaged or have someone enthusiastically build a community for them. Understanding that dynamic, first and foremost, is the key to great developer engagement.

Marketing to the Makers

There are a few mantras I live by in running Developer Marketing for DevExchange:

• Be Knowledgeable
• Be Informative
• Be Open
• Be Vulnerable

These are all related concepts but they manifest themselves in different ways at different times. I also think that these concepts will work for anybody who is tasked with marketing products or tools to the people who know how to build them.

Let’s walk through them and some examples of how we’ve incorporated them at DevExchange.

Be Knowledgeable

Talking to developers means being able to converse with a degree of confidence about their discipline. On DevExchange, our marketing team is charged with promoting API products and Open Source tools. We must be able to talk about endpoints, resources, CURL, JSON, YAML, etc., and understand how all of that fits into the producer/consumer world.

That sounds basic but actually, it can be more difficult than you’d expect. Generally, marketers are adept at expressing value props, customer journeys, even developer experience concepts. But they don’t write or consume APIs, usually, and finding a developer-marketer for your team is hard at best. But it’s just like any other product — domain knowledge is key to being able to put all of that together. My team actively pursues technical education and stays very close to their counterparts in development so they are immersed in the lingo and conversation as much as possible.

Even beyond the domain knowledge, it’s important to understand the product your teams are building. Knowing the operations and resources is part of it, but you also need to be familiar with how the payload is constructed, whether there’s a callback URL, are there scopes in place that determine the data that gets returned or the actions that are available? Being able to answer questions and go at least mid-level deep about an API is key to engaging in real, meaningful conversations with developers.

Be Informative

The best developer marketing enables rather than positions. Developers want you to get right to it. Don’t tell them how great your product is — they’ll be the judge of that. Tell them what it does, how it does it, and offer them technical content to help them leverage your API. Give them a way to try it right there on your site.

The best marketing content you can offer for your API is sample code and technical documentation. All our APIs are required to have both, as well as a reference app, before they can launch. We make all of that accessible as open source in GitHub and easy to find in our portal navigation.

If a developer has a starter kit for our API with code snippets, documentation, tutorials and educational content, that’s the best marketing you can offer.

We also make sure we are building complementary content in our blogs and on our site about coding in general, specifically mobile and language-specific content. Much of our blog content is focused on tutorials and how-to articles.

Be Open

Too often, companies wait to solicit feedback after they’ve already committed resources and environments to an API concept. The “Design First” approach to building APIs allows you to get your API into your consumers’ hands early. Using the API definition, you can generate mock services with some pre-defined data and run some IRL experiments. Host a hackathon using those mocks or set up a Gitter instance alongside your API documentation. Then sit back and listen.

This means creating an environment both internally and externally where open conversations can happen. We host small hackathons almost every month and often use API prototypes to start a conversation as early in the cycle as possible. That means we’re being transparent about the ideas we’re kicking around internally and giving our product teams an open channel to their potential customers so we know we’re building the right thing.

Being present and in person is important for this part. Gathering feedback is more than just hearing what people say, it’s also about looking at what they do. Did they employ a use case you didn’t consider? Are they asking a lot of questions that you thought the documentation covered? Are they giving up on your API before they’ve built something interesting? Is everyone building the exact same thing because your API doesn’t have many features or compatible companion APIs?

Being open and true can be one of the hardest parts. Getting developers to believe that you are being open and true is equally as hard. Too often, people assume that marketers are there to put the shiny stuff in front so it hides product flaws. Developing trust with the dev community means being consistently honest and transparent.

Be Vulnerable

I was in a great conversation recently with a tech marketer who shared with me her technique for validating how she talks about dev products. Get ready — it’s way out there. She writes her talking points about the product and actually asks developers what they think.

I know — it seems so common sense when you hear it that. But it requires a degree of vulnerability that can be hard to adopt. I talked above about giving developers early access to your prototype APIs (which also requires that you be vulnerable); doing the same for your marketing content and promotion plans can deliver incredible benefits.

Marketing teams often employ the same devices as design teams, leveraging A/B tests and user labs to get empirical data about what works and what doesn’t. But, in my opinion, nothing substitutes for conversation. Our team does a lot of on-the-ground interaction with developers at hackathons, meet-ups, and conferences. Those are all great opportunities to not only get feedback about the products themselves but also get feedback on the marketing plans and language.

Most developers will share their thoughts with you unprompted. It’s important to dig deeper to find out more detail about their feedback and iterate with them until your marketing plans resonate with them. The more details you have, the better decisions you can make about how to implement their requests.

Being Part of the Community

Developer Marketing is community engagement, above all else. You have to go where the developers already are, speak their language, and contribute to their efforts. No amount of online content substitutes for actual interaction, IRL or online, and that means showing up not once, not once in a while, but consistently and regularly.

The DevExchange Marketing team has close internal ties to the Capital One developers — we support their internal events, we are co-located with them, and we make sure they have every opportunity to get their voices and expertise heard via all of our channels. This makes it easy for us to do the same with developers outside Capital One. The magic of this is that the dev community has just naturally become our community. That’s the healthiest dynamic possible for a developer marketing effort.

In general, many of these principles can be applied to a lot of marketing efforts. But with developer marketing, the only way to be effective is to zoom in, get close, and stay close.

DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2018 Capital One.