“API Products” are mentioned relatively often, and there are different ways to look at the topic. None of them is inherently “right” or “wrong”, and we’ll discuss the two most important flavors of API products in this blog post. Whenever you have conversations about API products, it can be helpful to make sure that everybody is talking about the same thing, and understanding the two main perspectives can help with that.
The most important takeaway of this blog post may be that it’s important to not conflate the term “API Product” with APIs that are specifically marketed and monetized as externally provided products. Much more often, API products will be parts of a bigger value chain picture, and in those scenarios it is equally important to understand what it takes to create and manage API products.
What is an API product?
Looking at how the term “API Product” is commonly used, two main uses can be identified. We’ll start with the narrower definition and will then extend this to the more general understanding of what an API product is.
In our experience, it is much more helpful to use the more general understanding, because otherwise you will lose out on all the benefits that come with approaching all business-relevant APIs with a product mindset.
API as a Product
In a narrow sense, there’s the idea of managing an API as a product in and of itself. That’s something that’s tantalizingly easy to understand, but sadly also only makes sense for a thin slice of API use cases in the real world. An API as a product example would be Twilio and Stripe, where your API is the product you’re selling; and some companies have become very successful doing it.
There’s nothing wrong with that view, but it does not accurately capture the reality of the overwhelming number of organizations on their API journey. Very few of them have the intention of marketing APIs as their main products, which means that approaching API products with that narrow mindset misses the reality of the majority of organizations.
For this reason, we propose to use the term “API Product” in a more inclusive way, making sure that we capture the realities of the majority of organizations out there. In that world view, the goal isn’t to just look at externally-exposed API products. Instead, the goal is to make sure that you’re treating all APIs that contribute to your organization’s business goals as products, and that you’re managing them accordingly.
API products in general
The main value of APIs lies in their “packaging” nature: they wrap any digital building block in a way that make it usable for anybody interested in that capability. This “packaging” nature applies to any potential user of that digital building block.
The larger organizations become, the more it becomes important that they properly manage and provide all their capabilities for internal consumers. That’s the only way to make digital transformation work, which in its most simple definition demands that you transform your organization so that it can easily capture opportunities in the digital realm.
Jeff Bezos’ famous “API mandate” means, in essence, treating any capability as a product with an API, specifically also those that are not (yet) intended for external consumption. Limiting your product perspective to APIs intended for external consumption will forgo most of the benefits of APIs and will turn your organization into one that’s digital on the surface, but hasn’t quite taken the step towards true digital transformation.
What this means for our “API product” discussion is that you should approach all your business-level capabilities as API products. To be sure, this is a long journey, both in terms of building the skills and practices to manage API products, and in terms of slowly building up that catalog of API products that form the digital foundation of your organization.
But today we have more and more experience in how to do this, we have software solutions such as API marketplaces that help you do it, and we have plenty of proof that doing it is a worthwhile investment in your organization’s future.
What really matters for API products
Now that we have established that a more general understanding of API products will get you further on your API journey, what really matters for API products? We don’t have enough space to discuss all the details here, but here are some areas that you should keep in mind:
- API product lifecycle. Like any other product, API products have a lifecycle. They are conceived and designed for a specific set of consumers, they need to evolve alongside the needs of these consumers, and they need to have a well-managed product lifecycle from inception to sunsetting.
- API product development. Product development always is an outside-in process, starting with the needs of a user group and following a design process to best serve the needs of that user group. This can be quite a shift from the inside-out mindset of many APIs that simply expose technical capabilities without thinking about the needs of consumers of that capability.
- API product owner. In order for the lifecycle to be managed, and in order for the development to maximize the usefulness of the API, API products should have product owners whose job it is to make sure that the API creates the most value for the organization and for its users.
This short explanation of the most useful way to think about what an “API product” is hopefully enough to get you started on your own API journey. If you want to learn more about API products, the intention behind them, and what treating them as products means in practice, check out this conversation with renowned API expert Mike Amundsen about API products:
If you liked this video, check out Erik’s YouTube channel for more “Getting APIs to Work” content.
If APIs are products, it follows that they need to be exposed for consumption. Learn what an API marketplace can do for your business in our new interactive eBook.