[The API Book] API as a Product

API as a Product

  1. 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.
  2. 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.
  • 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.
  • 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.

API Business Models

Developers = end users

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. 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.

API = the main and/or the only mean of accessing the service

API = a partner program

API = additional access to the service

API = an advertisment site

API = self-advertisement and self-PR

  • 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’).

API = a feedback and UGC tool


Gray zones

The API-first approach

  1. 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).
  2. The quality of the service must not suffer if the service is provided only through the API.
  3. You must really possess the expertise in API development; otherwise, there are high chances to make too many design mistakes.




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Static Libraries vs Dynamic Libraries

Shared (dynamic) Libraries vs. Static Libraries —Differences in  performance. | LaptrinhX

Automating Instagram with Python

Forking a GitHub Repository using Git and VIM

Assembly “wrapping”: a new technique for anti-disassembly

New in Basecamp: See where projects really stand with the Hill Chart

Implementing MVVM in Android with Jetpack and Dependency Injection — Part 1

Web scraping Using Python Programming | IMDb Rating

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sergey Konstantinov

Sergey Konstantinov

The API Guy

More from Medium

The Time Traveler’s Guide to Easy Product Notifications

One More Framework to Evaluate Businesses

Three eCommerce Business Models that Trends in the Retail sector

Three eCommerce Business Models that Trends in the Retail sector

Product Manager tool: Product Requirements Document