Is there room for API products in your business model?

Have you ever spoken or heard these words: "We can't talk about API products because we are not selling APIs, we are selling our real products" or "How can we monetize our APIs?"

Marjukka Niinioja

Founding partner

These common lines inspired me to open up some examples on how to think differently on both your APIs and your products. Some of my recent clients have been from industrial or other “hardware” segments, where they typically produce and sell physical products. So my examples are from the world of fire alarms but can be applied to almost any industry with products or services other than software or APIs.

Are we selling fire alarm products or API products?

From the product strategy point of view, keeping the "hardware product" like fire alarms, as an example, and API product decisions separate is usually a good idea.

One hardware product may include many API products.
One API product can be used with many hardware products, depending on the value proposition.

Recently, one client in a big global hardware product company asked me a very good question after a conversation on two topics. First, the differences in API products between partner segments. Second, understanding the partners’ journeys and their business and operational needs.

Then the client asked a question.

“But what is the difference between these segments from an API point of view if we still have the same physical product?”

Excellent question, and one that does not necessarily have a clear cut answer.

Take a look at the world of fire alarm systems to find some answers to the previous questions. Fire alarms can be installed in single apartments, apartment buildings, commercial buildings and some critical facilities like hospitals or data centres. These are all examples of client segments. The companies managing these facilities are one partner segment. Installation and maintenance companies are examples of other partner segments.

What difference do your partners make for your API products?

Differences can be seen in many areas relating to the business model and to the creation and management of API products. I use the term productizing or more academically productization*) of APIs. I’m using this term to describe taking something abstract like an API and applying product principles to it. This does not mean that an API product is marketed to the general public or even outside the company. But still, similar principles apply.

Investopedia defines productization as "the process of developing or altering a process, idea, skill, or service to make it marketable for sale to the public". The definition goes on: "Productization involves taking a skill or service that has been used internally and developing it into a standard, fully-tested, packaged, and marketed product."

Enterprise architects like to use the word capability to describe this kind of technical “skill or service”, in our case the API. The term productization is related to the term servitization. In a manufacturing product business, the trend to "servitize" the product has been around for many years to stay in the market. Meaning that additional services have been designed to support, for example, machinery (the core product) sales.

The point of both productization and servitization is to extend the original offering and to make it more concrete. Just like any service, APIs are very "intangible" if productization is not applied. Neither your own organization nor your future API consumers will know what to use them for, how to use them, where to find them etc. It feels like the packaging of the product is missing.

The differences in API products between partner segments?

Each partner segment or API consumer segment impacts your API product decisions. These include the “packaging”: API design, service levels and other terms, pricing strategies and deployment models to name a few.

Let's take an example where the API customers are interested in one single apartment building.

The segments of API consumers or partners here could be the owners of the building or the maintenance company. When dealing with a single building, the API could be quite simple. The API is designed to be very easy to authenticate and with a simple data model.

Empathising with the API consumers in the segment is important. The design of an API needs to reflect the level of expertise and the need of the API consumer (user and application). In this case, the use of the APIs would be a simple integration with a minimal budget and experience of APIs. Therefore a simple API design goes a long way.

Typically, users in this segment would never use the API directly, but via a building maintenance system. This type of system could have a ready-made integration to the fire alarm system via API.

From an API monetization point of view, the model would be indirect. The maintenance company would pay for the use of the API without even necessarily knowing it. The API usage would be paid as part of the monthly or yearly fees of the software. This is an example of an indirect revenue model from the point of view of the maintenance company and the system provider.

In this case, the building owners or maintenance companies are most likely the buyers of the fire alarm products, not the APIs directly.

What would be included in the package for the maintenance companies?

There are at least three different packaging options:

1) fire alarm devices,

2) fire alarm devices with vendor’s own app or

3) integration to the maintenance system as an additional service.

Remember we were talking only about the one apartment building case. What if the same company manages multiple buildings? What if some of them would be apartment buildings and others commercial, or high security?

In these cases, the company would need to deal with many different fire alarm systems and tenants. Even if they were using one fire alarm vendor, there might be separate product lines or additional features for each segment. The maintenance companies would most likely want to use the API directly, instead of using the fire alarm maker’s proprietary system or an integration provided by a system vendor. They may have a dedicated integration partner.

