Subscribe
Share
Share
Embed
In our latest podcast episode, we spoke with Keith Casey, Head of Go-to-Market and Product Strategy at Ngrok and Principal at CaseySoftware LLC. As an experienced API expert with more than twenty years of experience, Casey's on a mission now to help others create and consume amazing APIs. What sparked my interest in having Casey on the show was his recent blog post on API adoption and the pitfalls that come with it.
Casey explains how in the ideal world, users find an API, integrate it, and launch it (easy, right?). But often, API usage really follows a counter-intuitive pattern. This pattern follows three stages that Casey outlines as exploration, integration, and adoption in his piece API Adoption: The Dangerous Delay: https://caseysoftware.com/blog/api-adoption-the-dangerous-delay
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/
Building a successful API requires more than just coding.
It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.
In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.
Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.
They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.
They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.
Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.
Yeah.
I should be all set on this end.
Yup.
Hey, everybody.
First of all, thanks for having me looking forward to this.
Yeah.
So Jason and I go back.
I think it is about a decade.
Let's see.
I think you're at shipping company.
Yeah.
Way back.
And I was at a little company called Twilio, and I called a little company because I was employed number 25 or so over there.
Way back in the day.
I was the first evangelist, not on a coast, which is a kind of a weird distinction.
But it turns out there's a lot of space in between those coasts.
So I was covering a lot of that.
Let's see.
So I was there about two and a half years.
I was number 2025, up through about 250 when I left Jump, shipped there to join an Austin tech company, APIs making audio and video searchable that crashed and burned.
So I know a little bit about API adoption and how to not get API adoption after that.
You're welcome.
It was a blast.
I think it was a little too early in the market, but after that, I went to another company called Octa.
Does Single sign on Identity Management.
I was there for about five years.
Ran go to market product marketing, that sort of thing for the customer identity product, API security product for kind of reshaped, how we are looking at the customer identity market and really did that from the ground up.
And since I left there early 2021, been consulting with API companies or figuring out how to help them become API companies.
Really going from the very early bare bones.
Here's what an API is.
Here's how the design and build it all the way to.
Okay, cool.
We've got an API now, how do we get people to use it and helping people figure that out.
And so the blog post that Jason is talking about was a thing where I track through what that adoption looks like over time.
Yeah.
So a lot of companies start with they start with their existing product suite, they start building things out, and those are great Salesforce is actually an early example of that.
They built a CRM.
Okay, great.
At some point, they go, you know what, if we can plug this into other things, that's even better.
So then they start adding APIs on top of it.
We all know that story, but that's one mindset.
The other extreme is the Twilios, where there is no product except the API.
So they build from day one with how do we make sure that people can plug this into? Absolutely anything.
So I worked with a lot of companies on both sides of that in the last few months trying to help people figure out, okay, of the products we have, what's suitable for APIs, what should be our priorities.
Well, yeah, even adoption is a super hard thing to define.
Like Twilio coming into the Twilio building their API early on, the space they're competing in was SMS aggregators.
If you're not familiar with an SMS aggregator, it used to be before you could send a text message before Twilio times is you had to sign deals with these aggregators that they would take all this API traffic or all this, not even API traffic.
They would take all this binary traffic in, aggregate it together and then pipe it off to the carriers.
If you wanted to do that, it usually cost upwards to $0.10 a message, $1,000 a month for a short code, like a four or five digit code, and they would cost $10,000 just to get started.
And I worked for an SMS aggregator way back in the day, I built the voting system for American Idol season six, seven and eight.
So I lived and breathed that space.
So the first time I found Polio and it was zero to get started instead of $10,000 a month or $10,000, it was one dollars per number per month versus $1,000 a month.
And it was $0.01 a message versus $0.10 a message.
I'm like, oh, crap.
You're going to win like, you're going to win and you're going to win big, and you're going to blow all these other guys out of the water.
So I started watching Twilio at that point.
But you're right.
Most people don't have a very clean transactional model like that.
With a toilet, you're sending a message, you're making a phone call with a send grid, you're sending an email with a Salesforce, though it's way more abstract when I query a customer record.
Is that valuable? Should I charge based on that? And those things are a lot harder to figure out.
And I think the big business problem that most people are having with APIs and adoption and everything is lining up their interest with the customers interest.
Our whole mindset was, look, if you're sending text messages, that means you're being successful.
You're shipping product, you're interacting with customers, whatever.
So tying us getting paid to you, having a successful customer was really easy.
When you've got these more abstract use cases, it gets way harder.
So you start getting into number of transactions per month or just a monthly fee or something like that.
And that's way harder to figure out.
So adoption ends up being really it is the easiest thing, and it is the hardest thing all at once.
Yeah, exactly.
at bare bones.
The easiest scenario to track is are people making API calls, because if they're not making API calls, really, nothing else matters.
You've built a cool toy.
You haven't necessarily built a product.
No.
Yeah.
So I always throw out counting API calls.
Is the baseline starting there is an okay spot.
It's not great.
It's not going to lead to probably the growth and the patterns you want, because it'll start creating scenarios where when you request a page of results back then if we're counting by API calls, then you'll make sure that every request after that is one record at a time, and you end up with these really weird, bizarre anti patterns as a result of that.
So, yeah, that's the baseline.
That's usually not where we want to be.
Usually I want to map things back to are we solving real concrete customer problems? So this is where I put on my product marketing hat and I say, okay, the things that this customer is coming to us to do are we solving their problems? Are we solving them successfully, smoothly, consistently, quickly, to make sure that they're getting as much value as possible and to flip this back to design for a second.
This is one of the places where I always tell people.
And I've had this conversation once a week.
Almost.
We are the experts at our API.
We are the experts in our domain.
We need to act like it when there's a choice to take on that heavy lifting.
And we say, okay, should we put this heavy lifting on the customer or on us? We have to acknowledge that the people using our API are probably not using it 40 hours a week, 50 weeks a year.
That's us.
We're the ones doing that.
We're the experts.
We know all the terminology and everything we should take on that heavy lifting and let them get started as quickly and easily as possible so they can move on to something else.
At Okta, I coined the phrase developers have exactly two goals in life, build something useful and go home.
And that's it anything we can do to accelerate one of those things.
We should absolutely do anything we're doing that prevents or slows down one of those things.
We should stop it immediately.
And when we think about building something useful, we need to think about, is this valuable to do? Is it easy to get started? Is it productive? Are the docs correct? Are the examples useful? Those sorts of things in terms of going home? We want to make sure people can stay home.
So are things stable? Are they reliable? Are they going to get calls at two in the morning? Are they going to get called by the CEO saying, hey, I'm doing this demo, Jason, and this isn't working.
What the crap? Those are the last things we want.
So at that point, it takes a lot of one on one conversations to get started with it.
I follow pretty much a product marketing mindset there of sitting down, understanding their use cases, understanding their expectations, how we're positioning the API, figuring out which of the API calls are actually generating value for them.
So it's not like the Salesforce model.
It's not querying the customer record.
It might be updating it it might be logging that we interacted with the customer.
It might be something like that and understanding of the API calls we have which ones are the valuable ones? Which ones are the important ones? And then prioritizing around those.
Once you do that with a handful of customers, then sit down and figure out who are the customers or sorry, more properly, who are the prospects that are just like this group, who are their competitors? Who can we go to and say, hey, Jason's company is doing this and they're blowing you all the water.
Here's how to improve what you're doing, who are their competitors of who do they look like, or who do they look at for leadership, for guidance, who do they want to be when they grow up and sort of crawling up that tree up the stack to figure out who are the people that they look up to and going down that stack of who looks to them for guidance and leadership and just finding personas and use cases similar to them.
Yes.
Yeah.
Let me walk through the pattern.
There a little bit.
So in the dangerous delay, I found this pattern with Twilio with Octo with clarify that was the company I was at and a lot of the companies I consulted with, there's actually three kind of key periods of usage.
One is that initial usage.
It's that first time exploration that happens with your API.
Somebody says, hey, look, we found this API.
What does it do? And that can come from a hackathon that can come from a useful blog post, a guide that can come from a meet up where somebody said, hey, I found this useful tool.
Let me check it out.
And that's just a developer sitting down and playing with it and saying, Does it do what I expect? It's quick.
It's very concrete.
It's very specific.
The thing that scares most people after that is usage almost always goes to zero immediately after that, because they weren't looking to integrate into anything.
They were just playing with it to say, yeah, does this do the thing that I think it does? You know, it's like, go to your favorite electronic store, you stop and you play with all the toys.
You have no intention of buying it, but you play with it.
Then there's some sort of delay, and I'll go into the delay in a second.
But then there's a second bump and that second bump happens and it's a little bit bigger than the first because it's usually driven by a requirement.
There's a product manager that comes and says, hey, that thing we talked about six months ago.
We need that now.
That thing that we are worried about that's reached the top of the priority queue.
Get on it, please.
Hopefully they say, Please.
And so they go ahead and the developer starts building on it.
The cool thing is that our usage is a little bit bigger than the first time, because now they're actually playing with it.
They're using it.
They're testing it around.
It probably takes a little bit longer, because this isn't just like a little hack kind of thing.
This is actually serious development.
And then almost without exception, usage after that goes back to zero.
And most people freak out.
At that point, they're like, what just happened.
We had this customer, they were going to do stuff.
Where did they go? Well, think of it from the developer's perspective.
For a second, they just finished their sprint.
That's all it is.
Calm down.
Don't freak out.
They just finished their sprint.
Now there's going to be a lag between that development being done and that being in production.
There's nothing wrong with that.
But we have to remember, we have to stop, take a deep breath and remember that's what's happening behind the scenes.
And then when it goes into production, hopefully that we're looking at a hockey stick.
Now, the dangerous delay is that time between that first exploration and that integration step, because at that first exploration, your API is a cool toy.
It might address something that's somewhere on the priority list, but it's nowhere near the top.
So somebody isn't really thinking about it.
And the integration point is when that item, that requirement makes it to the top of that list.
Now, if you are addressing a problem that is a real concrete, painful requirement, then that delay is going to be relatively short.
If you're dressing something that isn't a big priority, it isn't that important.
It's not that painful.
Then that delay is going to be longer.
Or that delay is going to be infinite because you're not solving that big of a problem.
Or maybe you screwed it up in that exploration stage and you irritated the developer.
You frustrated them.
You didn't deliver on the promise that you made, and then there's no delay.
It's just infinite again.
Right.
And so the reasons it's a dangerous delay is that you don't know if it's a delay or if it's a departure, and you don't know that until they come back.
And that's scary.
In the example I laid out on the blog post that the dangerous delay was roughly nine months for the group I was working with, that's a terrifying delay.
That's a long time to wait.
But the dangerous is the flip side of that of when you're telling your higher level leadership.
Yeah.
This will take a while if it never materializes, you have a problem on your hands.
Yeah.
So the way I always look at is with that nine month delay.
That means the things you're doing in January don't show up until October.
That's a long time.
That's like, ulcer inducing kind of pain there because you don't know what's happening in between.
You know, if you looked at, if you looked at the world in 2020, the world changed a little bit between January and October.
So and so many of those things are outside our control, outside our knowledge.
There's no way we can possibly predict them.
So when we're working with a nine month window, it's almost impossible to iterate.
You cannot connect cause and effect.
There's no way to do that between those two ends.
So any way you can shorten that window ends up being really important.
And so the place where I mentioned we had a nine month delay starting off after about two years, we were able to trim that down to five months.
It took a lot of effort.
It took a lot of strategy, but we were able to do that.
And now that's within two quarters still not wonderful.
But it's to the point where okay, now we can start to plan.
Now, we can start to model things out.
Yeah.
So it's really a two prong effort.
So like I said before, when you go from the exploration to the integration stage, the thing that drives that integration stage is that requirement making it to the top of the list.
So we need to think about how do we drive adoption? Well, it's easy.
How do we make sure that the requirements were addressing are moving towards the top of that list? So we can say, okay, we can address more important problems.
We can put more emphasis on those existing problems to understand.
Oh, wait a minute.
If this is costing us revenue, that's probably important, let's figure out how to move that up in our end users, our developers mindset to say, oh, yeah, this is a problem or less probably less.
So developers, more product managers, the product owners to say, hey, look, if your customers are churning because of this, here's how by prioritizing this, you have less churn.
Here's how you make more money at the end of the day.
So that's the product manager story of what we're doing is valuable.
Here, let me show you.
Then the flip side is go ahead.
Oh, absolutely.
If you can attach your value to them, making more money, that goes a long way.
And the cool thing is that then the product owners go, oh, wait a minute.
If my turn goes down when I integrate, you cool.
I can track that.
I can have a tangible impact on my product adoption, on the cash flow, on whatever.
And I also say this among the startups I work with, I have a lot of these little quippy one liners, but cash flow settles most arguments.
Yeah, go ahead.
Well, that ends up being more on the end user side of things.
So it's understanding how are their customers turning what are their customers running into? However, they're tracking churn, however, they're tracking adoption on their end, on our end, on the API owner's end, we need to have a very close intimate relationship with our top customers.
To understand, here's what's freaking them out.
I ask every company I work with, what's keeping you up at night, what's stressing you out.
And if we're addressing those problems, then we can go really far with those things.
So we're not asking our customers, the product owners on our customer side.
We're not asking them to adopt a new tool set or integrate differently.
We're saying, why are you losing customers? What's preventing your customers from converting? Okay, cool.
You have these five problems.
Maybe we can't tackle number one, but we can hit two, three, and four.
How valuable is that to you? Let's get shipping on that.
Let's help these things move up your requirement list.
So your end of year bonus is that much bigger? As a result.