Building API-driven products

I am consistently confused by people conflating the idea of managing products with that of 'making apps', or websites, or generally things with a user interface you can click or tap.

There are just north of 6 billion customers that can access your product through a visual interface - and tenths of billions of devices willing to access it programmatically, using a computer interface. This interface is called an API (Application Programming Interface), a catch-all term that encapsulates a wide range of solutions with one specific goal: letting other machines access what your companies does - for a fee.

If this sounds abstract, let's think of the fintech use case of issuing a card. A traditional product is your bank in the early 2000s: you fill in a form, request a credit or debit card, walk to the bank branch, verify your identity, and later get a card delivered at the bank office where you pick it up.

An API-driven version of this is any modern Issuing as a Service platform: someone builds a product that lets anyone fill in forms, request cards, verify identities and dispatch the newly personalized card using a set of specific APIs that another piece of software (for instance, your favourite neobanking app) can call programmatically.

The API product acts as a gateway - or middleman - and charges a fee for that: in fact, most of the fintech services popping up these days are - behind the scenes - powered by a handful of API gateways like Marqeta, SoFI, Adyen, or Stripe. This outlines a key advantage of API products: once built, they can capture multiple markets at once and - by offering a standardized, commoditized set of feature - command a significant share of the cake without having to scale up, reach, and onboard millions of users: instead, API products are usually sold to other businesses, that then use your generic API building blocks to power their own business models (and acquire private customers on their end).

A large part (around 80%) of the work I do these days is API-driven - I spend less and less time designing UI and customer flows; instead I spend most of my days either prototyping services on top of internal or external APIs, and thinking of how to expose our own APIs to other teams in the company or elsewhere.

Thinking about API products can be especially daunting to people new to the whole PM job - as a consumer, we mostly have experience with user-accessible products and services, and building API products usually requires good knowledge of the business line we're in: something that comes with experience.

There are however some general tips I can give to anyone attempting to build an API product - based on best (and worst) practices I've seen in the last few years. Without further ado, here's five things you really need to think about to build top-notch API products:

✨ Great APIs are usable

Usability for an API product is a bit different than your usual consumer interface: APIs target developers and computers, so usability means the API is consistent, behaves predictably, and is well-documented.

This should be an extremely obvious idea; yet there's so many API products that fail at this that I want to elaborate on those three principles:

• The API being consistent means similar constructs are used for all operations: for instance, you shouldn't have half of your API use numerical IDs for customer operations, and customer usernames for the other half. Or you wouldn't want some of your API calls return integers, and other return strings - for the same entity. Your API should be built from first principles that allow you to define a basic 'language' that will be used throughout your product.
• Closely related is the idea that your app should behave predictably. Once you have defined the basic structure that your API should follow, you should aim to build it following the 'principle of least surprise'. For instance, if a given call aims to return a single attribute for a certain customer, you would expect the response to contain the attribute - not a list of attributes, or an ID that can be used to fetch the corresponding attribute. APIs that are consistent and behave predictably can usually get the customer to a first working implementation much faster, and are more pleasant to work with.
• Which leads us to the last point: documentation. Your API should be well documented, and whenever it changes the documentation should be updated to follow. In fact, documentation is an integral part of your API product, and should be written during development (and not as an afterthought) to help enforce the principles of consistency and predictability.

👔 Great APIs follow your customer's business logic, not your product's software logic

This is also an obvious point that plenty of products fail at. You see, developers will build complicated products and once it's time to open them up to a third party will simply slap API routes on top of the existing software functions.

This leads to APIs that replicate your software logic - but are convoluted and difficult to use for businesses trying to integrate with them.

A good API product should be built to accommodate a set of basic use cases for your primary customers, while having solid first principles (consistency and predictability again) that would allow it to scale to future usage patterns. This means it should be able to accommodate your customer's business logic in a way that fits the most common use cases.

It's better to add an additional layer of work between your software and a delightful API, than to map calls to software logic 1:1 and end up with an API that makes no sense to the end customer.

✏️ Great APIs are easy to try

This one is simple enough we can cover it in a single line: your API documentation should have live code, an easy-to-try sandbox mode, or require at most a few clicks to get some test API keys and some boilerplate code or SDK that allows you to get the first API response in less than half an hour.

Now go to your average API product's signup page, and measure how many e-mails, credit card numbers, sign-up modals and general barriers you need to actually get started. Yep: it's another common sense tip that gets overlooked once sales are involved in your API product.

Don't let them do that to your product. Sneaky sales tactics like sign-up walls, delayed API key distribution, and the ever-present 'contact sales' button need to go.

Your API should be easy to try, because that's how you get your product assessed quickly - and considered for the job at hand by a potential future customer.

⛓️ Great APIs follow standards

If there's a standard in whichever sector your product is operating into, you probably don't want to re-invent the wheel.

For instance, in fintech, most transactions are authorized in real time, but the money only moves in batches. Trying to deviate from this model for your API would be an unnecessary layer of abstraction for your final users, and confuse those with previous experience.

It's good to modernize the basic ideas in your sector - and for sure, you can get creative about streamlining your API. But if there's a set of generally agreed upon standards that the ecosystem follows, it's probably best to use them as a constraint during the design phase

😍 Great APIs have fans, just like any great product

A common misconception is that people can have a visceral attachment to consumer products (like an iPhone or a Playstation), but they will never love your API product.

That's not really the case: delightful, well-designed products that make people's work easier, more productive and even teach them new ideas or concept along the way are just as epic as the next piece of consumer electronic.

That's why part of the role is pushing for investment and care towards a full ecosystem around your API - be it a developer ecosystem, developer advocates, good documentation, brilliant tooling and so on. Doing so gives people the feeling that they are dealing with a mature, complete and polished product that 'clicks' well enough to make people love it.

API driven products are less intuitive to build than consumer products - but they can be outstanding and loved by customers too. That's what you should aim for.