Introducing the AAARRRP devrel strategy framework

So, I am Phil Leggetter. I'm part of a develop relations team at a company called Nexmo. We're a cloud communications platform offering APIs for SMS, provisioning phone numbers, sending/receiving text messages, phone calls, making and receiving phone calls. But our goal is to ultimately connect everything everywhere, and to provide you the APIs to build that sort of functionality no matter the receiving and sending device. That's the pitch out of the way. I don't do marketing, right? But that's the pitch out of the way.

So, last year, I was fortunate enough to speak. I had a 10-minute slot at DevRelCon, and I spoke on the ROI of developer relations. And my analogy was that it's a bit like The Force. We can't feel it and see it. Sometimes we just need to believe. And that worked out really well for me because in January I was looking for a new role. I don't think it was related, but speakers beware. Careful what you say, okay?

But it was actually a really good opportunity for me. A lot of us have probably thought in this role, "I wonder if I said I was available, would anybody really be interested?" Because of the kind of crowd that we've got, you get retweeted and people get in touch. And it's great because it caused a lot of conversation. I had lots of opportunities to speak to people. And we're actually in kind of a peak of companies getting interested in developer relations, as I think we are, again, now. And we know we go through peaks and troughs.

And it was an opportunity as well from those conversations to go in and speak to companies. And it often felt, those that have probably interviewed at the same time, that you're, in many ways, providing consultancy during those interviews. You're in for an hour, and for that hour you're basically telling them how to build a developer relations team and the strategy that they should undertake. And you're kind of going, "I should be charging for this, but really I'm looking for a job." But all of that was from obviously all the conversations that I've had over the years with my peers with working at events and learning, hopefully, on the job.

Defining developer relations strategy

So, what I did is what we kind of do anyway, because I wrote it down. I wrote down this idea of how you can go about defining a strategy for your developer relations program. And it's kind of like a micro framework. And it's ultimately a summary of the conversations I've had with you and similar people. And because I don't do marketing, I also put a gimmick in there, which was the DevRelOmeter which I'll show later.

So, we'll cover what is the AAARRRP, developer relations framework, the basic steps to use that framework, and then how we've applied it at Nexmo. So, I want to tell a real story. I want to talk about how we really have used this.

So, a bit of background. Who's heard of Dave McClure's AARRR pirate metrics? Okay, I see quite a few people. So, for those that haven't, you'll notice that it does talk about product marketing and product management, and obviously not specifically developer relations. But I was introduced to this in 2001. And at the company where I was at the time, we did kind of use it to identify what it is we should be working on and measure some metrics around it.

And those metrics are acquisition. So, what these specifically mean will vary depending on what you're doing and the company you're working for. But in terms of Software as a Service, which is where I've worked for the past six years, acquisition is signup. Can you get that user signed up? It might be a download. When Dave McClure spoke about this, he just was talking about website visits.

Can you get them activated? So, again, with Software as a Service, making that first API call or making a number of API calls that you deem as being activated.

Retention. Can you keep them on the product? Are they making a few calls and they're never coming back?

Referral. Do you get enough people using your product and it's so good that they start to invite other people to it? Do you have a referral mechanism?

And revenue. Who cares about revenue. Right? But obviously, our employees do, and you need to get paid. So, it is an obvious metric.

A framework for understanding developer relations

So how does AAARRRP fit into that? I thought that was a good base point, but I felt it was missing a couple of things. The first thing is awareness. There's an A, not "wareness."

That says awareness. So, part of what we do is to raise awareness of the company. Right? You'll see we've got a banner upstairs. We've got t-shirts. We're trying to raise awareness of the company. We're not certainly trying to get you to sign up at the booth. We're just saying, "Hey, we're Nexmo. We're a cloud communications platform. If you need communications functionality, come and use us." So, you now know we exist.

On product. So, we provide input into product. I mean, I've got a background in software engineering. I've participated in product activities. I do development. I'm involved in building the libraries, writing documentation, providing feedback into the product. We work with the product teams, the engineering teams. So, there's a product aspect of what we do. So, this coming together provides us with AAARRRP. I'm going to get you all to say it at some point.

So how do we go about using this? Define your goals. So, each of those points are a goal. So, do I want to acquire new users? Do I want to activate users? Do I want to get users to refer? Do I want product feedback? So, define your goals

And then identify the activities that you go about undertaking to achieve those goals. Pretty simple. I'm not that clever, so I like that this is simple. It means I can follow it.

And then plan to execute. Now the framework itself doesn't talk about how you plan your execution. You need to take the output of this and ultimately take in a number of other factors.

Choosing your strategy

So, these are your options. At Nexmo, we chose awareness. So, before this year, can I ask who'd heard of Nexmo before? A few people. Okay, that's pretty good. Before this event, who'd heard of Nexmo? The same amount. The same amount of people. We've had no impact this year. Can we cut that bit out of the video? That's gone totally the wrong way. Everyone put your hand up. So, you've now all heard of Nexmo. So, we've now got 100% visibility in this room.

