Congratulations, you’ve just got a job as the first Developer Relations person in a company. It’s your job to build a Developer Program. Where do you start? When you try googling that, you’ll discover Google isn’t always your friend.

Fear not though, I’m here to help. I’ve been in the same boat this year, and I’ve had to figure it all out. I’ve joined the team behind the Fidel API in the middle of a pandemic, and I’ve started building a Developer Relations program. I’ll share my process, and I’ll tell you how I chose my blueprint. So bare with me. It’s going to be one wild ride.

First of all, when I tried to Google my way out of this particular bind, I found very little on the topic. So I started looking at what other people were using for their DevRel programs. Two contending models emerged, and they are fairly popular in some DevRel circles. AAARRRP and the Orbit Model. So let’s take a quick look at them.

AAARRRP

AAARRRP, also referred to as Pirate Metrics, comes from Leggetter. And Marketing, but we’ll not dwell on that too much. It’s an acronym for Awareness, Acquisition, Activation, Revenue, Retention, Referral and Product. And while they may be meaningless words on their own, they actually stand for both metrics and goals for a developer relations programme. If you look closely at the definition Phil has for them, you’ll notice they are highly generic because they are meant to fit different products.

I’ll share what AAARRRP means for me, at Fidel, so we’re all on the same page. By looking at Phil’s generalisation and my specific adaptation of it, you should be able to adapt them for your product.

• Awareness stands for how many people have heard about our product. Or are aware of it. We consider blog post views, documentation, API reference, and social media views in this metric.
• Acquisition is used to track signups.
• Activation refers to people actually having used your product. Once. So we consider people that have created their first test transaction as activated.
• Revenue means people are not just testing it, but using it, so we’re making money. People in the revenue band have gotten past the sandbox mode and are using the API live.
• Retention comes from people that have used it for a while, and they aren’t switching to something else. This stage is where the model stops looking like a funnel.
• Referral means people are telling other people about our product. This is one of the parts of the model that can happen at any previous stage. We don’t necessarily start measuring this metric only after people have passed the retention stage. Most of our customers become referrals even before they have left the acquisition stage.
• Product refers to the feedback mechanism that makes our product better. We measure not only the amount of feedback we get but also the quality of the feedback we get. Again, another one that can happen at any stage.

This model is often referred to as a funnel, which is not accurate, it’s partially a funnel, with 2 pillars (Referral and Product) on the side. Because those metrics/goals can be influenced at any point in the funnel. The only metrics that fit in a funnel are Awareness, Acquisition, Activation, Revenue, and Retention.

Orbit

The Orbit Model, on the other hand, is a model for building communities. It was created by Josh Dzielak and Patrick Woods. It defines four main concepts and depending on where you get it from, the orbit levels are called differently.

• Love is a person’s level of engagement in the community.
• Reach represents the size of a member’s audience or sphere of influence.
• Gravity is an equation of love and reach. Anyone in your community has a gravity defined by love x reach.
• Orbit Levels are defined depending on the gravity number. They are segmented into 4 bands, closer or farther away from your product, depending on gravity. The closest ones are Advocates or Ambassadors, followed by Fans or Contributors and Users or Participants, with the ones furthest from you being Observers.

This model’s biggest selling point is that it’s not a funnel. But then again, AAARRRP isn’t exactly a funnel either. If you want to be pedantic though, you could correlate Orbit Levels to AAARRRP, where Observers account for Awareness, Users are Acquisition, Activation, and Revenue. Fans are Retention, and Ambassadors are Referral and Product. And the whole reason for segmenting your community like this is so you can interact with parts of it in different ways.

Orbit is a great model if you want to build your community, segment it, and create a strategy around that segmentation. But here’s my problem with Orbit. When my entire Ambassadors pool is 1, and my Observers are barely 1000, there is no statistical relevance I can use. Sure, it’s a great model when you have a huge user base or a vast community. But when you’re a startup with 1000 users, not so much.

What Did I Choose?

Drumroll, please! …I chose …Neither. Because AAARRRP is massive, hard to measure accurately across all in-person activities, and doesn’t really work for a one-person show. And Orbit doesn’t work for a small community. This was a bit anticlimactic, wasn’t it? And it probably didn’t solve your initial question either.

So what did I do, as someone who has a small team and a small community? I scaled down. Instead of using AAARRRP as my model, I trimmed it down to something I can achieve in this first year, with a small team. I went for a scaled-down version I call AARP. or Baby Pirate Metrics. It’s an acronym for Awareness, Activation, Referral and Product. I only chose the top 2 layers of the funnel, because the more significant the addressable audience, the higher the chances I can eventually impact the Revenue bit. And Referral and Product are what ultimately touch everything else in the model, so I need to take care of at least part of it in the first year.

Those 4 goals still have quite a few activities tied to them though, and it’s a tall order. Let’s look at some of those day-to-day activities and which of the 4 goals they help achieve.

• writing the Documentation and API Reference (acquisition, product)
• building SDKs (product)
• create demo applications (product)
• write blog posts (awareness, acquisition)
• sponsor online events (awareness, product)
• live-stream on Twitch / Youtube (awareness, acquisition, product)
• give talks at online events (awareness, acquisition)
• answer support queries (referral, product)
• have customer calls (acquisition, product)
• maintain the developer community forum (referral)
• create a feedback mechanism between the product and developers using the product (product)
• help with recruitment efforts (awareness)

It’s still a very long to-do list for a small team. It seemed way more manageable when there were only 4 letters, didn’t it? How are you going to do this all alone? Well, if you stick around until next week, I’ll tell you how I solved this particular conundrum in my next blog post. If you just can’t wait that long, feel free to DM me on Twitter.