Understanding your place, finding your story and setting your goals are all fundamental stages in creating a developer outreach strategy. In his informative talk from DevRelCon Tokyo 2017, Hoopy founder Matthew Revell at looks the questions you need to consider.
Thank you very much. Okay, so Konnichiwa. Thank you very much for joining me in this session. I want to talk about “Strategy for Developer Relations,” as you can see on the slide here. So, why strategy? Well, first of, who am I? I’m Matthew Revell, as Kyoku said. I run a company called Hoopy, where we work with different companies advising them on developer relations. Those are the companies I’ve worked with, and those are some of the events I’ve been involved with over the past few years.
So I wanna cover what I see as the three stages of building a developer relations strategy, and in some ways, you can actually apply these three stages to any strategy. So the first thing is you want to understand where you are. You need to know what the situation is right now. Then you need to decide what it is in the world that you want to change, so you know where you are, where you want to be. And then, simply create a plan of action to make that happen.
Now, because developer relations is somewhat of a niche thing in Japan right now, I wanted to, very quickly, cover some of what I think developer relations is about. And I know that we’ve had some of that covered today already, but this feeds into the activities you need to do to create a strategy. So, I see it as a specialised form of marketing that’s aimed at software developers. Now, that doesn’t cover everything perhaps, but it’s a way to think about developer relations that helps inform the type of planning and strategy that you need to come up with.
When you think of it in other terms, then it’s very easy to get lost and detached from some of the things that are important to measure. But unlike a lot of marketing, which is very in-the-moment and perhaps short-term, developer relations is very long term, is about building relationships with developers, as the name suggests. But why? What’s so special about developers? Why do they need this special treatment? I mean, a lot of developers do, kind of, feel they are special, and in honesty, it is an unusual form of work.
You know, developers aren’t just another audience. You can sell toothpaste to people who are not experts in dental hygiene. They will not understand necessarily, the specifics of your formula. They might recognise terms like fluoride or whitening, but if you’re selling toothpaste, you’re not selling to experts. Developers, though, are expert in the thing that you’re selling. They build a career on having an understanding of some very in-depth, technical subjects. And the first thing to say is developers will correct you in public.
They will not be embarrassed about telling you that you’re wrong, and so that means that you have to be right. This T-shirt was inspired by an event that happened…a conference a few years ago in New York, where the speaker was talking about some very involved aspect of maintaining consistency across different modes of a distributed database.
And someone in the audience piped up and said, “Hey, do you even know how vector clocks work?” And that guy was Kyle Kingsbury who, since then, actually made it something of a career out of taking the promises made by distributer databases like MongoDB, Cassandra, and so on, and then blogging… He wrote an entire test suite that would test the promises of these databases, and then he would blog about it, and very publicly shame database providers by showing, “Well, actually you promised to do this, and here’s how much of the data you lost.” And things like that.
Interestingly, he wasn’t so bothered if you didn’t claim to be really great at distributing data or storing it, but if you claimed that you wouldn’t lose any data, he would go out of his way to prove that you did. And so, yeah. So you will have people in your audience who want to prove that you’re wrong. The other thing is developer-targeted tools aren’t just another product. You know, if I use a form of toothpaste that is maybe not living up to its promise, I can easily switch. I probably won’t lose too much, unless I carry on forever, and I just, you know, lost my teeth.
But with developer-targeted tools, with APIs, with infrastructure, the people you’re working with, they’re betting their careers and they’re credibility on the choice of tool that they make. You know, if you say to someone that your tool will do X,Y, and Z, and they believe you, and they test it and it seems to, but then at production it goes ahead and it fails massively and they lose their job, then the stakes are higher.
So, people really need to be able to trust that what you’re saying is true. The other thing is maybe the audience knows more about the product than you do. You know, if you’re selling something very specialized, then they can probably, very easily tell when you’re fudging things. You know, traditional marketing is a great deal about storytelling. It’s about selling a dream. You know, even in B2B marketing is even if you’re selling some, kind of, boring insurance product to a business, there’s still some aspect of not focusing on the detail, but selling something that makes people feel better, that makes me feel confident, makes me feel reassured.
Whereas, when you’re selling something very technical, you can’t fudge that detail. So, like I say, your claims can and will be tested by your audience. And so that’s why we build relationships with people because long-term relationships build trust. They build credibility. And so if you’re able to, even in some cases, build a one-on-one relationship with developers, then you’re going to have them trust what you say, and believe you because you’ve proven yourself to be credible.
Something on the back of your badges today is from Tim Falls who kicked off the developer relations program at SendGrid. He says, “A handshake is worth more than a click.” And the idea here is, and this is, kind of, where we differ from normal marketing. It’s very much that it’s better to meet someone, to get their trust, to see eye-to-eye with them, than it is to get them signed up into your CRM.
You know, if they’re… The people that you’re dealing with are not just numbers. They’re not just statistics. They’re people that you need to build that relationship with. So the aims that we’re trying to satisfy with that developer relations strategy are that you want to build trust with that cynical audience, demonstrate your credibility, nurture long-term relationships, and you can explain complicated technology to people who know more than you do, in a lot of cases. And you’re gonna encourage also, peer support and recommendation, build community, because that is a way of amplifying what you were able to do.
Okay. So let’s get on to how we’re actually gonna look at that and do that. There’s a friend of mine, Phil Leggetter. He is head of developer relations at one of our sponsors today, Nexmo, that’s somewhere on the slide there. And he came up with this really useful tool for understanding the process that developers take during their relationship with you. He calls it The AAARRRP Methodology, I call it The Dev Rel Funnel, and it starts off with awareness.
So, very much like normal marketing. At first, a developer doesn’t know about your product, so you want to make them aware. You’ll build awareness amongst a whole bunch of developers, and then a smaller set of those developers you will acquire. So they will sign up for an API key. They will download your SDK. They will sign up for your cloud service, whatever it is. You’ll acquire them. You’ll get them into your sphere, into your world.
And then, a yet smaller group of those people will become activated, so they will make their first API call. They will build a demo around your tool. Whatever it is, they will actually make use of it. And then a yet smaller group will be falling to the retention part of the funnel. So they will be building something for production, or at the very least, they’ll be writing something in development that works against your API, that works with your tool.
And then the part that a lot of startups forget, the revenue part. You then wanna get people actually paying you money, and there will be an even small group of people who will become revenue generating, and importantly, profitable. And then referral. These are people who are now ambassadors to your product. They want to get out there and teach the world about why it’s so great. And so they become part of your community, and they become part of your developer relations broader than what you can achieve yourself.
And finally, product. These are the people who are so into your product that they will contribute pool requests against your code. They will feedback on the roadmap. They will become involved in what you’re doing, and if you treat this, then make sure you credit fill. Although, I did put the colour scheme in, which I’m very proud of. So we want to move people through that funnel. We want to get them, at the very least, down to revenue.
And if we can, we want to get them all the way down to product. And so, there are four broad areas of activity that I see happening, although I may change this now. I have to, seeing John’s talk, and he mentioned scoop. But the four pillars, to me, that help us move developers through the funnel are broadly, outreach, community, developer experience, and development and support.
So with outreach, we’re talking about meet-ups, about creating something online, you know, blogs or other resources that bring people into your sphere. With community, we’re talking about creating a process that enables people to feel recognised, to feel like they’re contributing to something worthwhile, and that brings them from that aware developer to someone who is contributing back to your product.
So, whether that’s through something that’s involved as an MVP program or just something where you are actively encouraging and supporting people who are on your side. Developer experience, of course, is the API and SDK design, the documentation, the on-boarding process, all of that. And then development and support is a lot of what John is talking about, you know, where you provide excellent support to people. You provide them with a level of interaction that gets them over those humps that all these other parts of the process haven’t been able to do.
Okay. So how do we make sense of these four things and of that funnel? Like I said, the first step is understanding where you are. So I don’t normally quote ancient philosophers, but this is really useful. Basically, the idea here is that if you plan well, then you’ve already won the battle. A lot of developer relations is done off the cuff, is done without planning. It’s done without thinking about strategy. And that’s, kind of, okay, but really, we need to understand where we are before we can plan on where to go.
It’s not okay just to say, “Hey, Twilio did this, so we’ll do what Twilio did,” which, honestly, I’ve heard in a lot of companies. What they did was right for them at the time they did it. It’s not right for you right now where you are. Okay, so we’re gonna do… If you’re familiar with marketing, you’ll be familiar with situational analysis. I think it works slightly differently for Devrel than for traditional marketing. So what we’re gonna do is we’re gonna look at your product, your competition, the company that you work for or that is behind the product.
It might be an organization like Mozilla that isn’t necessarily entirely commercially focused, but I’m gonna call it a company. And then the climate within which you are operating. So we need to ask the right questions to understand how each of these contributes to our situation right now. The first one is about the product. How does this product change the world?
Now, I’m not saying this in a typical Silicon Valley nonsense way of thinking about, “Hey, we’re making something actually really inconsequential, but we’re gonna pretend it changes the world.” What I mean is if you’re not building something that makes the world different somehow, even if it’s a very small part of the world, then it’s probably not worth doing. You know, if you’re not changing the world in some way, I’m not saying making the world a better place or anything like that. It’s just there’s gotta be something that you’re doing that changes some small part of the world.
If you’re not doing that, then you need to think again. So looking at Stripe, it was really just, you know, let’s make payments easy and trustworthy for developers. Then let’s think about what is good about the tech. So if you’re looking at MongoDB, now, there are things you might not like about MongoDB, but one of the good things is they let you deal in native JSON without the impedance mismatch that a relation database might have with JSON. And what do we need to be honest about with our product?
I don’t know if you came across this in Japan, but there was a product that was, kind of, seen as an example of Silicon Valley excess, the Juicero, which was a really expensive juicer, which actually just squeezed out a bag of pre-juiced stuff. So, you know, you have the power to squeeze yourself, you don’t need to buy this $500 device. But, you know, you need to be honest upfront about what’s wrong with your product because, I bet you, everyone else in the world will be if you don’t address it immediately.
You know, those developers will come and find that thing that you haven’t quite been upfront about. And then what are the core use cases of your product? What are people gonna be using it for? So once you understand those things, you’re in a position then to know the good, the bad, and the ugly about your product, and to start thinking about what its role in the world is.
And then the competition. Similarly, we need to do the same thing for the competition. We need to think about each of the competitors in our marketplace, and say, “What are they good at? What are they bad at, and how will people use it? What are the core use cases for those products?” And you’re your company. Your company, obviously, has a very big influence. Your product doesn’t exist in a vacuum. So what is your company’s role in the market? How your company interacts with the other competitors is going to influence how people see you.
And I think there are broadly four roles that a tech company takes in a particular market. So there’s the obvious market leader. So if you’re selling cloud services, then AWS is the market leader, right, if you’re selling compute time, things like that. Then there’s the challenger. So maybe at the moment, that’s Microsoft Azure. This is the company that’s up and coming, could take the number two place, maybe even take the number one place, but they’re a company who is probably doing things that challenges the market leader, does more interesting things in some ways, but they’re not quite at the top yet.
Then there’s the niche player. So they’re a company who are plowing their own furrow, they’re doing their own thing, they’re quite happily bobbing along. So in the cloud services, you might think of someone like Joint, who are doing something slightly different to the main leaders. They’re probably not ever gonna threaten AWS, but they’re carving out small business for themselves in a particular area.
And then there’s the fun one, the shooting star. This is the company that’s got far too much venture money. It’s spending it like crazy. They’re not gonna survive probably till the end of the year unless they get another funding round, but the problem is they’re stealing all the oxygen because they’re spending loads of money, and so you’ve got to fight against them. So you need to work out, are you one of these? And if you are, then how does that affect however you will interact with people? And if you’re not one of these, then what is your role in the market?
You know, if you’re not… I’m sad to say that probably in many developer tool markets then, if you’re not going to be one of the top two, or maybe a niche player, then you’re probably perhaps, not gonna do too well because there aren’t always room for more than three options within a particular sphere. Then within your company, how does the people and the culture influence how people see you? So this image of Bill Gates and Steve Jobs, very clearly, those are two people who had a massive influence on the companies that they led, and in very different ways.
So are there people in your company who are going to influence how developers see you and see your product? And then more broadly, your culture at your company. Is that something that will have an influence, again, on how you’ll approach developers? And then the legacy. There will be good things and there will be bad things, unless you’re very, you know, brand new. There will be things in your history that you either have to live with, like Windows ME, or that you can be proud of that will contribute to how people see you.
You know, you might need to see off some of these. You might need to write a blog post about how, “Yes, well, you know, our bad thing that happened. It happened. We own it. We acknowledge it wasn’t good.” Be upfront about your legacy, acknowledge… You know, I used to work for a company called Couchbase who came out of the CouchDB community. And the CouchDB community weren’t too happy that there was a company called Couchbase that had a different product, but a similar name.
And so that was something that, in our developer relations, we had to deal with. And so there will be things in your legacy, in your history, that influence how you approach developers. Okay, so the broader climate now. So, partly, this is what is happening in the world. You know, what’s happening economically, politically, that might influence your strategy. But on a less of a macro level, you’re asking here, who are our target developers?
You know, earlier, Carina spoke about user stories for developers, and how to select who you’re talking to, based on those. I have a slightly different process, which I, again, fully acknowledge I have borrowed from Caroline Luko from Whit Factory, and these are about different drivers that send people towards and away from your product. So these are… We can break these down into different levels. So there’s technical things about the product. There are things about the type of developer. There are things about the company that they will work for, and then there are things in the broader climate.
So we have to understand these drivers by asking a bunch of questions. We ask siege questions, and a useful way of doing that is to really just write out the questions that we think might make sense for our product. Now, these aren’t the questions to ask. These are just example questions. Let’s say we were selling a database, then we might say, “Does our product make sense only at a particular scale?” So if it only makes sense for people with more than a terabyte of data, then we can say that one of the drivers away from that product is people with small data sets.
The one that drives it to our product is people who have huge data sets. You know, does it only run on Windows? Well, again, that will greatly influence how we approach the market. Is it a continuous integration tool rather than something that you actually use in the end product itself? Again, that will greatly influence your strategy. Questions about the developer themselves, the individual who you’re talking to. You know, how much commitment does our product require of developers?
So if you have no documentation yet, and you require that people read your source code, and stay up to 3 a.m. every morning learning it, then, obviously, that’s gonna greatly change who you approach and where you find them, compared to if you provide a really easy, one-hour training course that gets you everything you need. Similarly, you know, what languages are they using? What languages are they interested in? That kind of thing. What role do they play in their career?
Things about the organisation. You know, if your product costs $90,000 per developer per year, maybe you don’t want to approach really small, three-person startups that are running on seed funding. What sorts of organisations have a need for this? If your product is really great for banks then, you know, focus on banks. And so, basically, what you’re asking here is what sorts of company should we be approaching? You know, where will that developer sit? Where will they be earning their living or building their software?
And then more broadly in the market, obviously, you want to take into account the competition, but there are other things like what’s happening in the industry, more broadly, that might affect us? So is there a rebuilding, you know, a library for Go, but actually Go is not cool anymore, and nobody is using it, or something like that. Or more practical things, like, do we have offices in Tokyo, Beijing, and Singapore?
Well, if that’s the case, then perhaps we want to focus our developer relations efforts in those cities first, rather than going off to Paris and hoping that we can build something in a city where we don’t really have any infrastructure for our company. So we can use those drivers. You know, we ask those questions, come up with the drivers, then we can use those to create segments in the market or amongst developers. So, for example, we might say that one segment that we’ve identified is front-end developers who work in Japan at financial institutions.
And so we can now say, “These are the people that we’re not gonna target, but these are the ones that we are.” So how do you choose which groups to target? Well first, is it relevant to our business? You know, are they actually gonna have a use for it? Do they take those drivers that we had earlier? Is it large enough? You want to focus on the targets who actually have a good enough size that you stand to make some money out of them. Oh yes, and can we make enough money?
So you might find that if, you know, you have that $90,000 a year product, but you’ve also identified that high school students are really good…are a particularly relevant segment, well maybe don’t prioritise them because they can’t afford your product. And do you have the means to reach them? That, again, is if, you know, if you’re based in Tokyo, and one of the groups that you’ve identified are in, I don’t know, Minnesota in the United States, then maybe at this stage you don’t have the means to reach them because you don’t have that reach over there.
Okay. So that’s kind of that section. So what do we want to change? You might have heard of this company. You might have seen that they’ve had something of a change over the past few years. Depending on how old you are, if you’re as old as me, then you will know they used to have a pretty bad reputation. These are some examples. I won’t go into all of them because I don’t want to, you know, drag up bad blood. But this one is obviously the worst. But there was a time when Microsoft was the dominant operating system provider, and they used that to their advantage in some questionable ways.
And then things started to change. Well, let’s say Amazon, to start with, began providing a way to turn computing into a utility resource. So you weren’t needing to buy 1,000 Window server licenses, you could just fire up the machines you needed as and when you needed them. And then Android became the world’s most used operating system, not Windows. And then, obviously, alongside that, operating systems like Ubuntu became dominant on the server.
And so Microsoft didn’t have a place in that world. The world had changed, so they needed a new story. And I don’t know if you’ve noticed this, but their story, at least over the past five years, has been, “Hey, we’ve always been developers at heart, but now the developers are back in charge.” And so their developer story has been to say, “Look, we’re not really gonna acknowledge that stuff, but look at all this stuff that we’re doing now. We’re cool again, you know.”
So we have the CEO of Microsoft presenting the Microsoft loves Linux, and they’re integrating an Ubuntu subsystem into Windows. We have Office on the iPad, on the iPhone, on Android. We have Visual Studio Code, which, okay, is based on the work of the electron team at GitHub, but it is a cross-platform, code-developing environment for Windows, Mac, and Linux. Who would have thought we would have seen that, you know, 15 years ago? But they’ve changed their story, and it looks like I’m running over.
So you need a compelling story, which becomes a guiding principle for your strategy. And then once you have that compelling story, that guiding principle, you can start to set goals. So you say the understanding of where you are, you set the goals, and this is something that developer relations people find quite hard, but remember, that your goals don’t exist within a vacuum. Your company has goals. Your marketing team has goals. And so, really, your dev-relations goals just are a, kind of, they’re funnelled in from the greater context of your company.
And then you create strategic programs to enact those goals. So basically, a strategic program is one approach to achieving a goal, it tells you what you’ll do, the tactics, and then how you’ll measure it. Something important though, is the timeframe, so goals really should be from one year to three years out, no further, no shorter, really. And you need to follow the rhythm of your company. I’m gonna skip over this a little bit because we’re out of time.
But as John mentioned earlier, again, they’re in-person, content, community, and developer experience things that you can do that can become part of your strategic plan, part of your goals, or the plans to achieve your goals. So, sorry for skipping over this bit, but I have overrun. So in summary, you want to understand where you are, you need to decide a big picture approach, what thing are you gonna do? What story are you going to tell the world? And then you want a set of goals and programs to achieve that, to make that change from where you are to where you want to be.
It’s not rocket science. It’s just stuff you gotta think about. If you want to talk to me, I’ll be around. That’s how to contact me. I’m very happy to chat with anyone who wants to, and thank you very much for your attention.
Tamao Nakahara and Baruch Sadogursky demonstrate some mistakes to avoid when engaging with developers in this session from DevRelCon San Francisco 2019.
Amanda Moran from DataStax talks through the good and bad of transitioning from engineering to dev rel in this session from DevRelCon San Francisco 2019.
Write for us