But the feeling was people weren't particularly aware of Nexmo, and we found that at events, at the start we go, "Who's heard of Nexmo before?" And like one or two people in the audience put their hands up. And we now know that next year we go to the same kind of group and we go, "Who's heard of Nexmo?" and 60%, say, will put their hands up. So, we're raising awareness

Nexmo's been very sales focused and done very well. We've got customers like GitHub, Amazon, Expedia, WhatsApp, Snapchat, and big companies. So, when I looked at the job at the start of the year, I was like, "Wow, why have I never heard of Nexmo before when they've got all these great customers?" Because they've been very sales focused, and they haven't thought about developer relations. They've had occasional teams, on and off, move between marketing and engineering and marketing and engineering, but this was the first attempt at growing a big team. We're 9 at the minute and we're hiring.

So, it's a conscious effort to really put some money and effort towards this idea of developer relations. And with that, you get people like us that use software and go, "This is terrible." "Oh, I've got to use this." "Why does it do this? It should do this." "This documentation really doesn't flow." "The user journey here is not great." "Oh, the dashboard should do this." And there hasn't been that kind of product feedback.

In many ways, when you take the sales first approach, there's the post production stuff that really matters, the latency, the quality of delivery, the number of 9s on the decimal point, and Nexmo does very well with that sort of thing. But we haven't had to consider the initial developer experience, in many cases, for the long term, but now we do. So, part of our role is to work on product and provide that feedback and be the voice of the developer.

So, we've decided we're going with awareness, activation, and product. And step two is define the activities that meet your goals. Now I remember a few years ago, I went into a talk on how to manage your manager. And I thought, "This sounds really interesting." And we were presented with a spreadsheet. And I promised that I would never do that again, but unfortunately, I'm about to present a spreadsheet even though it's a matrix grid magic machine.

So, we need to identify what the activities are that achieve goals. Can you find these activities that meet more than one goal? That's a good way of utilizing your time well. And can you find complimentary activities, something that feeds into the next?

So, here's the AAARRRP grid matrix magic machine. It's a spreadsheet. Unfortunately, some of the stuff's cut off, but you get an idea. We've got documentation. We've got a bunch of blogging activities, tutorials, hacks, thought leadership. We've got event related activities, conference. These things say presales somewhere down there, so we'll just ignore those. Support and then feedback. So, beta programs, office hours. And there's actually capture feedback down here. It's down there.

So, taking into account what we're doing at Nexmo, we've got awareness, activation, product. So, this, again, just visually we can see the sorts of things that are going to help us achieve those goals. Really simple.

And if we look at some specific things, docs, great for awareness. If you look at the Stripe docs, isn't that a perfect example of product, which is ultimately marketing? Who's looked at the Stripe docs and been referred to them and saying, "Aren't they brilliant?"

Activation. Obviously without the documentation, you might have the best API in the world, but people can't use your docs unless you got really good swagger definition, but then you would generate your documentation from it.

And product. I mean documenting, for me, is obviously product.

Events. Hackathons specifically for us. When we're trying to improve that developer experience, we're going to get a lot of good feedback at hackathons when we sit down with people trying to use our product. Great for awareness. Great for activation. People have to sign up to use your product. And obviously great for that feedback mechanism.

Planning the execution

So then bringing in these extra concepts. So, this bit here I've actually stuck in a spreadsheet and it's available by this as a template. I get it's pretty simple, but you can edit and provide feedback because you might not agree with how I've... In fact, how the team, one of the things we did, we sat down as a team, came together and defined what these were.

So, the next bit here is we've added some weighting. So, ultimately, we know we need to put some additional effort into certain things such as documentation, so we've added a weighting column. But we've also added an awareness column. We haven't put anything specifically for activation because our focus with product is developer experience, which itself fits naturally into activating users on our platform.

So, can you find activates that meet more than one goal? Again, we've got here a column which is how many of these are we matching. We've got some good ones here. I think if I click again, yeah. Again, we'll see tutorials, goal alignment 3, hackathons, goal alignment 3. Really, really simple. And then we've got this scoring at the end that you can't see. So, anyway, there's a scoring here that basically multiplies these things together. So, that's 15 and this is 15, at least the greens are.

So, we decided to just do everything, because we went through all that process and none of us could really agree. That isn't necessarily true. We did kind of filter it down on some of these specific activities, around documentation, around libraries. So, our API has got some legacy to it, so there's some inconsistencies. The library helps hide some of that. We're looking at fixing our APIs, but for the moment, libraries really work. Some of the newer functionality has quite a tricky authentication mechanism. So, too, the libraries really help for that. Some people believe that libraries are product. I personally do. Other people don't. So, we feel that that's really important. So, we are working on libraries, which is this one here.

