API Business Models
APIs provide our company possibilities to improve, change or add to our current business models. APIs can provide a way to create an internal and/or external platform and promote re-using, sharing and network business models.
Business model describes how our company (or a specific business unit) creates, delivers and captures value.
Our IT as internal API platform provider, our business units as the API value proposition developers
We improve our internal efficiency with APIs. Goal is to use APIs in our internal applications, analytics applications or home grown mobile apps.
By using APIs internally, we aim to support our current and future business models with faster delivery time and new techonology.
While APIs get their data and some of they functionality from existing business applications, we aim to create an independent API layer (“platform”) on top of those systems for
- improved consistency between data models and functions
- to enable transition of existing systems to new systems without disrupting API consumers and
- to leverage using cloud and modern implemantation technologies
Business units or those IT teams more in closest contact with business are responsible for defining the value propositions for each API and endpoint.
Our company as API provider
By creating APIs (being an API provider), our company is able to deliver value to our customers and partners. Because of this APIs need to be thought of as products and they need to be designed and split according to what value propositions they offer.
Each API and each endpoint should be evaluated and designed base on:
- what data or functionality is our customer willing to pay for and what will make them more committed to engage with us and co-create with us
- what data or functionality should we expose to our partners, so they will engage with us more efficiently and be able to support us and our customers in a better way
- what is the data or functionality which is most needed by our customers and partners or our own service development? Which of those needs are easiest to implement and contains lowest amount of risk but highest amount of potential
In broadest sense value proposition can be described as a formula where Value = Benefits - Cost (cost includes economic risk). Developing a value proposition is based on a review and analysis of the benefits, costs and value that our company can deliver to its customers, prospective customers and other members of our company’s network and within our company.
As we are treating our APIs as digital products which can be bought, sold and shared we use this product management opportunity assesment list as a tool when making decisions on which APIs to launch, to whom and with which data/functionality and which business model.
Assessing API opportunities:
- Exactly what problem will this API or endpoint solve? (value proposition)
- For whom do we solve that problem? (target market)
- How big is the opportunity? (market size)
- What alternatives are out there? (competitive landscape)
- Why are we best suited to pursue this? (our differentiator)
- Why now? (market window)
- How will we get this API product to market? (go-to-market strategy)
- How will we measure success/make money from this product? (metrics/revenue strategy)
- What factors are critical to success? (solution requirements)
- Given the above, what’s the recommendation? (go or no-go)
_By Marty Cagan, Silicon Valley and MindTheProduct -network guru of product management — Taken from: http://svpg.com/assessing-product-opportunities/
APIs as business development and innovation enabler
It’s possible that APIs even allow our API consumers to create new innovations using your APIs. It’s important to think and prepare on who, how and under what conditions is allowed to do so and how is the value measured and distributed between you and the external innovators. It’s also critical to understand that it’s not just a relationship based on exchange of money, but also experience, customers and possibly physical and data assets. So it needs to be managed, but not too managed to attract interest.
Creating customer value and reducing costs by being an API consumer
Our company may also act as an API consumer.
Typical API business models we use for opportunity assessment
|Internal cost optimization||Indirect value||Additional sales||API consumer pays||API consumer is paid|
|Restricted free use "Freemium" model or for specific partner uses||APIs are included in the premium product/service packages or offered free for key customers||Pay-per-use or according to added value||Revenue sharing, %-based partnership|
|Typical API consumers = Developer community||Internal consumers: Analytics platforms, CRM/ERP and other business applications, Digital services||
For example startups or educational organizations can belong to this category before becoming actual reselling or innovation partners
|Innovation partners, customers, partners||
Customers to whom we offer APIs as our main products
|Innovation partners, resellers, supply chain partners|
APIs can be divided to public, private and partner APIs based on their usage.
- Private APIs are allowed to be used only by own applications. They contain attributes and data which is business critical and confidential.
- Partner APIs are available for third party organizations upon approval of partnership terms and conditions. Partner APIs may contain partner specific or customer data which is not available for general public. Partner is liable for the use of the data according to terms and conditions. Partner maybe required to restrict the access of their end-users to the data. F.eg. Partner may access detailed price and purchase data of all stores, but each retailer using partner’s application can only access data of their own store.