The “developers are the new customer” mantra seems nearly as old as time itself when it comes to API productization, but it is an incomplete perspective when dealing with enterprise-to-enterprise (“E2E”) paid access to APIs. Although API developers will remain an incredibly important audience to serve, they are typically not the buyers of your product in this scenario. Because of the historical effort traditionally focused on pleasing API developers, we have seen customers get confused about determining to whom their marketing efforts should be aimed in Enterprise API product sales. The best practice in Enterprise API sales is to ensure that significant effort is put into selling and marketing to the persona who is the buyer of your API product and not to the developers who will integrate your product.
The best practice in Enterprise API sales is to ensure that significant effort is put into selling and marketing to the persona who is the buyer of your API product and not to the developers who will integrate your product.
E2E API product launches should look a lot like any other software product launch, with the identification of your ideal customer profile (ICP) and the bulk of your sales & marketing efforts targeted at this persona and the problems your product solves for them.
However, the moment that you capture interest from an Enterprise customer and they send a developer to your portal, the quality of your documentation and API design is as important as it always has been when courting new developers to use a public API.
Lastly, in enterprise sales models, it is important that their initial experience logging into your development portal is as seamless as possible. If your company has already closed a sale with an Enterprise partner, the development portal should allow authenticated developers to see private API products purchased on their behalf as soon as they log in without any manual provisioning required so that they can get to work immediately.
Over the last 18 months, API monetization has increasingly become a business-led initiative supported by engineering, and not the reverse. In our opinion, this is a healthy evolution, as companies are now correctly viewing API-based products the same as any other software product launch, and supporting it similarly. In the past there was a tendency to believe in the ‘build it and they will come’ mentality for API-based products (more on that here), and this rarely turned out well.
For all of the reasons explained above, we’re big believers in business-led API product management at Revenium. For the sanity of your product-management teams and your engineering teams, API productization and API management should remain separate tasks, run by their respective teams of experts. We’ve seen the pain that occurs when every API business decision (i.e. change of marketing copy, change of desired packaging or pricing, etc.) must be implemented by the engineering team and recommend that whatever monetization solution you choose decouples API productization from API management.
It is quite common in large enterprises for multiple API gateways from multiple vendors to be in use. This raises several additional complications as it requires a marketplace/dev portal solution that can surface APIs from a variety of sources as well as a metering and monetization solution that is not tied to a single platform.
In these scenarios, very few API gateway solutions are cross-platform and Enterprises are forced to either consolidate all monetized APIs to a single platform (which is often expensive and time-consuming) or to consider a DIY solution for the portal & metering elements. The former approach is generally met with broad resistance from every internal developer not already using the chosen platform and the latter creates a significant amount of ongoing technical debt to maintain a self-developed platform.
We have seen a ‘roll your own’ metering & invoicing approach be successful when dealing with a very small and static number of integration partners, but beyond that use case, the cost of building and maintaining your own systems is likely to be far more than implementing a third-party solution.
Related to trend two above, historically, API monetization was a side project run with shadow budgets, and as a result, these projects were often immaterial to revenue. They also were capable of running in ‘manual mode’ (i.e. stitched together with duct tape and baling wire), with the side effect being that new partner integrations required months to stand up.
However, with the growing demand from enterprises for API-based products, these types of solutions are no longer adequate. Enterprises are quickly maturing their API products and supporting infrastructure to operate at scale and support significant revenue streams.
McKinsey recently reported that 1/3 of the banks they surveyed expected to increase total revenues by > 10% as a result of monetized API services.
In 2022, we saw large-scale API businesses born in many industries, but particularly in healthcare and financial services. There is also an incredible amount of funding going into API-first companies ($14B and counting according to GGV Capital’s API First Index), and these companies are increasingly encroaching on traditional Enterprises, forcing them to respond with API-centric products of their own.
And lastly... as this example from IMDb shows, there is massive value in offering programatic access to proprietary data.
The question I’ll leave you with is this… is the data inside your enterprise worth more or less than movie & television data from IMDb? Are you sitting on a potential goldmine?
