API Economics: Create More Value than you Capture

A while back, Tim O’Reilly posted an inspiring slideshare presentation on measuring the economic impact of sharing [embedded below] – some of the content has been posted before but it’s a great reminder of what we see as one of the core principles behind APIs:

Create more Value than you Capture!

In other words – make the API such that there is benefit for others to use – perhaps even vastly more benefit than there is for yourself. Breaking it down, there are really two parts of the statement:

1. Create Value.

2. Do not attempt to capture all the value you create.

The first is obviously important. An API which does not enable its users to do anything valuable will not be used (we covered this at the beginning in our Great API’s series). The second part however, may be less clear and is easily lost in discussions such as: Is our API a cost center? Or a revenue generator? Or What business model is appropriate?

Capturing less value than is created simply means leaving enough value on the table for the customers, partners and developers using the API. Essentially, allowing them to capture it instead of you. Failure to do this will make the API as useless an API that has no intrinsic value and it’s easily done for example by:

• Using terms of service to restrict API usage in such a way that all the significant economic opportunities are off the table for third parties.

• Charging high fees for the API – so high that there is no resulting viable business model for users of the API (i.e. the value they are able to create is all pulled back in terms of fees).

The general scheme is shown in the figure below. The ability for third parties to generate some value they can capture themselves is crucial for adoption of the API. Over time, this then grows the ecosystem and hence augments the API owners overall benefit from the API.

The fact that people are able to generate and keep some of the value is really the engine that drives adoption and take up.

Altruism or Sound Business Strategy?

If this post seems like a call to Altruism, it certainly isn’t – although we should all be greatful for the many open public APIs there are which create huge value and should get our support! The thoughts in this post really apply to any type of API: whether publicly funded or commercial.

The idea is really simple business 101 and obvious anywhere in the general economy. For example:

• Mobile Telephone Service: communication with this medium is priced on a per-minute or per message basis – independently of the value of the messages/communications actually carried out. Hence it costs the same to make a 1hr call to a large customer to negotiate a million dollar deal as it does to call to a family member. The value the user of the service is able to generate is much greater than the cost of the service – hence their continued willingness to pay.

• Merchant Payment Services: Online payment services solve the “complicated bits” of taking credit card payments online and charge a small service fee per transaction. This enables their customers to run their business and forms part of the ability to create value, but itself has a fixed predictable cost (in this case scaling with actual revenue).

Similar arguments can be made pretty much anywhere where you can make an ROI calculation. The models in the two examples are slightly different: in the former there is no real coupling between the value generated and the cost of the service, in the later there is some – but it’s low (and generally decreases by volume). Further, it may even be that that family member phone call is more value than the business deal – there is really no way to know up front.

Great APIs get this right also – one of our customers, JCI for example recently launched their Panoptix API and right out of the gate added the ability for third party developers to showcase, promote and get paid for their valuable applications. This shows how a platform sets out to not just provide a base service – but promote value creation for its users.

The Success Tax

An interesting thread on branch recently discussed the notion of a “Success Tax” that developers sometimes perceive they will be paying when using pay-as-you-go cloud services. The original discussion centered upon Mobile Platform as a Service Offerings, but the argument is potentially broader.

This phenomenon kicks in when users of an API (or other) service perceive that the more value they create, the more they have to pay the provider of their backend services. The perception is essentially the reverse of the positive view of “it cost me nothing to get started and my costs scale with volume – great, no up-front costs”. Getting the value v’s capture ratio and structure wrong can quickly lead to this negative perception. In particular, it is likely important to try to balance the following elements:

• Relatively low on-boarding costs: so people can see success quickly without taking a large upfront risk.

• Progressive pricing or value capture that scales up with “success”.

• But where the proportion of value captured by the API/Platform either stays static or decreases with “success” – e.g. pricing gets cheaper with volume.

These combinations may not be appropriate for all business (sometimes high on-boarding costs are real costs for example), however in general the “success tax” effect really kicks in if users of the API can see that once they reach some kind of ceiling, their costs on the API will jump significantly in proportion to the value they can capture. (The danger is that at this point users will switch APIs/platforms) – progressive sharing success is good for everybody.

