Not all companies’ API business models are the same and their users have different motivations too. In this talk from DevXcon San Francisco 2018, Nexmo’s Sam Machin asks you to consider whether your developers are customers or partners and explains why the answer can impact your devrel and devex approaches.

Transcript

I’m gonna talk to you a little bit about understanding your developers, and whether they’re a customer or a partner, and the kind of understanding how that will change your approach. So first of all, yeah, thanks. I’m Sam Machin. I’m a developer advocate at Nexmo. I’ll do the customary quick show of hands. Who’s heard of Nexmo? Okay. This is Phil’s metric you see for, like, raising hands. So recently, kind of earlier this year, I’ve sort of moved. I’ve been in the dev rel team for just over two years now. But I’ve moved to a slightly different role within the team, where we’re starting to look at partnerships. And we’re calling it extend. How we extend our capabilities by partnering with other APIs.

Which I’m sure I’ll probably love to talk to some of you about that if you’ve got kind of complementary technologies and things like that. But also, that’s kind of got me looking at how that differs the dev rel approach for those kind of companies. And the epiphany I had was, “There are actually two types of API companies out there.” And the fundamental thing is, whether you’re treating developers as customers or as partners or as something else.

Your customers? Your developers? Every company is different

So the first thing I wanted to kind of say here is everybody’s different. There is no right or wrong answer. I’m not gonna tell you, “Hey, you should be treating your developers as partners,” or, “You should be treating them as customers.” The answer is different depending on your scenario. So I really want you to kind of think about your own company. What’s your approach? I’m gonna try and give you some pointers to kind of identify maybe where you fit within that space.

So quick show of hands, how many people’s company offers an API? I’m assuming just about everybody of some sort. If you’re selling shoes, you’re probably not here. Okay, so, you know, we all have an API to some extent, whether that’s like a hardware device API, or SDKs right through to kind of cloud services. So the next question is, yeah, “Is your API the product?” So this is the important thing. We should be treating our APIs as a product, a product we offer. But is that the primary product of your company? Are you an API company or is the API a secondary product? Is it what somebody knows your company for? So two ways to kind of look at this. Firstly, do you charge for the API? Is the use of the API how you make money? So at Nexmo, we charge you to access our API.

The other thing is then, who are the users of your product? Do you have end users and developers, or are your developers your user accounts on your system? So that kind of make sense? Yeah. How many people would say that the API is the product in your company? Quick. Okay, less than I thought. What’s interesting as well is there’s actually quite a lot of dev tooling companies in here, which is maybe developers are still the customer in that sense.

What does it mean to be a ‘developer’?

So I kind of started trying to map this out. And this little sort of quadranty graph thing, in a very unscientific way, is me dragging stuff or icons around the screen. As I was trying to look at where different companies sit. So we’ve got two. On the side, I call them users. And there’s a term that we started to use a little bit, or I started to use within our extend thing of builders. We say the word developers constantly. It’s almost like being a Steve Ballmer convention, doesn’t it? Because how many times has somebody said the word developer today?

But, actually, ‘developer’ implies a very…we always think, “Oh, that’s somebody that writes code.” And actually, in this space, there’s a lot of things where people are creating with our product. Especially these kind of if this then that Zapier type products. I would say if you’re building a script or a recipe in Zapier, if this then that, you are building. You’re not just using the product, you’re building something for somebody else. Even Google Docs, the forms you build in Google Docs, you’re creating something there. So you’re offering a componentized system, but you wouldn’t think of somebody that’s doing that as a developer.

So yeah, on the side, we have users and builders. And then the bottom, product, and platform. Yeah, really, it’s just, “Are you more of a component somebody uses in your system, or are you a something you use as a shrink-wrapped thing, or a building block?” So if we look at this, we’ve got up in the top left, we’ve got the very much user-centric products. In the middle there, Apple. Everybody has heard of them, I hope? They’re quite big. And specifically, the iOS app store ecosystem. I think WWDC, yesterday or the day before in the keynote, they announced they just paid out $100 billion to developers. So, you know, their business model is not to charge developers in that sense, because the cash is flowing very much the other way. So that’s the extreme. Really, Apple is a consumer product company. But they have a huge developer ecosystem, which is powering that, making that product.

