Stop Chasing Developer Love: Build a Developer Go-To-Market CEOs Actually Value

So look, all of us are here because at some point, you know, some executive in your organization, the CEO, the VP of marketing, VP of product, somebody went full Steve Ballmer and decided that like developers were going to be critical to the business strategy, that they were going to make this big investment and out of that big investment, they were going to get this big return on that investment. We want to give back, right? We want to drive community, through the developer audience. We want everybody in open source to love us. We want to drive community. And that’s great. But at the end of the day, you need to be sober about the fact that this has to tie back to revenue somehow, because otherwise, it would be very hard for you to argue that you’re a good investment for the business.

I found this to be a problem with almost everybody I’ve spoken to who works in developer relations and developer experience. A lot of people in developer relations and developer experience, they’ve been tasked with going out and getting developer love, but it was never clearly articulated to them that they’re going to be measured on return on investment. Developer relations, that’s really fuzzy. It’s a dark art. There are no books written on this. And everybody in the organization who is not in developer relations is looking at your organization thinking, that’s not a good investment of our resources. So from a CEO’s perspective, there is no such thing as developer relations or developer experience. What they have is a developer go-to-market.

How CEOs Actually Think About Your Program

A CEO’s perspective is actually really simple, and now it’s not just CEOs who think this way, but they’re really the one person in the organization who has probably the most holistic view of the business. Everything that they’re doing, everything that they’re pushing, everything that they, you know, evaluate or prioritize is measured along three axes. The first one is driving revenue growth. The second is cost reduction. And the third one is, is what we’re doing enabling us to be more predictable or help us reduce risk? Everything a CEO does falls along these three axes, and a good CEO’s job is to look at everything that’s happening and say, where am I getting the most ROI, and where can I keep putting more money into to get more scale?

So as a CEO is doing his job, he’s going to take everything that’s happening in the organization, and he’s going to have to ruthlessly prioritize it every single minute of every day. Every executive in the organization is telling him that their project is more important than somebody else. We’ve got this large marketing organization that we’ve got to go fund, right? We’ve got an enterprise sales team that’s got to go do their job, right? We’ve got an engineering team that we need to double because we’re falling behind on roadmap. A lot of us live off of venture capital, and they’re giving you a ton of money, but at the end of the day, you have to be really, really careful about how you’re spending that money.

So from a metrics perspective, please track your metrics. If you’re doing developer relations, somebody has probably said this is really critical for the business. And so at the end of the day, the CEO’s job is not to play favorites. He has scarce resources. He’s got really challenging metrics that his board is pushing on him. And developer relations and developer experience also need to fall along these axes. Understanding what those are and how your developer go-to-market ties into them is critical, because if you don’t have a good answer to that, then it’s going to be very hard for you to continue getting resources to continue making the investments you need to make to be successful.

DevRel Is Just Marketing, DevEx Is Just Product

So at the end of the day, developer relations is a go-to-market strategy. Developer relations and developer experience are simply components of an overall go-to-market strategy. From a developer’s perspective, developer relations is just marketing. It’s just really highly specialized field marketing for a really hard-to-market audience who hates to be marketed to. Developer experience is a product function, and it should be measured as a business unit. At the end of the day, it doesn’t matter how fast your API is or all the amazing features that your product has, if the developer can’t use it, if he can’t easily figure out how to do what he needs to do in your API, that feature set doesn’t exist.

So from a CEO’s perspective, what they have is a developer go-to-market. For many companies, the developer go-to-market is not the only go-to-market they have. They might have a field sales team. They might have a really built-out e-commerce self-service model. They might have resellers. They might have any other form of partnerships. And the biggest problem we see both in our own organization, and the biggest problem I’ve seen with all of our peer companies, is we need to be really clear on where developer relations sits and how it fits into that developer go-to-market.

Developer relations and developer experience cannot be this dark art that only those chosen few know about. Everybody has to understand where it fits and how they fit into it as well. DevRel is owned by DevRel. DevX is owned by DevX. There’s no Chinese firewall. We’re one organization trying to work in a coordinated dance. Making sure that we’re not just simply two different parts of the organization that don’t talk to each other, but that we’re working together, is really powerful if you want your program to be successful. You have to advocate internally. You have to make sure that people know what your ROI story is.

You Can’t Just Copy Twilio, Stripe, or Apple

Everybody looks at the next, you know, Twilio or Stripe or Heroku and says, oh my God, they’re growing so fast. Their stock is trading at such a high multiple. Let’s go do that. Let’s go do that. We’re going to go copy what they’re doing and we’re going to be successful. If you’re Apple doing what Twilio does, it won’t work. If you’re Twilio doing what Apple does, it’s a really bad idea. The reason is they’re a different company than you. They have a different product than you. They have different competitors than you. They have a different budget than you. Everything about their business is likely very different from every part of your business.