Obviously costs from increased volume on an API have to be paid for – so the structure has to be right going in: users need to be able to generate enough value of the top such that volume usage doesn’t put the provider out of business.

Bait and Switch

Another unfortunate effect that can arise as the value created by an API rises, is the temptation to change the rules to capture significantly more of it – or, simply be vague about what value will go to whom. In many ways the recent platform woes seen at Facebook, Twitter, LinkedIn and elsewhere are precisely effects of this: a API provider significantly changing the slice of the pie it wishes to keep for itself.

While sometimes unavoidable, this kind of change risks wholesale mistrust within the ecosystem. Part of allowing third parties to create and capture significant amounts of the own value is projecting the stability of their ability to do so. Creating risk by land-grabbing value makes it a poor business decision for third parties to play in the ecosystem.

What about cost?

While all of the above is true, the diagram shown earlier is an oversimplification since it omits the fact that there is a cost to running an API. Whether the API is running on a Mac-Mini in someone’s basement, or a global array of custom hardaware with multiple layers of SLAs and failover, it has a cost. This is one of the reasons that, while interesting, we see the recent calls for some APIs to have “heritage status” as rather unrealistic. However minimal, APIs must be operated and maintained – and therefore financed. In the broader context the API value graph looks a little more like the next chart:

As an API owner it is very natural to focus on the lower parts of the curve – how do I cover my costs, make this pay and get value back? However when planning, it is crucial to think about the upper blue part of the curve – what value is being created that is available for others? The value in either case may not be in dollars/direct sales but as part of a wider business strategy but it needs to be possible to perceive and assess this value.

Questions

Given these tradeoffs, some natural questions arise for API Owners:

• What if I can’t generate enough value for API users?: it’s probably time to go back to the drawing board on the API. If there isn’t enough of a benefit to using the API, it’s likely something is wrong and more thought is needed. Perhaps the potential audience for the API is not there? perhaps what the API does is too limited to “close the loop” on transactions and hence little value can be created.

• How much value is it ok to keep?: there is no universal answer to this, but it’s likely useful to focus first and foremost on whether the value available to users is sufficient for them to be incented to us it and what values a “fair” in order to build a strong relationship with the user population.

• But we’re not charging for the API – how do we capture our part of the value?: charging for API usage is only one way of capturing value – you may get intrinsic benefit in all sorts of other ways such as reducing customer churn (SAAS businesses), driving sales (if the API allows transactions), distribution (if the API promotes other parts of your service etc.) and it is valuable to quantify this benefit.

• What is the value captured by others is so large our company we end up only capturing a tiny fraction?: this is a great situation to be in but can create tension and instability. The ability to shift pricing rules in the favor of capturing more value really depends on market norms, alternatives available and how the API is being used and so forth. The golden rules really are – making sure the API still remains a profitable place for users to be whilst also ensuring enough revenue is captured to make it a viable business. In doing this however – beware the dangers of being perceived as carrying out a “bait and switch” (see above) – nothing upsets API users more than being led on and having significant businesses made non-viable. On the other hand those same users will understand your platform needs to be sustainable, so there will typically be openness to change if it is well communicated and consultative.

• As a non-profit / government API our job is create value for others – but what happens if success drives us into the ground?: government and public APIs often drive huge value (think map data, census data etc.) but as they succeed infrastructure costs can skyrocket. In part this is a decision on how much society wants to put in to fund such data/API commons, but also for each individual API important decisions may be taken on how management is done. Would rate limits help ensure developers write more efficient code? should very high volume users (who are clearly deriving high levels of value) pay to contribute to API maintenance? would a donation system work etc.? In each case, the answer may be different – but even for public APIs it may make sense to capture some of the value of the API to put back into maintenance.

The good news is that APIs are in general amazing value generators – and often in many unexpected ways. So they provide a clear opportunity to grow what a business can offer into segments and niches that would otherwise be simply unreachable. To do that, thinking about the value that’s created in the world at large before what is captured is very likely a good way to approach the problem!

Have a Happy 2013!

Tim O’Reilly’s Presentation

Image