API Academy

Sponsored by Layer7

API Strategy 301: API-as-a-Product

By Matt McLartyPosted on

Learn how positioning your APIs as products can contribute to success across all aspects of an API program

In API Strategy Lesson 203: Building Business Value with a Framework for API Success, we outline key areas of focus essential to designing and maintaining an effective API program. In this lesson, we explain how positioning your APIs as products in themselves can contribute to success across all business and technical aspects of an enterprise API program.  

API-related activity has grown significantly since the iPhone’s 2007 launch began the app era. Recently, this growth has been boosted further by the emerging Internet of Things (IoT). While earlier Web-based services were seen as infrastructural concerns and managed by IT teams, today’s leading APIs are managed by product teams as commodities in and of themselves.

APIs fit the standard definition of a product well: there is a demand for them, they have customers – app developers – and they can be monetized. But like any product, an API cannot be successful if its target audience is not aware of it. By applying product management best practices to your APIs, you can increase awareness in order to generate real business value.

To successfully position your APIs as products, you should adhere to three basic principles:

  • Be customer-centric
  • Assume every API may become an open API
  • Leverage Your APIs strategically —

Be Customer-Centric A mistake commonly made by API architects is focusing on data rather than customers. Too often, APIs are created as generic query interfaces to data sets, without much thought for how the data might serve the needs of consuming developers. Instead, architects should focus on their target developer’s problems and on providing products that help solve those problems.

User interface expert Jared Spool has identified a number of ways organizations make product design decisions, which can be ranked in order of maturity. By applying these concepts to the specific example of APIs, we have created the API Design Maturity Pyramid, pictured below. This model will help you assess how well your API’s design meets the needs of its audience.

The API Design Maturity Pyramid outlines the way an API provider might typically move through four levels of API design maturity:

  • Unintentional design This is where most API developers start when they are looking for the quickest way to expose a data set. The data is deposited somewhere just so users can get access to it but no real thought is given to design.
  • Automated design Once an API designer starts creating tooling to connect with a data source, there is some form of API design and some best practices are used. However, the design does not take into account the specific needs of the developers who will use the resulting interface.
  • Self design Next, the designer starts to take account of how the API may actually be used. But the designer’s decisions about how to meet user needs are made entirely according to their own preferences, rather than being based on input from developers.
  • Activity-focused design Finally, the designer arrives at an approach conforming to the advice of product and user experience experts. Target developers are interviewed, to discover the problems they have. Then an API is designed specifically to help them solve these problems. —

Assume Any API May Become Public One of the key factors that will affect your API business strategy is the distinction between private, partner and open APIs. A detailed exploration of this distinction is provided in API Strategy Lesson 201: Private APIs vs. Open APIs. But for the purposes of this lesson, here is a quick summary:

  • Private APIs Typically, private APIs are created to facilitate integration among internal systems or enable internal developers to create new applications and services. With private APIs, it is relatively easy to control how the interfaces are used.
  • Partner APIs Partner APIs facilitate integration between an organization and its business partners. This makes it somewhat harder to control how the APIs are used but there is generally some alignment between the agendas of the organizations involved.
  • Open APIs Public or open APIs are created in order to give a wider population of developers access to an organization’s information assets. Because the interfaces are available to the public, it is much harder to control how developers use them.

Some companies try to save time and resources by skipping considerations like usability and security when creating private or partner APIs. This is an inherently bad idea – these are vital aspects of every API program – and can also make it difficult to transition into an open API model, where the impact of ignoring these considerations will be significantly greater.

Many of today’s most successful APIs started out private but became so valuable that their owners decided to open them up to external developers and charge these developers for access. So, if you are building a private API without making it simple to transform that API into a public product with its own revenue stream, you may be leaving money on the table.

Leverage Your APIs Strategically There are four main product management strategies for API programs.

  1. Platform thinking Offering APIs makes it possible to productize your backend systems as a platform upon which other organizations can build new applications. Organizations that come to rely on this product will be invested in its success. Therefore, your API program will be backed by the cumulative development, sales and marketing resources of everyone on your platform.
  2. Monetizing existing assets An API can be a significant multiplier of return on investment for your existing technology investments. By enabling you to share, rent out or repurpose under-utilized resources – for example, by offering an infrastructure-as-a-service (IaaS) product – APIs can empower you to monetize assets that might otherwise have been sitting idle.
  3. Composability From a technical perspective, API architecture makes it possible to offer technology products as open systems instead of inflexible off-the-shelf solutions. An API consumer can use your resources to compose a solution that suits their business requirements and workflows rather than adapting their business processes to the limitations of your solution.
  4. Unbundling The phrase “unbundling†means the process of breaking something apart into its composite parts. Venture capitalist Marc Andreessen has pointed out that the history of the consumer Internet is a perfect example of unbundling. AOL included a portal and connection to the Internet. Yahoo unbundled the portal, Google unbundled search from the portal and so on.

Unbundling is not the same as decoupling applications from the backend systems that power them (an essential aspect of API architecture). It is about identifying small feature sets in big products and isolating them, to focus on creating innovation. The liberation of the small from the big in the service of innovation is much more important than the technical decoupling.

Any company with a feature rich technology product is in danger of having competitors unbundle one of its key features in order to create a more focused and innovative competing product. By using APIs to unbundle your own functionality, you can beat them to the punch and benefit from whatever new innovations they build upon your platform.