Launching an API is the easiest thing you’ll ever do.

On the minimum end, you can put a framework in front of your database and call it done. If you add annotations to your source code, you can even auto-generate documentation. If you want to get fancy, you can use OpenAPI to auto-generate SDKs and a developer portal. BOOM. Done. You have an API.

But then you get to the real problem: API Adoption

Over the last 15 years of working with APIs, I’ve seen hundreds of companies launch APIs “successfully” and never actually get people to use them. Even when their teams go above and beyond with docs, SDKs, samples, etc, still no one cares. I know. I’ve done that once myself. It hurt. It hurt to spend weeks and months building something to only hear crickets.

In the ideal world, our users/customers find our API, integrate it, and launch to getting massive month over month growth. Unfortunately, we live the real world and API usage really follows a counter-intuitive pattern which maps into three steps usually called: Exploration, Integration, and Adoption.

Let’s talk about what that looks like.

Exploration

When someone first learns of our API, whether it addresses a major problem or just a curiosity, they play with it. They read about it, check out the How To or Quickstart guide, and try some code. Overall their usage looks like this:

At this stage, the developer is just exploring. They may not have a project in mind or an immediate need but they’re figuring out if our API does what they expect. The good news is that now they know about us. The bad news is there are 50 other more important things on their Jira board, the dog is barking, the newest Netflix series just dropped, and the kids need dinner.

And then time passes..

Integration

At some point in the future, a requirement appears. Even better, that requirement needs our API! Even more better, that requirement is top priority in this sprint. Our API has another chance to shine!

Unfortunately, we don’t have the SDK for this week’s Javascript framework and now we feel the pain of our mediocre documentation but the docs are accurate and we gave useful examples, so the developer can still integrate the API. This is a huge win and we watch traffic go up for a few days or even a week.

And just as quickly, the traffic drops all the way down to zero. What happened!?

Adoption

Whew. It turns out the drop off we saw was simply the developer finishing the sprint. Now that it’s tested and deployed, we’re into production.

And NOW we see the hockey stick we hoped for. Now they spend money with us. Now we see more and deeper integrations.

But is this what API Adoption really looks like?

Unfortunately, yes.

Over the past ten years, I’ve validated this with API companies of all shapes and sizes. Some you’ve heard of and probably use, some didn’t manage to turn themselves into real businesses. Regardless, every single one saw an adoption curve like this.

Except when they don’t and that creates the Dangerous Delay. It is the single most dangerous moment for an API company.

The Dangerous Delay

The Dangerous Delay is the time period between these two bumps. At first glance, it’s the time between when a developer finds your API and integrates your API. In more precise terms, the Dangerous Delay is the time it takes for your API to change from a curiosity to a need.

When I initially noticed this trend working with one API company’s data, their specific delay was an average of nine months. Nine months. For every prospect who found the API in January, they wouldn’t integrate until October. That means as you experiment with marketing and sales, you can’t even guess which dollars were useful or useless until multiple quarters later.

The good news is adoption means we may have a business. Every dollar keeps us in the fight a little longer to let us experiment, iterate, learn, and apply the results. Unfortunately, we need to figure out how to pay the bills in the meantime but we attempt a variety of things to shorten this delay. In the situation above, with a lot of work, we were able to reduce nine months to five months. It’s still a long time but more manageable.

The bad news is this is scary. In our nine month example, month one and month eight are identical with zero usage. In fact, we don’t know “nine months on average” until we pass nine months and have adoption data to look back on. That could easily take twelve or fifteen months.

This is the danger of the Dangerous Delay:

We can’t tell the difference between “not adopted yet” and “never going to adopt” until well after the fact.

Has one comment to “API Adoption: The Dangerous Delay”

You can leave a reply or Trackback this post.
  1. Agatha Harkness

    Thanks, Keith, for sharing this article. And I have seen companies care less about this path and care more about the alternative way. I’m sure you are aware of this alternative path.

    Account executives and sales reps chase potential customers,
    telling stories about how their product (API) can solve customer problems. How customers can accelerate, be more efficient, and grow business with their product. They will help by providing training and a customer success team for a smooth onboarding.

    1. The exploration phase can be shortened by providing training.
    Examples:
    Training | commercetools
    Book a training CoreMedia

    Certifications are crucial in Germany. “Certified developer” is one of the bullet points to win the deals for the agency partners. So, I can say do the vendor provide training and certification? Is one of the criteria on the decision to purchase the product.

    2. The integration phase can be shortened by taking help from Solution Engineers and delegating it to expert agency partners.

    Of course, training and support are not FREE; they come with a cost.

    Still, developers have a call to make technical product choice decisions; I borrow your argument here; they are usually busy with projects and have less time to explore all competitive products analyses extensively and make tradeoffs.

    What do you think?

Write a Reply or Comment

Your email address will not be published.