Well, I’m sure there’s a lot of different ways of doing this, but I’ve only seen three models be successful for developer relations. I’m sure someone will grab me afterwards and be like, you missed one. But the three that I’ve seen is you’re either trying to sell your product, which is what Twilio does, what Stripe does, what Okta is with their dev platform are doing. You’re trying to sell your product through the developer. Or you’re trying to build an ecosystem, and this is what Apple with iOS is doing. The more apps that exist on your OS, the more valuable that OS is. Or maybe you’re Apple and Google and people are now consuming more of your OS, which is your product. This is what Google with Android is doing.

Or the third one, which is not as common, but we’re starting to see a little bit more of it lately, is I already have a product. It’s already being sold successfully. We have this interesting opportunity where we have to go rebuild it from scratch. We can’t just copy Twilio. We can’t just copy what Apple does. We have an enterprise sales team. It’s already being sold successfully. So what we’re really trying to do is embed those seats that they already have deeper into the organization, so the organization starts building workflows off of their core product. Box with their platform is a really good example. They’re building out APIs and a developer engagement model, not to sell more Box, but to deepen the engagement for that product in the organization.

You have to pick which one you are, because which one you are is going to drive every other part of your program. If you’re Twilio doing what Apple does, it’s a really bad idea. If you’re Apple doing what Twilio does, it won’t work. So let’s actually think about what is our strategy? What are we really trying to do with our developer go-to-market? Are we trying to sell our product through the developer? Are we trying to build an ecosystem? Are we trying to deepen the engagement for a product that’s already being sold successfully? If you copy what they’re doing, you will fail.

There’s No Such Thing as “Developers”

There’s no such thing as a developer, right? There are millions of different kinds of developers. There are front-end developers, back-end developers. There are mobile developers. There are people working in Java, .NET, Node, Python, Ruby. There are data scientists. There are architects. There are senior developers, junior developers. A Node.js developer who is working on Heroku has a very different set of concerns than an enterprise .NET developer working in a purely Microsoft stack in the data centre. Depending how you look at your market, depending what matters to you, you need to slice them differently.

Once you have a really good sense of who your personas are, which developers are you really going after, then you can start to put together a plan of how you go after them, what features you built for them, what kind of experience you’re going to cater to them, the depth of your documentation. The sooner you understand who you’re targeting, the more focused and bespoke you can be in how you reach those people. Similarly, where are they? If you’re going after more junior front-end developers that are maybe one or two years out of school, hackathons might work for you, maybe, but if you’re going after very senior enterprise architects, you’re not going to find them at a hackathon, right?

You might not find them at the events that you’re going to find a mobile developer at. They may not read Hacker News, or maybe they do, but understanding who they are is going to help you figure that out. You need to know these things to figure out where to invest your time and money, because these programs are really hard to build. They’re really expensive, and chances are you’re really busy. You can’t deliver your program developer experience and developer relations if you don’t understand who you’re really going after, well, what do they care about? What they care about is going to drive what you build, what content you write, what events you attend, and how you show up.

What Metrics Actually Matter for ROI

So from a metrics perspective, please track your metrics. Otherwise, you don’t know if what you’re doing works. The next step, and I see this a lot, especially from people who are new to developer relations, is not that people aren’t tracking metrics, it’s that people are tracking all the wrong metrics. So common mistakes we see often are measuring developer relations by Facebook likes, Twitter retweets, GitHub stars, pull requests. That’s all great. That shows the health of a community, that doesn’t show return on investment on your developer relations program. NPS or referral is really important because the reason we’re all here, the reason developer relations even exists, is that the only tried and true way people have figured out to market to developers is through word of mouth.

So here are some metrics that I think are important. The first one is sign-ups. Are you getting reach? It’s visitors. Are you simply bringing in people to see your stuff? From there, are you getting sign-ups? Are people compelled enough by your message, by your product, by your features, by everything that you’re doing that they want to sign up for your service? The first one is sign-ups. Then you get into activation. Does the developer take the time to bring down your library, install it, open up a terminal or a command line, and actually make that very first API call? Or maybe your product’s different, there’s some other activation point, but are they putting the effort in?

And then once they put that effort in, are they engaging? Are they using the features? Are they trying out feature X, Y, and Z? How deep are they getting into the product before they bounce? Which is the next point, which is retention. Are they sticking around seven days later? Are they still around 14 days later? Are they around 30 days later, 180 days later, a year later? And then finally, revenue. So a general question is, how will your company extract value from all the work that you’re doing? Maybe it’s direct revenue because you’re Twilio and Stripe and you’re generating revenue off people using your service. Or maybe it’s implicit because you’re building brand awareness for the broader company. Or maybe you’re Apple and Google and people are now consuming more of your OS, which is your product.

So with that perspective, how do we build a successful developer experience and developer relations so that you can build a successful DevRel and DevEx program in your organization and be confident that you’re doing the best thing for the business? You should be tracking this. Is what you’re doing working? Which programs are working? When you’re flying all over the country, all over the world to give talks, which are the ones that are actually driving impact? And if something’s not working, stop doing it immediately. And if something’s working, do more of it. And if you don’t have a good answer to that, then it’s going to be very hard for you to be making major investments.

“You Can’t Measure DevRel ROI” Is Just Laziness

