In the last blog post, I showed that in the API economy, the success of APIs will be judged and determined by the customers of your API. One of the keys to success is focusing on the customer in the early stages of API design. In my opinion, there are no viable alternatives to this customer-centric approach to APIs. This opinion also aligns with Gartner's recommendations for building customer-centric organizations, making the obvious case that enterprises cannot focus on the customer enough.

While it is true that customer-centricity is the cure for a lot of the ailments associated with APIs, the cure can unexpectedly become a poison when applied in the wrong way and in the wrong dose. As the renaissance physician Paracelsus (1493-1541) said: "solely the dose determines that a thing is not a poison." And it can serve as a word of caution for customer-centricity in APIs.

Challenge: Confusing existing customers with API customers

Identifying API customers can be confusing. Many organizations confuse the customers of their existing products with the customers of their APIs. In most cases, the API customers are not the existing customers of your organization.

If you are a car manufacturer, your existing customers want cars—not APIs. If you are a bank, your existing customers want bank accounts, loans, or investment products—not APIs. If you are an insurance business, your existing customers want insurance policies—not APIs.

You get the picture. API customers are the API consumers, the people and companies calling your API. In most cases, API customers are a new customer segment and should be treated as such.

Don't make the mistake of confusing the API customers with the existing customers of your organization's traditional products!

Challenge: Overfitting—too much focus on single API customers

When you talk to the customers of your APIs, their needs might seem all over the place and contradictory. Some of your customers might be more vocal about their needs, pains, and gains than others. There is a natural tendency to follow their requests—after all, we want to be more customer-centric, right? But following every wish of a customer can lead you in the wrong direction. You may end up building a bespoke API, which is a solution for the unique situation of one specific customer.

Sometimes we call this challenge, "overfitting," since it makes the API too specific to the needs of one customer.

To prevent overfitting, always check your API design and optimize it for a sizable number of customers, a segment of customers, and not for a single customer. So make sure that the needs, pains, and gains are shared by a wide range of customers. Start with a large group of potential API customers that represent a broad range of interests. Find commonalities and patterns by filtering the list of customer needs. Determine the needs that you should consider in order to design a successful API.

Deciding which needs to address and which to ignore is a balancing act; make the API too broad and it will not appeal to anyone but make it too specific to the needs of one customer and it will only appeal to that one individual customer use case. The goal should be that the API is a product that appeals to a broader set of potential API customers.

Discuss these insights amongst your teams and with customers. It can be helpful to place some structure around these discussions and have a visualization. The API Value Proposition Canvas is one example.

Challenge: Listening too literally to API customers

Listening is a tough skill to master. The biggest challenge I see is listening too superficially and too literally to what API customers say, instead of listening to their real needs. When you talk to API customers, your intention is to learn about their needs. However, it is easy to get sidetracked.

API customers might be more comfortable proposing their own solutions rather than talking about their challenges, needs, and current pains. In such cases, it might be helpful to keep Henry Ford's quote in mind: "if I had asked people what they want, they would have said faster horses." Luckily, he did not listen to people too literally, but he applied his own analysis to uncover the needs first and then propose a different, and much better solution to those needs.

So, apply Henry Ford's wisdom and don't take the customer's proposals for APIs too literally. Instead, gain some altitude to analyze what is said, do your own thinking, and try to uncover the deeper needs. This allows you to propose APIs that customers really need.

Summary

Designing APIs for the API economy is different from designing technical or internal APIs. Most API designers err on the side of too little customer-centricity. But when they realize this mistake, it is easy to over-correct by seeing existing customers as API customers, over-fitting, or listening too literally to everything API customers say. Awareness of these common challenges helps you to stay clear of them and get started building truly customer-centric APIs for the API economy.