Kyle Wild: Hi, I'm Kyle. First, I wanna give a little bit of a disclaimer. This is the first time I've given this talk. So our design team, who is excellent, has not looked at these slides or helped me with them. So I'm gonna talk for a little bit about building and monetizing an API company, theory, practice. And to finish maybe some jokes. I didn't actually write any jokes. I might think of some jokes. So this is me, co-founder and CEO of Keen IO. We've been doing it almost six years. And before that, I was an early customer of Twilio, Stripe and SendGrid. I'm a big fan. Those companies are relevant because they're API companies. And I've got some stuff on what API companies are but given what I've gathered about the audience, and obviously our host, I don't think I have to go as deep. But I want you to look at this slide anyway 'cause it puts our logo next to theirs, which subconsciously makes you think that we're like them, which is good. So the list goes on, the... This is a class of companies whose core users aren't really people or businesses. The users are actually applications. And developers integrate these APIs into their applications. This is a new kind of company that's really emerged recently, and there are some things in building this kind of company that are a little bit different, so I wanted to talk to that.
KW: So this is more like, "Who uses these?" I'm gonna skip some of this stuff 'cause it's about what is an API company. But here's an example. I guess I'll talk through this briefly. When I try to explain what an API company is to my mom, I'm like, "So when you text your Lyft driver, there's actually this company called Twilio, that's a multi-billion dollar public company, that powers that SMS messaging and creates a phone number and all that stuff on behalf of Lyft, so that Lyft people don't have to learn how to build telephony infrastructure." Here's an example of how people will use Keen. So when you log into a SaaS application, there's generally like reporting or overview or dashboarding tab. We power lots and lots of those. And again, those companies don't have to learn how to do what we do, and we make a fraction of a cent when that happens.
KW: So it goes even further. We actually collect that through API calls to Stripe, and then we send our customers an email through an API call to SendGrid that says, "Here's your bill from Stripe for using Keen to power something in your application." So this is really how internet connected applications are being built today. And it's been a pretty big shift. When we got started five or six years ago, the people were using this word called mashup, which meant an application that makes a bunch of API calls to these platforms instead of doing its own logic. Nobody says mashup anymore because that's actually just how software's built. So it's become kind of the standard. So that's a little background on what an API business is, but this talk is about kind of lessons learned making a company like this ourselves and observing the industry.
KW: So before I go into it, there are kind of two core constituencies if you're gonna take one of these kinds of companies to market. First is the developers who build into their applications, in consumer APIs, and the second is the companies that these developers work at or the organizations these developers work at. I'm gonna focus mostly on number one, but I have a lot thoughts on two. It's just kind of a different talk like how to get into the enterprise where the developers work. This talk is going to be pretty short. I'm not gonna use most of this time so there'll be a lot of time for Q&A. And please ask questions if you're interested in number two. So I broke this into a few categories. The first one is product. When you're making this kind company, what should you do within the product. And our golden rule at Keen is minimize the time to value. This has been our key role since we started the company. Oops. Just trying to wake you all up. So any chance when you're designing the product, any time you can make it so that it's gonna require less code, one line of code instead of two or two lines of code instead of 10, always err on that side. Make it so developers don't have to think. They don't have to learn as much to get some level of value.
KW: Fix things like environment problems. Like developers, when they're trying out a new technology, they might only have 20 minutes to check it out. If the first thing they run into is it won't compile or there's something wrong with the version of whatever framework they're using and whatever SDK you've put out there, they will give up and they'll never probably come back. You won't get their attention for a long time. So minimize time to value. This kind of goes hand in hand with this. Make experimentation possible. Developers are tinkerers and they're builders, they like to experiment. And part of the thesis of this kind of company is you don't always know all the ways people are gonna use your API in their application. So for instance, when Twilio got started, there was not an Uber or a Lyfter, or like a ride-sharing economy. They didn't necessarily know that that was one way people are gonna use it. This is why, for us, one of the keys is to make experimentation possible. There are some tactics for how to do this. I think I maybe... No. And once it's possible, make it more and more likely. So tactically, this is things like have a free tier. Make it so that for a side project or for a hobby or for kind of a hackathon project, they're not gonna have to worry about paying you ever for that.
KW: Your paid accounts will subsidize all that usage. So having a free tier, specifically, I think there's a pattern toward having a free tier that's free forever as opposed to free for seven days, but then you better delete your code or destroy your app, although there are some examples of companies who've done well without that. But yeah, the key focus is experimentation. Yeah, so follow standards. Being cool in the developer mind is pretty crucial to growing this kind of company. You're not cool if all the developer friends say you use a competitor, but then their boss is trying to get them to use you. That's not gonna generate developer-driven growth, and one of the ways to do that is just to follow standards. Like if you're making a JSON RESTful API, look at what people are doing in terms of actual technical standards and then look at what people are doing in terms of what we think of as like fashion. And a lot of this comes down to being willing to copy what some of the great companies are doing.
KW: So I remember, in the very early days at Keen, in our version one of our API, we had some kind of... It's too technical to go into it, but a little bit of a debate on what to do, and we just kind of looked at what Stripe was doing on this particular issue, we were like, "Well, it's a toss-up except Stripe is already doing it this way, so let's do it that way." And for the things that are in the grey area, that aren't standard yet, copy the cool companies. And following standards is important for API development because eventually developers who don't work for your company are gonna make SDKs and make your platform usable, and if they're the kind of person who makes SDKs for... Like some new language comes out and they wanna go make a Go SDK for SendGrid then a Go SDK for Stripe or whatever, you want your product to be just as easy to wrap, so following standards is key.
KW: SDK is kind of everything. A lot of times, APIs are made by back end engineers, but your user base is actually an application engineer, and they don't spend their days reading API specs and looking at HTTP and cURL and in Linux, they spend their days writing code in a code editor, so that's the user interface that we think about optimizing for, right? Like if I'm gonna write code all day... We had this saying, like speaking the local language without an accent. I remember when I was a developer before Keen, I was trying to use... It was when AWS first launched some stuff, and this is an anti-pattern, even though it's AWS and even though they're super successful, at the time, we were trying to use PHP to basically use Amazon Web Services, and their SDK had clearly been written by somebody who wasn't from the PHP community. It had more files in this SDK than there were API calls. It was like 500 files for an API with three or four calls. It made it feel awkward. It made it feel like they weren't our people. They can get away with it because they're AWS, but maybe you can't.
KW: So in conforming to the idioms, since it's really about... So one of the things we do at Keen is if we don't have anybody that is good with the language, we just try to find a really good firm or contractor who's really focused on that language and pay them to make our stuff, or at least pay them to re-version our stuff, 'cause the SDK is oftentimes the first thing a developer's gonna see, right? Frequently people actually learn about your platform because they join a company who's already using it, and then they see the code and that's gonna be their first impression. So it's key for that code to market your company well. Never turn off an API. This has already come up earlier today. Never means like not even once. If you've got customers who've built a bunch of code and shipped applications that depend on your API and you break that, it's not good.
KW: Social media companies like Twitter and Facebook do this frequently. They can get away with it 'cause they're not API companies. They're social media companies and you need their social media, so they can make these mistakes, and developers are angry about it, but it's not like they can say, "Well, I'm gonna use MySpace instead of Facebook because I'm mad." Because MySpace doesn't really exist. So this is part of a general rule which is when you're studying how to make this business, copy from companies who make this kind of business, not companies who they do something else but they happen to have an API so you're gonna take their approaches, because their success wasn't dependent on their API being accepted, and if you're making an API company, that's your whole company. So never turn off an API. I won't go into many more details.
KW: Versioning, which one of the other speakers talked about, is a really great way to do this. We issued v1 of our API five years ago and any code that used v1 of our API has like /v1 or something in the URL, it still works, and it will hopefully work for decades or centuries. So if developers feel that, they'll build stuff on you. And this is product metrics. Focus on developer retention, not just organization retention. What I mean by that is like a company signs up, they use your product. Maybe the company churns. Maybe they went out of business. Maybe they got acquired by somebody else. In a traditional SaaS company, that's looked at like, "Oh, we lost an account." That's account churn. Our account retention went down, which is true, I'm not saying you shouldn't track it. But if you focus on developer retention, this means like an individual human developer, they're gonna have a new job every 18 to 36 months. If you retain that person for a decade, you'll get into a bunch more companies. The companies they work at are gonna grow. You'll have a growing customer. They're gonna get acquired. You'll get to pitch the company that bought them or merged them in, or they'll get shut down.
KW: If they get shut down, all the developers will go to different jobs and then you'll have access to more companies. So focusing on developer retention's pretty key. We kinda visualize this like there's a tool belt, developers have a certain number of loops. They have a hammer for payments and a hammer for sending SMS. You wanna be one of those loops on their tool belt. No matter what job they have, no matter what company they work at. And finally, developer documentation. This is 90% of user experience. A developer that sits with your APIs, they have your docs open in the browser, they have their text editor open that they're writing code in, and they go back and forth. A lot of companies treat this stuff as an afterthought. We're big believers in doc-driven design which often means like make a Word doc of what the feature would look like, show it to customers. It's easier to iterate on it while it's in Word doc form and you can focus on how easy it is to use, how consistent is it with the other parts of your API, how clean does it look from the SDK side. You want your docs to be highly accessible, so there's an anti-pattern here. We were looking at a database technology that I guess I'll just name because they're really big and they probably won't come after me.
KW: It's from a company called SAP, really big software company, and we had a specific technical question from reading through what we could find of their docs, and we're working with them on the partnership side so we talked to our partner manager over there and we're like, "Hey, so... " It's some kind of specific technical question. It was something like custom field type, JSON type column. I don't know. Something that we heard, found reference, but we couldn't Google. We couldn't find anything on [13:40] ____, we couldn't find anything else in the docs about it. So I e-mailed our partner manager, and he sent me a PDF of the real docs and I was like, "Why don't you put this on the website? This actually explains the feature." And he said, if we put the docs on the website, then we couldn't make a bunch of money on consulting fees. That's not a good way to get adoption for a development technology. So don't hide your docs to make consulting money. Maybe do, I don't know. It depends on your business model.
KW: I mean, they're pretty big, but we think of it as an anti-pattern. Got some screenshots and this is Stripes API docs for the API reference, we saw this maybe three or four years ago and really liked it. It's got some cool things. First of all, it's one long tall page, so you can hit command F or control F and search the page for anything. Second, it has a bunch of different languages on the right that you can kind of flip between. So any feature you're looking at, you can see embeddable code in Ruby or Python or Dot-Net or whatever. Here's a screenshot of our API reference, probably looks similar. That's when I learn from the best, great artists steal, and this was so useful to us as a Stripe user, we were like, "Well, why don't we make the next version of our docs look like that?" We [14:54] ____ this a couple of years ago and we didn't have to invent the ideas. One, they're a bunch of good ideas, but two, now any developer who's familiar with the Stripe API Ref is gonna automatically know how to use ours, and we watched this kind of trend in doc design flow through the whole industry and... We think it's really good, so we took it.
KW: So positioning, from a developer viewpoint, you're either made for developers or your not, and if you are, that's a big advantage, so you should telegraph that. A good example is, here's a screenshot of Twilio's homepage about a year ago. Build Apps are the first two words, that sounds like it's for developers. APIs and then a call to action that says Get a Free API key in the big red button. This obviously is for developers so when I land on it, I'm not inundated with kind of marking language that doesn't seem like it's for me. We were heavily inspired by that homepage when we rolled this new design out, maybe a year ago, and yeah, we lifted some of these ideas from them at Keen. Meter pricing is definitely the rage. It's not every developer company is doing it, but it's clearly the trend. Transparent pricing's always been key for working with developers. Pay as you go is really nice for encouraging experimentation and obviously free tier, like I talked about before. This allows you to, by basically charging for consumption kind of like the power company or the water company, it allows your whole organization to think about how do we drive consumption and know that revenue's gonna come, instead of starting every conversation with how can I make revenue. And consumption's what's actually gonna give you traction over time.
KW: This is very vague, essentially the kind of SaaS playbook, meaning like how did Salesforce grow, how did Workday grow, how did the pure SaaS applications grow. That playbook... Parts of it work well for a developer at API and platform companies, but parts of it don't and that's a whole 'nother talk, so I'm not gonna go into much more detail. In marketing, reference architecture is pretty key, so this is basically like how Lego shows a big picture of the Millennium Falcon so you can see that you could make the Millennium Falcon out of Legos. That's a good reference that helps people's imaginations kind of get moving on what can I do with all these building blocks that you're selling me. Those are really good and then actual solutions that your customers have built because a lot of innovation doesn't happen inside your company. It happens in the developer base outside your company. Promote those things, when you find good ideas, so that other customers can be inspired by them.
KW: There's a bunch more to say on marketing, but I think that's all I wrote for now. Yeah, and then in terms of sales process, the real design here is how do I help a developer or set of developers who wanna use my product or use more of it? How do I help them win budget? How do I help them go up the organization, or convince their boss's boss or whatever it is they need to do, you need to do, to unlock budget politically for them? Developers aren't the best at unlocking budget inside of organizations. In fact, the ones who are are called directors of engineering and above, so this is an important distinction. If you change your sales mindset into how do I help the customer who wants to use our product get corporate buy in so they can use our product, it's a lot better. We've tried other mindsets that didn't work as well. That's it. Abrupt ending. I wanted to get to questions. I don't really think linearly in terms of writing talks in... Which flow linearly. This is actually how I write talks. It's kinda crazy and chaotic. Yeah. I wanted to get to questions quickly while we still have time so... Questions?
Audience Question 1: Hello. At first, you'd shown about using different services, Twilio. What is your opinion about using one big provider instead of several providers? For example, using the old AWS services within different companies.
KW: Yeah. Part of this movement toward using... Even ignoring API companies, just using micro services inside of a company, inside of your own company, it's about separation of concerns. It's about my team is gonna build an email API. Maybe that team's gonna use Nylas. Maybe that team's gonna build everything from scratch. Whatever that team does is irrelevant to the other teams who are just gonna use the API. That's true for service arena and architecture... Micro services that people build on internally and externally. I think it's unlikely that one big platform company has the best of breed for every single kind of API that you might wanna use, so I think the... I don't know. I don't think there's a lot of advantage in doing it that way like it's pretty common for people to use Amazon EC2 for actually running their servers and use pieces of the Google Cloud stack especially things like data flow and then use like Microsoft's natural language APIs or something.
KW: That's even among the big three platform providers, they have different advantages. But for things like telecommunications, things like sending email... In one way, SendGrid has a major competitor in Amazon Simple Email Service but in another way, like last week, SendGrid launched on the AWS Marketplace. SendGrid is a whole lot easier to use, has a whole lot more functionality. I'd say the only reason to only use one platform provider is maybe to keep your bill clean. I don't know. I'm pretty biased against it, I guess. But I have a reason to be, you know... We [chuckle] don't... I'm not here talking about AWS so...[pause]
Audience Question 2: I had a question about the very last thing you said about the sales thing. It seems like the decision to use an API would be made at a much higher level than the individual developers that really like it, and so how do you go from, "Oh, maybe like 10 developers at a 200-person company want to use it, but the VP of engineering is not someone who like your landing page is speaking to or like whoever is actually gonna make the budget decisions?"
KW: Yeah. Developers are gonna focus mostly on ease of use. How quickly is it gonna get out of my way? Does it feel nice to use the stuff? And VP of engineering care about that and they care about making their developers happy, but we have different sections of our site that speak to different groups, so like your... Your H1 position on the homepage, there's only one of those. You have to kinda choose well how you do that, right? But there are other examples like Okta is a great API company who's H1 copy doesn't speak directly to developers, for instance. But we have solution section that speaks to more like VP product or VP marketing, different line of business people. You can have your secondary position speak to those audiences but the language is different. Like a VP Engineering is thinking somewhat about developer experience for their team but also what's the total cost of ownership, what's the... With them, it's a little bit more like, "How do I justify this kind of expenditure? Or I'm gonna weigh... "But it generally comes under buy versus build for VP Eng, at least in our case, so like, "Should I build this from scratch or should I build this on APIs?"
KW: Our sales language to that audience is more about cost and cost of ownership and then maintenance risk, 'cause a developer's thinking... This isn't necessarily true but they move jobs every couple of years so they're thinking, "How can I build stuff and get experience and move on?" VP Engineers are generally thinking more organizationally. So like, "If my team's gonna move on, how do I make it so we're built on something that wasn't like their homegrown, undocumented, non-standardized kinda thing?" It's different language, and we just kind of speak to it differently. Frequently, when the bill gets big enough, we know we're gonna have to get somebody higher in the organization so we do work ahead of that time to get the right messages to them.
Audience Question 3: Hey. How much of your business is built from developers first loving you and then it growing up? And how much is sort of more direct targeting to the VP of product or [23:37] ____ that?
KW: Pretty much... It's hard to quantify, but I'd say nearly all of it is from the developer. But as we've gotten closer to solutions-based stuff, it's moved, so like we've... The thing is it's hard to do targeted messaging to developers anyway. You can't send an email to a developer. I don't recommend it if you don't know them, whereas a VP marketing will open up that email. For us, even the cases where the VP product needed to do an embedded analytics feature set and kicked off an internal research project to develop, some developer on the Eng team had already heard of us. So, it doesn't always help us win those, but it helps us... We're always in the conversation because of the developer growth. So even in those cases, I think we attribute success to the developer base.
Audience Question 4: Maybe this is a dumb question, but what is metered pricing, and why do you think it's all the rage?
KW: So, metered pricing, what I meant by... I don't think it's a dumb question, I might have made it up, but the category of it for us is you're gonna use some unit and you're gonna be charged some rate for that unit as opposed to... So, there's a super category called usage-based pricing. Metered specifically means if you use 12 units, we'll charge you 12 times as much. If you use 100 units, we'll charge you 100 or maybe less times as much, but tiered pricing is more like... SendGrid's pricing is like if you send between 200,000 emails and 500,000 emails in a month, you're at this tier, and then as soon as you send that 500,001st email, you'll be in the next tier. I think metered is all the rage 'cause the math makes more sense to developers. I think it's also all the rage 'cause AWS has consistently been that kind of more close to metered approach, when in the early days, AWS was the only one really doing metered, and because all your SaaS bills are more tier-based, it was more popular, maybe, in early days for Keen, so five years ago, to do nice chunked tiers.
KW: So it's a smooth... Instead of it being a smooth bell curve, it's like, 100 bucks a month for quite a while, and then 200 bucks a month for a while, and then so on. I think that's flipped as AWS got more popular. It's arguably bigger than all the other API providers combined, and that's how they bill. So some of it's just that. People got used to paying kind of these random amounts of money every month to AWS, and it makes more sense engineering-wise. As an engineer, I look at it like it's round off error if you just round me up to the next chunk every time. So, I'd say that's a big part of it. It's also, selfishly speaking, tools that actually do metered pricing require really granular tracking. People use things like Our Platform to do that, and they'll think those things weren't as available before. So, yeah, that's pretty much why I think Stripe and Twilio are pretty clear leaders in doing it that way too, and they... So if Stripe and Twilio and AWS have been doing it that way for quite a while, it's gonna become the trend, I think, and we switched to it in January, so it's pretty new for us.
Moderator: Alright, so it looks like we are up in time. I think we can take one last quick question, if there is one, otherwise we can end the Q&A.
Audience Question 4: Hi, just as follow up on metered pricing, one of the challenges a lot of larger companies have with adopting metered pricing is predictable spend. Do you guys do anything to address that? It's pretty easy for a developer to screw up, and throw you in a while loop, and do 4, 1, to a billion call Keen.IO, and that would be very bad. What have you done to alleviate that concern?
KW: Yeah, so, I should've been more clear on metered pricing. I was describing the self-service, kind of developer of the credit card level of business. Once you get into enterprise sales, and for us, that's anything above the $2k a month range, those tend be a lot flatter. What we'll do is we actually will round up, and we'll say, "Here is the usage limit, and here's the monthly rate," and as long as you're under that usage limit, you're good, and we'll either do an overage or we'll reject traffic depending on what they want during a negotiation. As we got into kind of larger accounts, that has always been the way we do it, so it's not one answer or the other. It's like some organizations, older organizations, bigger organizations, organizations where engineering budget goes through a different group, and it's more finance-oriented, they tend to want more consistency. They'd rather commit to three years of their maximum level spend, instead of month to month, but I can't tell, even if they would know they would save money, it's harder to get budget. They don't allocate budget that way, so yeah, it's definitely not the only way we do it, in the large size, even if AWS does it that way. So yeah, that's custom negotiated. I recommend always being willing on custom negotiations, conform to how they like to spend. Somebody wants to give us $100k in Euros, fine. We'll figure it out.
KW: Awesome. Well, thanks.