We don't do support tickets because we have a dedicated support team, which is why we're good at support.

Complimentary activities

So, can you find complimentary activities? And I think, just as an efficiency measure, this is great. But also, it's a natural flow in how you work. So, if we can improve the product and then we can create content demonstrating about how we can improve the product, or we can define how we attempt to our developer relations, strategy and then do a talk on it, it naturally feeds into the next thing. So, we're creating content. And in creating the content, we increase awareness.

So, for instance, when we started, we knew we were working on libraries. So, we updated the Python library. We released a new version of the library. We put a blog post out about it and we tweeted, sort of macro micro shares. We then built a demo using, say, the new 2FA functionality that we'd added to the Python library. And then we built that demo on it and we shared that.

We wrote a blog post about how we built the demo, and then we shared that, and then we ended up at PyCon. So, we're trying to create complimentary activity that feeds into the next thing, and in many ways actually, in this sense, keeps you consistently visible in that specific Python community. And then we did the same thing with Ruby, PHP, Python and .NET to a certain extent. So, this is actually taken from internal presentations that I've given out at work.

So, execute. Now execute is obviously very important. I'm not going to talk. The top three points are really important, obviously. Brandon did a really good talk last year on burnout, which is obviously tied to team well-being. Jessica mentioned the need to be tied to your company values and team values. And we've got to get stuff to the company, get stuff done, committed to each other, integrity, customer success as a team. We've got have empathy, be open and community focused. The headcount obviously affects the work you can do, the resources you have, the money you have and so on. But I want to kind of dive into evangelism or advocacy, and I'd love to have more conversations afterwards about this. And then team member responsibilities.

The DevRelOMeter

So, this is the DevRelOMeter. And the idea here is that you look at the activities that you're doing and it defines the type of work you're doing. Whether you're an evangelist or an advocate. Personally, I was an evangelist for a number of years and I did a lot of product stuff. It's just a job title. But I wonder from it externally and I've seen tweets. "This conference is full of evangelists. I don't want to go." There might be something in that. It might be something in it's full of advocates. I think they're the same thing. I don't want to go.

But I think maybe even in a sense of defining what your role is, it could be quite important to say, "Well, advocacy is a two-way conversation between the customers and the product and engineering teams." Maybe evangelist is more you're given the product as the first customer, and then you take that to market, the developer market.

So, I think that it's an interesting ongoing conversation that I don't think is kind of going to go anywhere. I don't think it's going to be resolved, but it's something that I wanted to highlight. We've chosen to be a team of developer advocates because it does reflect our involvement with product and engineering, with stakeholders throughout many of the decisions that are made with their next one.

Specialisation in teams

And the second thing, and something I feel very strongly about, which is related to my first tweet and why I ended up there, is that many organizations group their teams and the activities that they do by function. So, building product, writing documentation, doing API tools, SDKs and libraries. Community, which might be in a startup or general community activities. We class community as the languages as well, Python, because it's more focused. But you might separate communities and then outreach into events and so on. And I have put marketing up there. I'm kind of accepting that we do 50% marketing, 50% product.

And many companies will split their teams like that. They'll probably have their product teams. They'll have their documentation teams. And from a developer relations point of view, you probably sit in the outreach marketing, which is why so many teams sit under marketing. Google, I believe they sit under product and engineering because they work directly with their engineers.

But I feel quite strongly that as creative individuals, and I feel quite creative. I'm a software engineer. I like to build stuff. I feel I've got a reasonable mind. At some point I might like to start my own company, and I think a lot of us do feel that way. It's very difficult to pigeon people like us into doing just one function. And I much prefer this approach where we allow individuals to work from end to end, through from involvement in product, involvement in documentation, the API tools libraries, community involvement and outreach.

And I think based on what Jessica was saying as well. Firstly, we've got true ownership in delivery. Secondly, there's authenticity. Because if I start involvement in the product, I write the documentation, I write the tools, I write decent demos, I write the blog post on the tutorial, and I stand on stage and talk about the experience that I've had in doing that, it's much more authentic than me being given the API and saying, "Build something on that. Look at the trend, and then give a talk that's interesting, that raises awareness." For me, that's not really that authentic. I think this is a much more authentic approach. Dave, need the five minutes.

Define your goals

So, in summary, define your goals. It is really simple. That mapping of the goals that your company has to the activities that you should undertake to achieve those. And when you look at the activities, what activities will achieve those goals and how can you undertake them? Can you find that complimentary nature of one activity meeting more than one goal and feeding into the next?

And then plan and execution is really just taking the output of that and taking the resources, your thoughts about team well-being. The nice idea with this as well is that you're not always on the road. If you were always evangelizing, then events are a good source of awareness. But if your involvement in product, it means you're working from home or you're in the office and you're getting that variety of a little bit of travel and a little bit of work at home. But that's really up to you and your organization to put that in place.