We’ve written plenty about different API monetization models and monetizing your API using a freemium model in the past, but just as important is envisioning how your API might fit into your business model as a whole.

Obviously, this is something that will differ hugely from company to company — in the case of a business like Twilio, the API is the core product. In most businesses, however, an API is likely to be seen as a secondary offering, i.e. an ancillary product that exists on the margins on the business. APIs are often regarded as something just for techies that don’t have much of a role to play in the wider context of the business.

It’s this view that Matthias Biehl, API consultant at API University, believes is totally outdated. An approach that puts APIs first can be a key business driver, with enormous financial potential, but only if it’s built to satisfy the needs of the developers who will be using it.

What do APIs and Lego Bricks have in common?

Most of us have fond memories of playing with Lego as kids. The real attraction of Lego is that, even though most sets came in boxes with pictures on the front, it really didn’t matter if what you built ended up looking the same as that picture.

To quote a previous article featured on this blog, “Many API talks start off by explaining that APIs are like these [Lego] bricks. They can be combined in innovative and creative ways beyond their originally intended purpose.”

The more you look, the more similarities between Lego and APIs you find:

• Standardized: Universal, standardized components that function as building blocks;
• Usable: Strong emphasis on usability, with documentation/instructions;
• Customizable: Options to use different bricks/APIs for different functionalities;
• Innovative: Ability to mix and match different building sets/APIs to create hybrid results.

“Lego and APIs have a super simple interface and, because of this easy interface, it’s very intuitive and very simple to build things quickly.”

With Lego the sky’s the limit, and the same is true when you consider the endless creative potential APIs can offer. While legos and APIs may come with a picture on the box or documentation that outlines their recommended uses, some of the most exciting outcomes might not look anything like what the API provider is expecting.

Let’s think more about that statement, because it has some pretty big implications. It suggests that, in the many cases where API consumers build services that the creators of APIs aren’t expecting, there’s a disconnect between what API consumers want and what API providers think they want. In fact, we’ve previously written about some unexpected uses of APIs in the context of IoT.

One of the things we love most about APIs here at Nordic APIs is the potential they offer to hook up products/services that would otherwise be unable to talk to each other. In this respect, APIs actually have even more potential than Lego bricks — you’ll know that if you’ve ever tried to use the latter alongside Duplo or Playmobil…

APIs and the Value Chain

Matthias suggests that the easiest way to make money with an API is took look at where it fits, or might fit, in the value chain, i.e. where does the API in question have an impact in the wider context of the business?

As Matthias puts it, “the story doesn’t end with API consumers.” In all likelihood, the goal of API consumers is to put together an app or service — one that may package several APIs — and serve it up to end users.

He provides the example of Uber which, as we’ve covered in a previous post, relies on multiple APIs for survival:

• Maps/GPS – Google Maps
• VOIP and SMS notifications – Twilio
• Payment processing – Braintree
• Identification — Microsoft Face API

So we see that API owners not only need to be thinking about about what their API will do, but what some of its potential use cases might be. Only then can they determine how the API can make things smoother and relieve stress not only for API consumers, in this case app developers, but also for end users who will use these apps.

APIs and Design Thinking

Matthias poses two frequently asked questions that API developers hit him with all the time.

1. How can I make money with my API?
2. How can I make my API easy to use?

He also poses a third that he never gets.

1. Am I building an API that developers need?

Right away, we can see that 2 and 3 are the key questions that need to be answered before 1 can be addressed. Unless an API has real purpose and is easy to use then it’s very unlikely that anyone but the most ardent fanboys of your product will want to use it, let alone pay for it.

In order to identify API functions that people really need, Matthias suggests the following cycle:

An API business lifecycle, as defined by Matthias

The process can be slow and arduous, not to mention less exciting than hacking together an API in one caffeine-fueled evening. But it’s probably no coincidence that many products built in the latter way fail to find traction. In fact, as one article in The Atlantic puts it, “Nothing useful is ever created at a hackathon.”

That may be overstating the case – many popular Facebook features were born at internal hackathons – and, while adopting a “design thinking” approach doesn’t guarantee success, it’s far more likely to help bridge that disconnect between API developers and consumers than racing ahead with development without any input from potential users.

APIs and the Business Model Canvas

Click to expand/download the Business Model Canvas

Once the needs of API consumers have been identified, it’s much easier to see where an API fits into a business model. Matthias suggests using the Business Model Canvas (BMC) to do this in visual and easily iterative terms.

If you’re not familiar with the BMC, it’s a methodology often associated with lean startups that involves plotting out your business model in its most basic terms using a standardized template.

He uses the format to provide an example of how a Telco business could pivot its key focus to providing APIs:

Taken from Matthias Biehl’s slides

Even if an API is only a small part of your business, it can be helpful to look at how it fits within the structure of your business. That could even mean using the Business Model Canvas to map out what your business would look like if you decided to make your API your core product tomorrow. Now there’s a thought that’s exciting and terrifying in equal measures!

It’s also worth noting, as Matthias does, that the value chain associated with any API is effectively constructed of two different business models: the business model of an API provider and an API consumer. These two models are far more closely linked than many people believe them to be; identifying where an API adds value in the business model of a consumer enables providers to determine where/how/whether to charge for certain functionalities.

Final Thoughts

A huge issue with the current approach to APIs, and in particular how they relate to business models, is that many companies build their API(s) alongside their products before thinking about how it can fit into their business model.

As every business person knows, starting a project without conducting the proper market research or planning about how it will fit with the overarching model of the business is never a smart move.

The big questions to focus on when planning a new API are as follows:

• Am I building an API that developers need?
• How can I build an API that makes addressing those needs as easy as possible?

If you already have an API, it might be too late to ask those questions. Although there’s certainly nothing to stop you, like WorkflowMax has done, from inviting user feedback via your documentation or developer hub.

It’s never too late to look at how customers are using your API and whether you can start charging for elements of it. Or, if you’re concerned about the backlash that might generate, building in additional services that are related to – but go beyond – the most popular aspects of what you currently offer.

Great APIs are like Lego bricks: easy to use, and people want to play with them. If you’re building a new API, or reiterating an existing API, you might just want to think about keeping a Lego brick on your desk throughout the process. You know, just as a reminder of what you should be aiming for.