An API Product Manager has a number of responsibilities that bridge the gap between the business and technology, a fact we discussed in our post on developer experience. One role critical to the success of an organization’s API program is defining business value. This role has two aspects:
- Defining the monetary value of your API
- Qualifying how your API delivers value from a product perspective
If an API Product Manager fails to define these areas successfully using terms the business will understand, then their organization will lack appreciation of what the API brings, both financially and as a proposition.
Defining Monetary Value
The growth of the API economy had been diverse. Countless industries and sectors have been touched by the increasing number of API providers and the products they offer. The motivation for providing an API varies hugely, for some providers an API is a technical means to a technical end, for others it’s the the cornerstone of their product and the main channel for serving their customers.
From the perspective of monetary value these two cases are at opposite ends of a continuum. The continuum defines how readily the explicit monetary value of an API can be quantified.
At one end there are technically-focused and private API where monetary value lies in the “stack” the API is part of rather than the API itself. The value of the API at this end of the continuum is almost intangible.
At the other end are product-focused, per-click or subscription-based APIs. The monetary value is explicit, with consumers being charged to use the API. Calculating the return on providing the API should be more “obvious”. Stripe provides a good example of such an API, with a flat rate fee per transaction that can be mapped neatly to API calls.
In middle are public, free-to-use APIs that are not the main channel for an organization’s product but help drive consumers to it by offering flexibility and choice in how the product is consumed. eBay provides an example of such an API. eBay does not charge for API usage but offers a way for developers to create create applications that use their platform. The net effect is to drive up the volume of sales and therefore selling fees.
Clearly there is a variety of ways that these delivery models earns revenue for an API provider. An API Product Manager must therefore ensure they use the correct means to show the business the monetary value of their APIs. Traditional finance measures like return on investment are always compelling tools as they are a language the business understands. If this can be broken down to discrete measures, such as revenue per API call or per transaction executed as a result of a call to the API then it becomes easy to extrapolate. API Product Managers can then help the business forecast on future growth of the API by having a good understanding of the current value.
However, API product managers should also understand that sometimes underplaying the role of an API is crucial to remaining autonomous. If monetary value really does lie in the stack – and the the value to the business is how this stack is manifested, whether through a mobile app or any other point of consumption – then feel free to let your API be part of the stack. Surfacing an element of a technical architecture to a non-technical audience who do not understand its significance can result in unwanted or unwarranted scrutiny that is time-consuming and invasive.
The time to bring APIs that support the “stack” into the spotlight is when a significant opportunity presents itself to make a private API available to external consumers. When this happens, do your homework and calculate the monetary value in readiness for taking a persuasive argument to your business stakeholders.
Defining Product Value
Justifying the value of an API as a product is undoubtedly easier to accomplish than the monetary value. An API Product Manager needs to rely on less quantifiable evidence and can be empirical in their approach to defining how an API fits an organization’s product offering. Qualifying API product value is similar to monetary value on that it sits on a continuum of organization types that characterises how the organization focuses or fixates on the API. For example:
At one end of the continuum are API-first providers, who do APIs and nothing else. For API-first providers no API means no product and for them “the API is down” is an absolute catastrophe.
Diametrically opposed to these are API-last providers who had a portfolio of products long before APIs came along and do not rely on them as their main revenue stream. Such a provider may have a many APIs, but as already discussed they are a technical convenience for powering offerings like mobile apps.
Somewhere in the middle are the organizations that are embracing the API economy by becoming API providers, placing importance on their burgeoning suite of APIs whilst still thriving on their existing business. Visa provides a good example of such a provider, with a large suite of APIs that are a complement to their core authorization platform.
At the heart of any API is a compelling product that attracts consumers – regardless of where an API provider sits on the continuum. An API Product Manager must show the business how the API supports the organization’s product offering. For API-first providers this is a given – the API and the product are intrinsically linked – but this is more difficult for organizations that tend towards the API-last model.
If an organization cannot be classified as API-first proving business value often takes the form of a fashion parade which aims to define “what good looks like”. The API economy is becoming an arms race of organizations in the same sector each with competing API offerings. An API Product Manager must therefore be acutely aware of the competition. They need to use them as an example to show the business where their industry is going and what the business needs to do to stay competitive. APIs in this context can be used as a tool to enhance reputation or outdo the competition.