Why would one API not be enough?

Definitely, the API design would need to be more complex when managing multiple buildings and stakeholders. It would need to include more building types and more complex fire alarm setups. It would require more fine-grained access control. From a product strategy point of view, one must think carefully if all these features ever need to be used simultaneously? Or is there even a bigger risk involved in that case?

Something to consider when mapping out the scenarios:

It's possible that the companies, systems and use cases used to manage all building types and fire alarm products would never exist in the same company's system and service portfolio. This means that separate APIs for each segment could make the API design and API consumer experience much simpler.
It's also possible for one system to use multiple APIs to cover multiple value propositions if needed.
In some scenarios and with meticulous planning it may be possible to get to a simple design and one API even in a complex use case. This typically requires simplifying many internal structures and adding a smart orchestration layer as the first level API.

APIs in your marketing and support channels and as relationship builders

APIs can be a channel to market and order your existing products. APIs can be a way to share product sales data with partners. APIs can create new value propositions or new product categories to augment existing products. They can provide access to product usage data or other extra features.

The most common assumption is often to make money i.e. use direct monetization by pricing your APIs. Most often, that is not the case. The indirect revenue models and benefits may present a much more lucrative opportunity. I’ve covered some of the various ways of how APIs can fit your business model and product or service strategy in the book “API Economy 101” I co-authored with Moilanen & all (2019). If you want to learn more, I recommend reading how Matthias Biehl explains the differences between indirect and direct monetization.

Indirect revenue models include many benefits. These can be improved client retention, increased customer and partner satisfaction, and faster delivery of products. The more clients can co-create experiences by integrating their own systems and data into your products, the more committed they are.

Digital product management re-invented: APIs over UIs

The fire alarm system could offer a nice user interface, data and analytics for their own products directly to the end-users, the building managers. But they could also choose to "outsource" the problem to the maintenance system providers. By doing so, they would risk relinquishing also some amount of connection and customer experience with the end-users. On the other hand, they can also benefit by being able to sell more and reach a wider audience.

From a monetization standpoint, the question of whether these maintenance system providers are paying for use of the API or not. They are expecting the API to reduce the fire alarm system vendor's costs with no need to develop their own software or support customers with integrations. They could also gain a bigger market. Of course, there is a chance the partners already have their own software, and there could be other reasons, why your API is blowing up your partners’ business model instead of enabling it. It’s best to try to find a win-win scenario, and this is why partner research is essential.

More customers mean more attention and effort towards partner onboarding and partner management. The sales and marketing efforts will look different to this segment than the traditional. This needs a set of tools, resources and practices.

‍

If you would like to find the right fit with your APIs and your business model, or rather a good business model for each of your APIs or API product categories (!) then try the lean and business-oriented APIOps Cycles method that many companies use as part of their tool box and operating model. I developed it together with some other enthusiasts a few years ago, because there just wasn't any framework that business managers, API product managers, service UX and API designers, API architects and API developers would be able to use together.

These are some of the topics we address daily with our clients at Osaango and The API Collective. With APIs touching so many aspects of the business model, technical architecture and organizational silos, the humans behind APIs may sometimes find themselves lost in the sea of opportunities and stakeholders. I recommend reading Claire Barrett’s post on how to find the decision-makers and get your API products and programmes funded and supported. It’s not going to be just technical changes, you need to power a lot of people to make the organizational change happen.

*) Some explanations on the choice of difficult academic terms. Both terms productization and servitization have very firm Finnish (like me) origins and research traditions. I recommend for example reading more in the "API Economy 101" -book (disclosure: I'm one of the co-authors) or e.g. this research Simula, H., Lehtimäki, T., & Salo, J. (2008, June). Re-thinking the product: from innovative technology to productized offering. In Proceedings of the 19th international society for professional innovation management conference, Tours, France (pp. 15-18).

The three foundations for making money with APIs

Making money with APIs is often aspirational and can be difficult to realize in practice without: (1) the right business model, (2) an appropriate pattern for API monetization, and (3) support from the organization. In this series of articles, we explore these foundations in more detail.