Everybody says, oh, you can’t do it. It’s really hard to measure it. These programs are really hard to build. It requires a lot of systems integrations. It requires a lot of labor. Extraordinarily hard to build, but worth every single penny. But you have to find ways of tracking it. If there’s a way to tie back to revenue, you should find a way to tie back to revenue. At the end of the day, you need to be sober about the fact that this has to tie back to revenue somehow. If you can put a public dashboard on something like Periscope or Grow.com or something like that, do it and let everybody have access to it.

I’ve invested heavily in this at companies to have dashboards that show everything from top of funnel aquisition down to revenue $.

It’s really easy in developer relations to see a blog post and say, oh, my God, we, Goldman Sachs saw this post on Docker, and they came in through that post, and six months later, they bought our product. Well, was it a fluke? Did it just happen to come in through Docker? Or we should write more about Docker. Do you expect JP Morgan and Bank of America and all the other banks to come in through that same post or similar content? You should be tracking this. So getting ROI is a big piece of it, but it’s not enough. You have to make sure that people know what your ROI story is.

Integrating with Sales and the Rest of the Business

For many companies, the developer go-to-market is not the only go-to-market they have, and this is really important because a lot of people in developer relations and developer experience, they’ve been tasked with going out and getting developer love, but it was never clearly articulated to them that they’re going to be measured on return on investment.

One of the things that’s interesting for those of you who care is you can follow us. Follow us on Twitter. In fact, our Twitter handle literally just went live today. Go to our website. Follow along. Follow us on either, you can email us as well with questions. Go through the flows. Tell us where developer relations is not working, where you think we’re off the mark, where you think we should be focusing on. Tell us where our developer experience needs to improve. Give us feedback. We’re just getting started. We’re making a really, really big investment. We want to give back, right? We want to drive community. But at the end of the day, we need to be focused on cost. People in tech often forget the importance of cost.

DevRel resources, one, are really hard to find. These programs are really hard to build. They’re really expensive, and chances are you’re really busy. You need to be focused on cost. And so, do you know if you’re generating word of mouth? NPS or some sort of referral metric is a good indication. This is where you ask somebody who’s signed up how likely they are to recommend your service to somebody else. From there, are you getting sign-ups? Do they activate? And then once they sign up, are they actually using it? Are they putting the effort in? And then once they put that effort in, are they engaging?

We can’t just copy Twilio. We can’t just copy what Apple does. We have this interesting opportunity where we have to go rebuild developer relations and developer experience at a brand new organization from scratch.

Make ROI Everyone’s Problem, Not a Dark Art

Educate the people on your team about your focus on ROI. Make it clear to them that they’re not there just to get developers to like them on Twitter or Facebook. They’re there to drive business. Educate your peers, the people on other teams, the sales organization, the marketing organization, the finance department. Developer relations cannot be this dark art that only those chosen few know about. Everybody has to understand where it fits and how they fit into it as well. That way everybody knows what you’re doing. So everybody knows that you are working on it and not hiding the ball.

If you’ve got metrics, if you know how things are going, communicate them up, down, to the left, to the right, to everybody around you. Share your metrics across the board. If you can put a public dashboard on something like Periscope or Grow.com or something like that, do it and let everybody have access to it. If the numbers are great, scream it from the rafters. If the numbers suck, be open about it. If your numbers aren’t working, own it and try and work on it. Then finally, hold yourself accountable. Make it clear to people that you’re going to hold yourself accountable. So, at the end of the day, as you’re doing your work, at some point, there’s going to be this tough moment at the executive staff level where they’re going to look at an expense report or the financial, you know, the financial statements and ask, hey, what is all this money we’re spending on developers? Are we getting a return on that investment?

And in some cases, you and your team’s jobs may be a jeopardy. So, no pressure. But somehow, you need to be clear on how you tie back. If there’s a way to tie back to revenue, you should find a way to tie back to revenue. You have to make sure that people know what your ROI story is. You have to advocate internally. You can do it. Everybody says you can’t do this. You can do it. It’s really hard in developer relations. This is a hard one for people in developer relations. But you have to find ways of tracking it. Otherwise, it would be very hard for you to argue that you’re a good investment for the business.

At the end of it, my hope is that you’ll be thinking about DevRel and DevEx in a much more effective way and in a way that you can articulate to anybody else in the organization what’s working for your customer set and what isn’t. Not just how do we get it right because we’re going to build developer love, but how do we get it right so that the business is getting value, so the business is getting a return on its investment, so we can continue to invest and our company continue to grow? So let’s do it the right way. We’re going to be talking openly about our experiences, the way, the lessons we’re learning, because one company is not the same as the other, and so there are mistakes we’re already making, and we will be very open about it.

We want to make sure that as large organizations like Goldman Sachs and other companies start to come in to us through our developer relations programs, that we’re doing a clean handoff if somebody’s interested in talking to sales. We’re all really focused on driving developer love. That’s so cool. But at the end of the day, you need to be sober about the fact that this has to tie back to revenue somehow. So, yeah, that’s how we’re going to do it. We’re going to be talking openly, we’re going to share, and hopefully all of us in this room today, because we’re hoping to learn from each other because talk to each other, follow along, keep us in mind. Bye.