Creating a developer advocacy program

Almost a mini-definitive guide

Let us first start with the VISION.

The VISION can one of the following —

  1. Become a developer platform. This means we enable developers to build cool things on top of our product. The things that get built may be product gaps or some crazy shit which opens up a new business opportunity (not directly for us).
  2. Engage developers to use our APIs, write apps and monetize them. These apps have to fill product gaps.
  3. Make our APIs a tool for power users and large clients to build custom workflows.

It has to be one of the three — not all. The paths, choices and things to commit are different for each one.

Irrespective of the vision we set ourselves for, certain things are non-negotiable when you are creating a developer advocacy program.

  1. Developer advocacy is fundamentally a support role. It supports our product, developers, ecosystem, marketing teams, etc. It is an important role that can enable great stories, but it is still fundamentally support.
  2. Developer advocacy also fundamentally requires support from cross-vertical business units. It is part marketing, part product and part engineering. These units need to be aligned with the vision.
  3. Developer advocates are on the road, showing APIs and getting feedback. There should be a commitment from the product, engineering and marketing to incorporate that feedback — which can range from API complexities to app store experiences.

Building a program around vision 1 —

A typical mission statement would be — “We want to be a developer platform. This means that developers are our bread and butter. APIs are our oxygen. We are committed to making sure our APIs are rock solid and tell a story. We are committed to making sure our developers can build amazing things. We are committed to enabling stories.”

Twilio is a great example. They are among the best developer platforms today. Stripe is another great example. They live and breathe developers.

  1. Hackathons make sense here. The goal of hackathons is to let people flirt with our APIs in the hope that they fall in love. The free form nature of hackathons will result in some nifty and fun (and at times productizable) applications or hacks.
  2. Metrics are very hard to define around initiatives. The goal is to be around developers whenever possible. The goal is to help them create cool stuff using our APIs. The outcomes won’t directly translate to revenue.
  3. Amazing feet on ground efforts needed. This involves marketing teams to work with evangelism teams on picking the events that matter. This also involves product and engineering to come up with solid docs and usecases.

Typical external facing team — Dev advocates (~3 or more), Events team (might be filled by dev advocacy teams themselves depending on which stage the company is in)

Internal teams — Dedicated API and platform teams, Product marketing person who focuses on dev experience stories and any app store related stuff.

Building a program around vision 2 —

A typical mission statement would be — “Our focus is our product. There are things we would love to build and we cannot get there. But, we believe our developers can build these features as apps and monetize them. We are committed to providing an API that lets developers address these product gaps.”

This is typically where most e-commerce companies today are.

  1. Hackathons might make sense, but only from the perspective of determining how much friction exists in building apps, and how the APIs play with other APIs in the industry. But, focus groups might be better. Oh, on the topic of how to plan a dev focus group, that is worth another discussion.
  2. For this effort to be successful, there should be some amazing transparency on what features we build versus what we support our ecosystem to build. Nothing is more upsetting to have a developer or partner build an app that we eventually make a default product feature.
  3. There should be an open channel where users of our product request features. Obviously, the channel should be open for the dev world to see and act on.
  4. Certifications and app liability concerns are real depending on the market you operate in. If apps are extensions of a product, then companies have to stand behind the best ones, feature them, etc. Billing has to be integrated so that developers can choose to receive a payout rather than managing transactions. Also, deeper product hooks are needed to provide a path for apps to look part of a product and not stick out like a sore thumb.
  5. Feet on ground efforts are not needed as much. But, tight engagement with developer community is still required to enable conversations around best practices for building such features. Conferences are more critical than hackathons — As an example, if you want to see your app store filled with fraud prevention apps, you need to talk to people who are passionate about that space and show them the opportunity.
  6. Marketing research team becomes critical in helping choose events where the target (niche) developer audience is found.
  7. Online competitions with bounties will generate momentum but will run into accountability issues unless the company is willing to absorb and support the apps that get built from competitions and challenges.
  8. Figuring out your support structure is critical. If the app breaks who supports it?

Typical external facing team — Dev advocates (1~3), Events (mostly a marketing research person works with product to identify the immediate product gaps and plan events to attend), Partner tech support engineer who can determine what to do when the app breaks.

Internal teams — Dedicated API and platform teams, App store manager (who manage the app store experience and also certify apps as needed)

Building a program around vision 3 —

A typical mission statement would be — “Our focus is our clients. Our product is powerful, but for usability reasons, it is minimal. However, we have APIs that can do a lot of heavy lifting. We are committed to allowing our users to harness the power of our product fully.”

Developer advocacy in the traditional sense does not apply here. The APIs are not truly open. However, there might be a powerful revenue stream tied to this approach. For instance, a product might scale enterprise with such a solution.

  1. API support teams are critical in this scenario. These are technical guys who write and understand code.
  2. Your API is essentially an upsell of your product. You need to treat it as such and have dedicated support around it.
  3. Engineers need to be part of support loop.
  4. A solutions engineering team that can architect business applications and enterprise level custom solutions working with sales channels.

Typical external facing team — API support team, Sales engineers

Internal teams — Dedicated API and platform teams, Escalations, Tech support, etc.

Successful developer advocacy efforts truly depends on all business units agreeing with what the vision for APIs is. Another problem that plagues the developer advocacy teams is metric tracking. What metrics make sense? In my experience, the answer to this depends on what vision drives us. If we are building true developer platforms, the metrics should be long term. It does not make sense measuring the immediate impact a hackathon or a conference created. We might see how many people downloaded our presentations or forked our Github repos, but it hardly translates to anything tangible. Because developer advocacy is central in companies with this grand vision, we need to start connecting the metrics together with the MBOs that marketing, product and engineering units have. For instance, if your marketing team is planning a conference, supporting a developer track will be an useful objective. If the constant feedback from dev community is used to iron out API bugs, that can be tied with the respective team goals.

If we are focussing on enabling developers and partners to build apps, an obvious metric will be to see what apps get built. However, it cannot happen without cross verticals helping with stuff like API endpoints, seamless integration experience, etc. Again, it makes more sense to tie dev advocacy metrics with actual product and marketing. Win as a team, fail as a team.