Ten years ago it was typical that only system architects uttered the phrase API. Since 2005 the programmable web has exploded from a handful of open APIs to thousands of companies exposing functionality for developers to harness. Firms like Salesforce and eBay enjoy more than half of all their transactions via their API while social networks such as Twitter experience well over 10bn API calls a day.

Exposing an API helps organisations deliver more functionality and achieve faster times to market. The API allows businesses to use the best of class existing services and focus on delivering customer value, for example catalog management, rating providers, shipping carrier integration, pricing engines, inventory systems, payment gateways, social integration, recommendations, image manipulation, video streaming, ticket booking, etc, etc.

The business benefits of building an API depend on context and focus but include…

  • Customer innovation,

  • partner network development,

  • increased sales conversions,

  • professional services revenues,

  • speed of development,

  • and user acquisition.

The business of APIs is huge and many successful multi million dollar firms do nothing but operate an API such as Twilio.

Probably because an API has no traditional user interface and is consumed by engineers many organisations make the enormous mistake of failing to invest in API product management. This results in API initiatives that deliver low or zero business value.

API product management has to focus on two key personas:

  • Engineer / Developer who will consume the API.

  • The users of apps the above engineers build.

Product managers need to fully appreciate the pain points the engineers face to consume the API. If the API uses unusual protocols or forces the engineer to ‘jump through hoops’ they are less likely to confirm to management that it is feasible to integrate your API.

If engineers inform their management your API is poorly designed and will take many man hours to integrate, management are more likely to de-prioritise the work or suggest the engineers look for an alternative. The engineers consuming the API are your key stakeholder and customer.

AuthorDave Martin