And then down on the bottom right, we have the classic developer as a customer. So, you know, Nexmo, Pusher, Stripe, where developers are using the API, the product. They’re embedding it in their stuff. Couple of interesting ones. Google Maps. That’s funny because most people think of Google Maps as a user product. But actually, how many websites do you go to where you see the little Google Map embedded on every little random local bar or, you know, small business? And it might just be a snippet of HTML they’ve embedded. But that’s a kind of more of an API-developer-builder offering that they’re putting out there. So they start to kind of move down a bit.

Examples: Amazon and Slack

Amazon is kind of interesting. So Amazon have very much like two fronts. We have Alexa, on the top of the blue circle, and I can say that without something beeping on the stage behind me for once, and then we have AWS. And Amazon divides their dev rel activities into two sides of the business. So AWS, they charge developers. You’re selling a product to developers. You pay for EC2, or S3, or storage, those kind of things, on a per usage basis.

But then on the Alexa and the Fire TV, and that kind of side, you know, Alexa is a consumer product. But they have a huge dev rel activity to encourage developers to build with the APIs to enhance the product. And again, Amazon are actually paying out money to developers now. If you build a successful Alexa skill, you’re getting a cheque from Amazon for like $1,000 in a month or something because developers are becoming a supplier to them.

Slack, I think, is another one. We’ve had a couple of people talk about Slack and things today. Slack is a really clear-cut one here, where Slack sells a product to companies. They want companies to use Slack, so they’ll go and Nexmo pays for Slack, and we use that as our internal tool. But the Slack developer effort is developers are building features, bots, whatever little plugins to enhance Slack that makes the Slack product more valuable when they sell that to their customers. So the developer team at Slack, the dev rel team, are not really thinking of developers as customers. Maybe there’s obviously this overlap and things there that a lot of people that are building on your platform are also using your platform. But that kind of thing shifts a bit.

Reasons for offering an API

Okay. And so next question to ask yourself, you know, “Why do you offer an API?” This may seem a little bit odd. But yeah, you said you have some sort of API. If you’re not an API first company, or if API isn’t the product, why are you offering it? So obviously, if it’s your product, you know, for Nexmo, that’s simple. Why do we offer an API? It’s how we make money. We wouldn’t do very well if we didn’t have an API. But then think about the other ones.

The first one, it’s to increase the value of your product. So this is Apple, Slack, those kind of people. It makes the product we sell more valuable to customers because of what developers build on the API. They are enhancing our product. You know, how many people would buy an iPhone if you couldn’t get any apps on it? Windows Phone. Why did Windows Phone kind of not really take off? The general consensus is because it didn’t have the support of the apps. So it doesn’t matter how good for something your product is, often your product needs the developers to make your product a success.

Then there’s, like, to broaden the reach of your product. So this is the concept like the Google Maps thing. Why does Google want you to embed Google Maps in your website? Because people recognize the Google Maps style and look. And it’s, “Oh, yeah, that’s Google Maps.” In the UK, we have the Ordnance Survey maps. It’s like a standardized thing that the government produce of maps for going out hiking and stuff. And it used to be that people could read OS maps. I think we were even taught it at school to understand the different colours and shades and stuff.

These days most people really couldn’t. But everybody knows on a Google Map, “Oh, yeah, that’s a, what is that a beige box, that’s a building.” It has that kind of visual ignition. And it’s worse when you go to a page somewhere and they load you up like a Bing map or something. And then you’re like, “Huh, what? I don’t remember this.” Because Google have made Google Maps the ubiquitous standard. So they’re getting people to embed it, which means that, yeah, when I want to search for directions, I go to maps.google.com

Broad reach and niche features

