[The API Book] API as a Product
NB: This is two new chapters for the future Section III ‘The API Product’ of the API book I’m currently writing. I’d appreciate if you share it on reddit, for I personally can’t do that.
API as a Product
There are two important statements regarding APIs viewed as products.
- APIs are proper products, just like any other kind of software. You’re ‘selling’ them in the same manner, and all the principles of product management are fully applicable to them. It’s quite doubtful you would be able to develop APIs well unless you conducted proper market research, learned customers’ needs, and studied competitors, supply, and demand.
- Still, APIs are quite special products. You’re selling a possibility to make some actions programmatically by writing code, and this fact puts some restrictions on product management.
To properly develop the API product, you must be able to answer exactly this question: why your customers would prefer making some actions programmatically. It’s not an idle question: out of this book’s author’s experience, the product owners’ lack of expertise in working with APIs exactly is the largest problem of API product development.
End users don’t interact with your API directly but through the application built upon it by software engineers acting on behalf of some company (and sometimes there is more than one engineer in between you and an end user). From this point of view, the API’s target audience resembles a Maslow-like pyramid:
- users constitute the pyramid’s base; they look for the fulfillment of their needs and don’t think about technicalities;
- business owners form a middle level; they match users’ needs against technical capabilities declared by developers and build products;
- developers make up the pyramid’s apex; it is developers who work with APIs directly, and they decide which of the competing APIs to choose.
The obvious conclusion of this model is that you must advertise the advantages of your API to developers. They will select the technology, and business owners will translate the concept to end users. If former or acting developers manage the API product, they often tend to evaluate the API market competitiveness in this dimension only and mainly channel the product promotion efforts to the developers’ auditory.
‘Stop!’, the mindful reader must yell at this moment. The actual order of things is exactly the opposite:
- developers are normally a hired workforce implementing the tasks set by business owners (and even if a developer implements a project of his own, they still choose an API which fits the project best, thus being an employer of themselves);
- business leaders don’t set tasks out of their sense of style or code elegance; they need some functionality being implemented — one that is needed to solve their customers’ problems;
- finally, customers don’t care about the technical aspects of the solution; they choose the product they need and ask for some specific functionality being implemented.
So it turns out that customers are at the apex of the pyramid: it is customers you need to convince they need not any cup of coffee, but a cup of coffee brewed using our API (interesting question: how will we convey the knowledge which API works under the hood, and why customers should pay their money for it!); then business owners will set the task to integrate the API, and developers will have no other choice but to implement it (which, by the way, means that investing into API’s readability and consistency is not that important).
The truth, of course, lies somewhere in between. In some markets and subject areas, it is developers who make decisions (i.e. which framework to choose); in other markets and areas, it might be business owners or customers. It also depends on the competitiveness of the market: introducing a new frontend framework does not meet any resistance while developing, let’s say, a new mobile operating system requires million-dollar investments into promotions and strategic partnerships.
Here and after, we will describe some ‘averaged’ situation, meaning that all three pyramid levels are important: customers choosing the product which fits their needs best, business owners seeking quality guarantees and lower development costs, as well as software engineers caring about the API capabilities and the convenience of working with it.
API Business Models
Before we proceed to the API product management principles description, let us draw your attention to the issue of profits that companies providing APIs might extract from it. As we will demonstrate in the next chapters, this issue directly affects making product decisions and setting KPIs for the API team. [In brackets, we will provide examples of such models applicable to our coffee-machine API study.]
Developers = end users
The easiest and the most understandable case is that of providing a service for developers, with no end users involved. First of all, we talk about different software engineering tools: APIs of programming languages, frameworks, operating systems, UI libraries, game engines, etc; in other words, general-purpose interfaces. [In our coffee API case it means the following: we’ve developed a library for ordering a cup of coffee, possibly furnished with UI components, and now selling it to coffeeshop chains owners whoever willing to buy it to ease the development of their own applications.] In this case, the answer to the ‘why have an API’ question is self-evident.
There is also a plethora of monetizing techniques; in fact, we’re just talking about monetizing software for developers.
- The framework / library / platform might be paid per se, e.g. distributed under a commercial license. Nowadays such models are becoming less and less popular with the rise of free and open source software but are still quite common.
- The API may be licensed under an open license with some restrictions that might be lifted by buying an extended license. It might be either functional limitations (an inability to publish the app in the app store or an incapacity to build the app in the production mode) or usage restrictions (for example, an open license might be ‘contagious’, e.g. require publishing the derived code under the same license, or using the API for some purposes might be prohibited).
- The API itself might be free, but the developer company might provide additional paid services (for example, consulting or integrating ones), or just sell the extended technical support.
- The API development might be sponsored (explicitly or implicitly) by the platform or operating system owners [in our coffee case — by the smart coffee machines vendors] who are interested in providing a wide range of convenient tools for developers to work with the platform.
- Finally, the API developer company might be attracting attention to other related programming tools and hoping to increase sales by publishing the API under a free license.
Remarkably, such APIs are probably the only ‘pure’ case when developers choose the solution solely because of its clean design, elaborate documentation, thought-out use-cases, etc. There are examples of copying the API design (which is the sincerest form of flattery, as we all know!) by other companies or even enthusiastic communities — that happened, for example, with the Java language API (an alternate implementation by Google) and the C# one (the Mono project) — or just borrowing apt solutions — as it happened with the concept of selecting DOM elements with CSS selectors, initially implemented in the cssQuery project, then adopted by jQuery, and after the latter became popular, incorporated as a part of the DOM standard itself.
API = the main and/or the only mean of accessing the service
This case is close to the previous one as developers again, not end users, are API consumers. The difference is that the API is not a product per se, but the service exposed via the API is. The purest examples are cloud platforms APIs like Amazon AWS or Braintree API. Some operations are possible through end-user interfaces, but generally speaking, the services are useless without APIs. [In our coffee example, imagine we are an operator of ‘cloud’ coffee machines equipped with drone-powered delivery, and the API is the only mean of making an order.]
Usually, customers pay for the service usage, not for the API itself, though frequently the tariffs depend on the number of API calls.
API = a partner program
Many commercial services provide the access to their platforms for third-party developers to increase sales or attract additional audiences. Examples include the Google Books partner program, Skyscanner Travel APIs, and Uber API. [In our case study, it might be the following model: we are a large chain of coffeeshops, and we encourage partners to sell our coffee through their websites or applications.] Such partnerships are fully commercial: partners monetize their own audience, and the API provider company yearns to get access to extended auditory and additional advertisement channels. As a rule, the API provider company pays for users reaching target goals and sets requirements for the integration performance level (for example, in a form of a minimum acceptable click-target ratio) to avoid misusing the API.
API = additional access to the service
If a company possesses some unique expertise, usually in a form of some dataset that couldn’t be easily gathered if needed, quite logically a demand for the API exposing this expertise arises. The most classical examples of such APIs are cartographical APIs: collecting detailed and precise geodata and maintaining its freshness is extremely expensive, and a wide range of services would become much more useful if they featured an integrated map. [Our coffee example hardly matches this pattern as the data we accumulate — coffee machines locations, beverages types — is something useless in any other context but ordering a cup of coffee.]
This case is the most interesting one from the API developers’ point of view as the existence of the API does really serve as a multiplier to the opportunities: the expertise owner could not physically develop all imaginable services utilizing the expertise. Providing the API is a win-win: third-party services got their functionality improved, and the API provider got some profits.
Access to the API might be unconditionally paid. However, hybrid models are more common: the API is free till some conditions are met, such as usage limits or constraints (for example, only non-commercial projects are allowed). Sometimes the API is provided for free with minimal restrictions to popularize the platform (for example, Apple Maps).
B2B services are a special case. As B2B Service providers benefit from offering diverse capabilities to partners, and conversely partners often require maximum flexibility to cover their specific needs, providing an API might be the optimal solution for both. Large companies have their own IT departments are more frequently need APIs to connect to their internal systems and integrate into business processes. Also, the API provider company itself might play the role of such a B2B customer if its own products are built on top of the API, and external API exists merely as a byproduct of the internal one.
API = an advertisment site
In this case, we talk mostly about widgets and search engines; to display commercials direct access to end users is a must. The most typical examples of such APIs are advertisement networks APIs. However, mixed approaches do exist either — meaning that some API, usually a searching one, goes with commercial incuts. [In our cofee example, it means that offers searching function will start promoting paid results on the search results page.]
API = self-advertisement and self-PR
If an API has neither explicit nor implicit monetization, it might still generate some income, increasing the company’s brand awareness through displaying logos and other recognizable elements while working with the API, either native (if the API goes with UI elements) or agreed-upon ones (if partners are obliged to embed specifical branding in those places where the API functionality is used or the data acquired through API is displayed). The API provider company’s goals in this case are either attracting users to the company’s services or just increasing brand awareness in general. [In case of our coffee API — let’s imagine that we’re providing some totally unrelated service, let’s say, selling tyres, and through providing the API we hope to increase the brand recognition and get a reputation as an IT-company.]
The target audiences of such self-promotion might also differ:
- you might seek to increase the brand awareness among end users (by embedding logos and links to your services on partner’s websites and applications), and even build the brand exclusively through such integrations [for example, if our coffee API provides coffeeshop ratings, and we’re working hard on making consumers demand the coffeeshops to publish the ratings];
- you might concentrate efforts on increasing awareness among business owners [for example, for partners integrating coffee ordering widget on their websites to also pay attention to your tyres catalogue];
- finally, you might provide APIs only to make developers know your company’s name to increase their knowledge of your other products or just to improve your reputation as an employer (this activity is sometimes called ‘tech-PR’).
Additionally, we might talk about forming a community, e.g. the network of developers (or customers, or business owners) who are loyal to the product. The benefits of having such a community might be substantial: lowering the technical support costs, getting a convenient channel for publishing announcements regarding new services and new releases, and obtaining beta users for upcoming products.
API = a feedback and UGC tool
If a company possesses some big data, it might be useful to provide a public API for users to make corrections in the data or otherwise get involved in working with it. For example, cartographical API providers usually allow to post feedback or correct a mistake right on partners’ websites and applications. [In case of our coffee API we might be collecting feedback to improve the service, both passively through building coffeeshops ratings or actively through contacting business owners to convey users’ requests or through finding new coffeeshops that are still not integrated with the platform.]
Finally, the most altruistic approach to API product development is providing it free of charge (or as an open source and open data project) just to change the landscape. If today nobody’s willing to pay for the API, we might invest in popularizing the functionality hoping to find commercial niches later (in any of the abovementioned formats) or to increase the significance and usefulness of the API integrations for end users (and therefore the readiness of the partners to pay for the API). [In case of our cofee example — imagine a coffee machines maker starts providing APIs for free aiming to make having an API a ‘must’ for every coffee machine vendor thus allowing for developing commerical API-based services in the future.]
One additional source of income for the API provider is the analysis of the requests that end users make. In other words — collecting and re-selling some user data. You must be aware that the difference between acceptable data collecting (such as aggregating search requests to understand trends or finding promising locations for opening a coffee shop) and unacceptable ones are quite vague, and tends to vary in time and space (e.g. some actions might be totally legal at the one side of the state border, and totally illegal at the other side), so making a decision of monetizing the API with it should be carried out with extreme caution.
The API-first approach
Last several years we see the trend of providing some functionality as an API (e.g. as a product for developers) instead of developing the service for end users. This approach, dubbed ‘API-first’, reflects the growing specialization in the IT world: developing APIs becomes a separate area of expertise that business is ready to out-source instead of spending resources to develop internal APIs for the applications by in-house IT department. However, this approach is not universally accepted (yet), and you should keep in mind the factors that affect the decision of launching a service in the API-first paradigm.
- The target market must be sufficiently heated up: there must be companies there that possess enough resources to develop services atop third-party APIs and pay for it (unless your aim is terraforming).
- The quality of the service must not suffer if the service is provided only through the API.
- You must really possess the expertise in API development; otherwise, there are high chances to make too many design mistakes.
Sometimes providing APIs is a method to ‘probe the ground’, e.g. to evaluate the market and decide whether it’s worth having a full-scale user service there. (We rather condemn this practice as it inevitably leads to discontinuing the API or limiting its functionality, either because the market turns out to be not so profitable as expected, or because the API eventually becomes a competitor to the main service.)