API Monetization: Enterprise Quick Start Guide
Enterprises in all industries are experimenting with API monetization to enter new markets and respond to customer attrition to new API-first competitors. Learn where to look internally to quickly find your first opportunity to launch your own API-based product.
In consultation with our clients, one of the most common questions is how to identify and prioritize opportunities for direct external API productization (and, ultimately, monetization). It is also quite common that projects like this remain deprioritized on the backlog because they lack a plan for getting started.
The problem with this strategy is that not every company is leaving it on the backlog! We frequently see how API-only product offerings from new market entrants are disrupting traditional businesses. This leaves traditional enterprises having to play catchup to ensure they remain competitive and retain their existing customers. Below are a few of the most common areas to investigate to jump-start your plans for API productization & monetization.
First, Look Internally (it’s easier):
As any product manager knows, customers surface their complaints or desires to all areas of the organization, and it is no different from the case for API monetization.
In our experience, outside of product management, your sales, customer success, and customer support teams will be the top internal indicators as to whether there is an opportunity for API monetization in your business.
However, it’s important to phrase your questions to these teams broadly to ensure you expose API-centric opportunities even if the customer has never said, “I could really use an API to solve this problem.” (if only life were so easy!)
Below is a short list of questions that will uncover and guide opportunities as well as real-world examples we’ve run into that will help provide more context to the opportunities these questions help to uncover.
Q1: Have customers asked us if there is a way for us to export our data into a different system they use as a part of their regular workflow?
- As an example, banks often exchange de-identified customer information with outside parties for various purposes using batch file processing.
- Instead of batch processing, a well-designed API can drastically reduce the time & cost required to exchange data required via batch processing.
Q2 & Q3: Have customers asked us to sell a single part of our overall solution on its own? Have we lost customers to competitors selling cheaper/simpler versions of our product?
- This one comes up quite frequently when enterprises sell monolithic and expensive solutions catering to a broad set of customer requirements. When new competitors emerge and start selling one part of the product suite, often as an API, at a vastly reduced price (compared to the entire suite), existing customers who do not need the entire solution will put pressure on sales teams to come up with a similar offer. In this case, enterprises have to choose between retaining the customer at a smaller revenue or losing them completely.
- Offering individual components of the monolithic legacy offer as an API-centric solution are a common solution to this problem. This allows you to retain your margins and pricing for the traditional product suite and to retain (and grow!) the market segment of users with higher price sensitivity and more narrow use cases.
Q4: Do you have open or free APIs published today and do you know they are being used?
One of the first pieces of advice we generally offer to clients considering releasing external APIs (even if free) is to do so only within some set of usage constraints.
- Placing constraints on your free API usage allows you to assess existing demand and determine whether there is a future opportunity to monetize a higher-usage tier or a higher-performance tier (or many other variables you can tweak to turn free usage into paid usage).
- Unfortunately, many clients release APIs without constraints, which makes future efforts to add paid tiers to your API much more difficult. With that said, even if you find yourself in this situation, it is critical for product managers to evaluate the usage of these free APIs to understand if there are monetization opportunities within your existing APIs and customers.
- Lastly, even though it is more difficult to implement constraints after your APIs are broadly used, we still recommend you do so. To avoid disrupting existing clients, you can consider grandfathering older clients a non-constrained usage policy or providing a very long transition period for them from unconstrained to constrained usage to give your CS team time to make the transition with customers.
So what happens if you’ve checked all of these sources and turned up nothing? Two possibilities exist: 1) there truly is no opportunity among your current customers to release API-based products, or 2) you have a chance to be first and be the disruptor in your space as opposed to being disrupted.
Lastly, if you have already identified an opportunity, this article discusses how to get your monetized API to market as quickly and as low-risk as possible.
Unfortunately, we tend to deal with more clients operating off their back foot (i.e., losing business to API-first competitors) than the front foot (being first to market) because this type of disruption occurs across industries. However, if you are lucky enough to have the first-mover advantage still, we recommend you capitalize on this as quickly as possible.