Alexa do this again with the Alexa voice service. So the other half of their API, they provide an API so that you can embed Alexa in your own devices. So people like BMW are building that into cars and that kind of thing. And developers are building it into toasters and weird devices. But, again, it’s making the product more ubiquitous. It’s broadening the reach of the product because it means it’s everywhere, and they win that way.

And also, to offer the niche features, the customization of our product. So it’s accepting that if you’re building a consumer product, or a user product I should say, particularly actually in enterprises, you’re not going to be able to offer every feature every user wants to all of your users. Because one, you’re going to end up with a really, really cumbersome product with 400 different option menus and settings and everything. And also, it’s just some stuff is gonna be too small for you to bother with, or you don’t understand that marketplace. We’re not experts in that vertical.

So by offering an API, people that use your product that do understand that specific space, they can tweak or build the extensions to your product that mean that it fits it. And enterprises just always want to change something. You sell software to an enterprise, it always seems like, “Oh, yeah, yeah, yeah, it’s great, but we want to change that. Because, you know, we can. And we’re gonna buy 1,000 seats from you if you make that menu blue,” or something.

Four motivations for API use

Okay. On the flip side, why do developers use your API? Why should they? What’s their motivations? I think the simplest or the earliest stage if you’re just starting up or opening up an API, it’s to solve their own problems. It’s the hobbyists, scratching your own itch scenario. Developers like to be able to tweak or customize a product. I think, again, why do developers like Slack? Because they can build their own little plugins. I have a hookup to my doorbell into my personal Slack group organization, which is just me. So when someone rings my doorbell, I get a popup message in Slack. I’m never gonna productize this. I’m never gonna sell it, but it’s really useful. And, like, all my home smart-home automation events get posted into a Slack channel and things, because I want to tinker with that. But that base stage of developers doing stuff, they’re gonna play with the product. They want to extend it.

Then they want to enhance their own product. The great example here I think is Expensify and Uber. So most people probably have used Expensify if you’re expense tracking. You can link your Expensify account to your Uber account. So when I take a trip on Uber and I’ve used my business account, it automatically loads it into Expensify. I don’t know who built that, whether that was Expensify used the Uber integration or Uber used the Expensify API. It doesn’t really matter. But that’s brilliant because the two products have both been enhanced. It’s win-win, you know. I’m more likely to use Uber because it automatically imports to Expensify rather than using some random taxi where I’ve got to get a little bit of paper and take a photo and things. And I’m more likely to use Expensify because it just makes it easy to import stuff into Uber. So that’s the win-win scenario for offering an API, looking at partners.

Re-selling your product, like FinTech and that kind of space, that’s quite common, too. People will, you know, they’ll just want to refer you. They’ll sign up a customer and you’ll pay them out a referral. White labelling your product, that kind of thing.

And then the final one is, you know, building a business. You’re gonna become a channel. This is that marketplace space where developers are gonna build something on your product. They’re gonna offer an app or an extension of your service, and you’re gonna sell that for them.

Competition, misuse and brand damage

Okay, things to think about, things to watch out for, the dangers and pitfalls. And I think what’s important here, you know, it’s important to think about this stuff up front, before it happens, rather than waiting until one of this kind of moments occurs, and then you have to kind of be in a reactive PR face-saving mode because something’s blown up on Hacker News or Twitter or Reddit or whatever.

What happens when a partner uses your API to build a product that competes with your product? If you’re a product company, this…you know, and you can pretty much go and see this will happen at some point. And you as dev rel are gonna be the ones kind of talking perhaps to the partner, to the developer. And you’ve got product guys, who are interested in the revenue targets for the product and they’re not maybe looking at the company as a whole, who are gonna say, “Well, you’ve got to kill their access. Pull their API key. Disconnect them. Kill their product off.” And that’s gonna be awkward, you know, you’re not gonna come out well. So have that conversation with your product team up front.

