API Strategy: When to Build and Where to Start

I’ve had an unusually high number of conversations about API strategy over recent weeks. Many of them get technical fast, faster than I’d like. But, great API strategies start without mention of APIs or technology, they (surprise, surprise) start with a conversation about the customer and your partners. 

That is, your API strategy needs to start from the outside-in, which is the perspectives of your customers and ecosystem partners, and be balanced with the goals of your organisation. What this means is don’t go crazy building APIs before you know for sure you really need them.

Your API, or APIs, API platform, API technology, marketplace whatever you want to call it, then becomes the enabler. It is an enabler for the customer value proposition you want to deliver on.

This post aims to provide a reference point for those early conversations where you are starting to plan or rethink your API strategy. Think of it as providing a light framework, grounded in the principles of a product-led approach, to kick your API strategy discussions off with the right foundations. 

Start from the outside-in with your customer

The starting point needs to be from the outside in; viewing what you are doing or about to do with your customer in mind.

Something about the technical nature of APIs means this gets skipped, is rushed or doesn’t get the attention it needs. But at the end of the day, the success or failure of your API will come down to it’s value proposition to your customers as well as their ability to use and succeed with it. Their ability to get their Jobs-to-be-Done, done.

So delete API from your mind for a moment and look at what your customers are trying to achieve. This means understanding their world, their day and their priorities. 

Pro tip: Jobs-to-be-Done is my go-to framework to apply here to understand the customer better.

You may need to skip a few partners or integrations in the middle to gain a true understanding of this. You may need to work through a few layers of customers, looking at the customers of your customers. Getting to the end customer or user.

This takes time and effort however time spent here is cheaper than mistakes later and sets your API up for success. 

With your customer or layers of customers clearly in mind, you can now start to build your Customer Value Proposition (CVP), your Business Model and your Business Case. Focus this on the API as a product, not your general offering.

If you are just starting out or thinking about a major overhaul of your API strategy then you will want to give thought to who your early adopters will be. Which partners and customers are going to be best placed to take up your API products first? This is likely to be customers that will be somewhat forgiving because you’re solving something important to them. This is where you are going to get results the fastest so focus your initial CVP and Business Model here with a roadmap or plan to achieving the longer term CVP and Business Model that caters to a wider customer base.

Assess why an API is appropriate 

With an understanding of your customer in hand you now need to make an assessment of whether an API is the appropriate product to use to provide value to your customers. You’re essentially asking the question: Is an API the best way to deliver value to the customer for this particular problem (or set of problems)?

You will find some reasons for when to build an API and when not to. You’ll also find some common reasons that are used, but might be traps.

What you will notice is that the reasons when to build an API are centered around the nature of the customer and what you’re planning to do for them. The traps tend to come from an internal driver. 

When to build an API

Here are some reasons that might point to building an API:

1. Truly finishing the Job-to-be-Done always requires customisation  
2. High customer fragmentation.
3. Technology fragmentation within your Job(s)-to-be-Done.

My rule of thumb is that if one of these is present you have a compelling reason to create an API product. If more than one is present it’s even more compelling but prioritise which reason is more important.

Reason #1: Truly finishing the Job-to-be-Done always requires customisation 

When the final mile of the Job-to-be-Done always requires a material amount of customisation there might be a strong case for an API. 

It might be that your product gets them 80% of the way to having their job done but the final 20% differs for every customer. If you provide them with an API to finish off the final 20% then they can finish it the way they want.

This situation can arise straight out of the gates or arise when your customers have become more sophisticated.

Take PayPal’s offering for online shops and their API as an example. PayPal provides some out-of-the-box no-API-required buttons and a payments page. But some customers will reject the buttons and portal either because they want complete control over the user experience or have a special payments use case. These folks need an API. 

Reason #2: High customer fragmentation

When your customer base is highly fragmented there may be a good case for an API. 

This is a compelling reason if your product or business is used by a broad customer base and for a broad use case. You’ve had sufficient success that you can now drill down and see that there are more specific customer segments with differences in what they are trying to achieve and how they need to achieve it. 

