"APIs are products, not projects" has become a trope in the API industry: if APIs are products that implies that they will be able to generate revenue, and are worthy of a bigger investment. But are APIs really (always) products? Is a product mindset truly the best way to make successful APIs? Or is API-as-a-product only a transitory phase of the API industry?
In 2024 I think it is time to stop blindly following the playbook of the API-industry darlings, and to let APIs become what they were always meant to be: interface utilities.
Interface utilities don't need to differentiate themselves to create a bespoke developer experience, instead they embrace standardisation to enable the next wave of innovation that will be built on top of them. In this article, I will explain what is wrong with product-in-a-marketplace thinking, why I believe today's APIs are the precursor of an interface utility infrastructure, and how we could create new, better products on top of them.
What is wrong with API marketplaces (and API products)?
When customers say they want to build an API Marketplace, I start worrying about the eventual success of their API program. Marketplace is a loaded word that triggers a range of expectations that are a bad fit for developer portals. No, you can't get a defensible 30% margin on other people's APIs. No, spray and pray is not a successful API strategy. No, most APIs will not create direct revenue. There is a lot of value and potential revenue in API programs, but to realise that value you will need to execute on an API strategy that is adapted to your organization and your market.
That is why, in my opinion, if you are trying to make a lasting impact in your organisation, API Marketplace is the wrong thing to name your developer portal. Calling a developer portal an API marketplace perpetuates a fundamental misunderstanding of how APIs work:
APIs are not products, they are utilities that enable API products
API products are distinct from the underlying APIs that they provide access to:
- APIs are economy of scope assets that become better from reuse, the more we use the same API designs, the more valuable they becomes.
- API products are economy of differentiation assets that are designed to maximise value capture.
I derived this insight from Jabe Bloom's 3 economies model. Check out our podcast interview with Jabe Bloom on the 3 economies to learn more about economy of scope, differentiation, and scale.
Publishing your existing APIs and microservices unaltered is not going to make you money
It is possible to find new customers or markets for the capabilities your existing APIs encode. But to maximise value, a new API product will need to be designed that is aligned to the distinct market opportunities you discover. Radically different pricing might be needed for different use cases of the same API. A nuanced API product strategy is needed for each use case of your APIs to protect your strategic business interests, grow your community, and/or maximise your profit.
API product portals
Instead to maximise value creation and value capture, organisations should be building API Product portals that guide customers to the right interface and API product depending on their use case. This is more complex, because it will require more nuanced information architecture and a continuous effort to discover new affordances in your APIs. Developer portals with a flat API catalogue simply cannot fulfill these requirements.
The API product confusion
But what is the source of this confusion? And how do we correct it?
I think the current confusion started because of 2 reasons:
- Most companies shouldn't try to emulate the API-darlings, they should do their own thing: The API industry kicked into high gear after the initial success of the API-pioneers, now it needs to evolve beyond that model. Once companies like Twilio and Stripe showed that it was possible to make money with APIs, other companies started to replicate the API-first playbook and all its developer-centric practices. But here lies the problem: API-darlings create value through a differentiated API design with a unique developer experience. For other companies these might not be the right thing to focus on (more about the alternative in future blogposts).
- Historically, APIs were treated as sub-projects that were backend services for a range of interface patterns (e.g. integration projects, mobile and web apps, partner communities). While treating APIs as products represented a significant improvement, it was only an incremental change in the right direction. API projects don't have the longevity to support important interface products. If you or your ecosystem are going to build more than one interface on top of an existing API, that API needs to be even longer lasting than a product. So to achieve the true value of APIs, they really should be treated as utilities.
APIs as an Interface utility
Ever since I've learned about Wardley mapping, I've been wondering how Wardley mapping plays out in the API and developer portal space. That made me realise that the product stage is not the final stage for APIs. There are some key counter examples like the Kubernetes ecosystem that show how much value can be created when an ecosystem adopts a set of API standards, but why don't we see more API standards evolve? In Wardley speak, What is blocking APIs from evolving into utilities?
I think the API industry is currently stuck at the product stage because of the artisanal nature of application development. Because applications are handcrafted by developers, there is an incentive for a fragmentated API landscape. This effect is further entrenched by the winner-takes-all nature of the API industry: everybody wants to be the next Stripe.
But as LLM AI systems start consuming APIs, this evolutionary block might get lifted. When AI-driven API consumption starts to reduce the value of applications and increase the importance of APIs even more, the art of handcrafted API design will come under pressure. This might be sufficient to drive a standardisation of API design, to a level that at least allows for AI systems to successfully make API calls, and in turn break the incentive for differentiated design. Once that happens, competition will shift from developer experience towards business logic and business value.
The next generation of API products
When electricity became the de-facto utility platform for power, this triggered a Cambrian explosion of power-tools. Today Western households have hundreds of electric devices that fulfill all kinds of functions from illumination through washing, drilling, heating, etc. Similarly when APIs become a utility platform, this will create a massive increase in the usage of APIs and of digital interfaces.
But will this increase also create margins for the API creators and distributors?
When APIs become a utility, differentiation will shift from having the best API design with the best DX, to having the best business fit of the API products your organization provides or distributes. Having only a single API product tied to your APIs destroys value for your business. While the marginal cost of an API call might be close to zero, it sometimes makes sense to give money to some API users, and to charge thousands of dollars to others. The challenge is to learn to differentiate use cases so that you can offer the right API product to the right customer.
Conclusion
APIs really want to be a utility, and not a product, and it is only a matter of time until they will fulfill that function. In anticipation of the further evolution of the API space, it is important to see APIs and API products independently from each other. That way it becomes possible to separate the utility aspect of the API technology, from the product aspect of the API product. This in turn is essential to derive business value from APIs (be it through monetisation, ecosystem development, or complementarity with existing products).
If you like this article, and would like to learn more about how to create differentiated API products, get in touch, or register for our mailing list where we will send out similar blogposts when we publish them. You also might enjoy the following articles or any other articles from the APIFutures:
- Three Predictions for 2024 by Mike Amundsen
- How simplistic API product thinking is holding back progress by Marsh Gardiner