What about misuse, brand damage? What happens when somebody creates something – I’m sure we can all think of ideas using the darker sides of our minds as to something you could create with an API that isn’t great PR for you as a company to be associated with but is now doing really well on beta or Reddit or whatever? How are you gonna manage that, handle that? Are you gonna have up front approvals, are you gonna have an invite-only, something like an approval process in the app store, like Apple have? Are you gonna just let it become the Wild West?

And then, can partners use your API to short your revenue model? What is the revenue model of your product? That’s quite important to know upfront. And then when you’re offering an API, you’re not putting that revenue model at risk. You know, I think we all kind of know the problems that Twitter had in the early days when they were talking about developers and APIs. Because they suddenly realized that they were kind of losing control of the users because people were third-party apps, and people were never interacting with Twitter. So they wanted to try and introduce a revenue model and ads. I mean, ads are a really good one here. Where if your revenue model for your product is ad driven, and you’re offering access to the content of the product via the API without serving the ads, that’s risky. People are gonna find a way to…people are gonna build other ways to consume your product.

And finally, how will you manage competition? If you get to that marketplace, that ecosystem thing. We’d all love to be Apple and have the $100 billion of payouts to developers. But Apple have to manage that ecosystem, that marketplace. Competition, we agree, is a great thing. We need competition, but you have to police it. You know, what happens when you get people leaving fake reviews for products, or developers complaining to you that, “Hey, this developer’s copied my product.” And you suddenly become this arbiter of the ecosystem, and that can become a huge kind of community drain. If that falls to the dev rel team…now hopefully by the time you get to the stage of the app store or something, you’ve built up that team. But if you’re building out an ecosystem, a marketplace where your developers are gonna compete with each other, then you have to…are you gonna ensure fair competition? Are you gonna have preferred status? Are you gonna cross-promote developers? Your sales guy is gonna go out and sell things?

Activities and marketing differ between developers and customers

So speed up a little two slides. So then looking at some of the activities you’re gonna do, how do the activities you’re gonna do differ whether you’re talking about customers or partners? So on the left, we have the stuff you’re gonna that I think probably doesn’t really change massively whether you’re charging developers or not. So obviously this the classic dev rel stuff we all do. We all want to create great documentation and libraries. Developers want that whether they’re paying for it or not. We’re gonna build demos. Maybe your demos you need to think a little bit about. What are we trying to encourage people to do? Are we trying to give away a product? They’re gonna just copy a demo and launch that in our app store? Are we trying to show them, or are we trying to help them solve a solution? But, you know, generally, you’re gonna still create demos in the same way. You’re gonna write blog posts, collect feedback, give talks, all that kind of stuff is the same.

And then the stuff that changes a bit. We talked a little about the community. I think community is very different depending on whether you’re charging your developers or not. If they’re customers or they’re a partner, that really is gonna change. And then the other stuff is really the rest of the organization, the rest of the company, how you interact with them. You know, your relationship with product, with support. If you have a support team, and your developers are customers, they’re probably talking to developers. If you have customers who are users, your support team are probably geared up to support them as users, and you may be providing the developer support.

The marketing tone of voice you use. Again, that’s gonna change where if your marketing team are selling to enterprises, but you want to talk to developers, you may have to have a very different tone of voice. The same thing for brands and, of course, sales. You know, let’s all talk about sales for a minute. The sales guys, are they selling to developers? Or are you giving the sales guys something that makes the product more valuable to talk to people?

So, final slide, wrap up. The takeaways really, things I want you to understand. Know your own position. Understand where your company is. Take some time to think about, “Where are we actually? Are they customers? Are they partners? What are their motivations?” Looking for those mutual benefits, those win-win scenarios where somebody can build something that means that both your products are better.

And I think the final one, value the trust developers put in you. If they’ve chosen to build on your platform, if they’ve chosen to build a business on your platform, they’ve got a lot more at risk actually than you have. So don’t pull the rug out from under them, because it might be how this guy’s paying his mortgage or something. Thank you very much.