Sometimes the need to drill down is driven by the emergence of niche competitors that are  catering (better) to just one segment within your market. You can’t or don’t want to go directly after each segment but you can empower partners and customers within each segment to solve their problems better.

For example, Atlassian’s Jira (a project management tool) covers the broad customer base and JTBD of people needing to manage tasks across a team. But, their customer base is fragmented across a range of industries, organisation types and organisation sizes. Even if you focus on their customer base in software teams there is immense customer fragmentation. While Jira itself caters to the broad use case, Jira’s API has enabled Jira to be extended to cater to the unique needs of customers of all shapes and sizes.     

Reason #3: Technology fragmentation within your Job(s)-to-be-Done

When the technology used by your customers is fragmented there may be a good case for an API.

This is a compelling reason if your product needs to work with other technologies to truly solve your customer’s problem. Your customers use different technologies and that it is impractical and uneconomical for you to try to replace this technology with your own products or integrate directly with all their technology. 

Providing an API enables you, your partners and your customers to better solve the problem of technology fragmentation.

For example, consider Square (a payment processor) and a cup retailer’s Job-to-be-Done of “accept payments” (I like cool cups). At CoolCupA they use Square and CupTrader (a fictitious end-to-end cup shop management software). My other favourite cup shop (CoolCupB) has connected Square and Xero. 

From Square’s point of view, there is significant technology fragmentation across “shop management software” so it’s more effective to provide an API for the various shop management software providers (or their partners) to integrate with. Yes, Square might do some direct integrations with major providers but the API let’s them directly address the issue of technology fragmentation.

When not to build an API

Now that you’ve thought about why to build an API, let’s now walk through why you might not build an API.

This list is by no means comprehensive but represents some of the common reasons that come up.

Reason #1: “This partnership will bring us lots of users”.

There is a drive within the business to create an API so that the business development team can create partnerships to bring new users or customers. This isn’t a bad thing at all however, usually when this is the driver (an inside-out driver) it misses what the customer actually wants which dooms it to trouble from the beginning. If the partnership brings value, hopefully new value, to the customer it will work, if not don’t do it for “new user acquisition”. You might get the users but they will churn fast. It’s OK, I’ve been guilty of this.

Reason #2: “We want to get the data out”

A customer tells you they need an API to get data out. This might be a good reason for an API or it might be a trap.

Before talking APIs with the customer, make sure you explore whether an export button or manual export of the data could work. Commercially, this might be a cheaper and faster solution to implement. Additionally, the objections to the export will tell you whether an API is needed and, importantly, why it is needed.

It might be that the API provides them with significant efficiencies due to the scale of their business. It might be that a competing product provides this and it’s a differentiator in selecting between you or them.

Basically, get clear on the Job-to-be-Done. If getting the data out via API makes sense for them and you then go for it. Making sense for you will usually mean multiple customers want it or a big enough customer essentially underwrites it. Otherwise find alternatives, an export is easier to implement and maintain.

Reason #3: Your customers aren’t ready for APIs.

With some products targeting consumers or small businesses your customers probably won’t be able to make use of an API. In fact, even in larger organisations when the customer is non-technical APIs may be useless or commercially difficult to work with (for your customer). Your workaround here can be to rely on partners but this means there needs to be enough of an incentive for them to work on the API.

Consider alternatives

Then before you set off on the first version of your API you may want to do a double take on some possibly viable alternatives: 

1. Can you integrate directly? Either as a one-off bespoke solution or a repeatable plugin. Sometimes just solving the entire Job-to-be-Done is better.
2. Can you provide better reporting in the product itself?
3. Can you allow for better data exports?

Next steps

If you’ve determined that an API is worth pursuing then you will want to start looking at how you are going to bring the API to life. This is a topic for another day but broadly you will want to think about your API product roadmap, developer enablement/experience, and the technical platform.

If you’ve determined that an API isn’t worth pursuing then great, you’ve just saved yourself a whole lot of time and your company some money.

---