January 10, 2024

How simplistic API product thinking is holding back progress #APIFutures

How simplistic API product thinking is holding back progress #APIFutures

“Stripe or Twilio.” If you’re like most people, that represents what you’d likely think of when you hear the phrase “API product.” This makes perfect sense, as both of those companies are mature providers of API-based solutions to consumer-developers. Hence, it's not surprising that the most “productized” APIs today are big, public APIs like these.

But what then exists at the other end of this spectrum? Or to ask this another way, “At what point do you consider an API not to be a product?”

In the answer to that question we can find a big missing piece — possibly even the biggest flaw in our mental models — which today in early 2024 is holding APIs back from reaching their true potential.

Let’s dive in.

What makes a product?

For anything to be a product, it must satisfy several pre-conditions:

• A producer (or supplier): a party (person or group) that produces or possesses something of value

• A consumer: another party that is willing to trade for that something of value

• A transaction: a resulting exchange of value between the two parties

The iPhone might be the most famous product so far this century. Because Apple is the only producer of iPhones, every iPhone must have been sold from Apple at some point. iPhone customers aren’t just happy to exchange their money for the device, they’re sometimes willing to stand in line for hours to be one of the first to get it.

But if I have a used iPhone, and I sell it to someone else (or even trade it for something), would it be fair to call it a product of mine? That doesn’t seem right… so let’s add one more condition:

4. Repeatability: a producer must be able to make more

Let's try applying these rules again. This time, imagine I’m a decent painter (note: I am not!). I could spend hours meticulously painting a piece that I can sell for thousands of dollars. Once I sold it, that painting would be gone. However, I could in theory paint that same scene again and again. Even though these paintings may vary slightly, they are reasonable substitutes (repeatability). This seems to satisfy the four product criteria above.

What then if I made high quality prints of my original paintings? The cost of creating nearly identical items would drop tremendously. My original may have been 30-inches-by-30-inches, but now I can potentially offer bigger or smaller versions. What is most notably different about these new products is how the cost of goods has fallen and how repeatability has improved. These prints feel like they have more product-ness than the original pieces.

“But wait,” you say. “I came here to hear about APIs. Why are we talking about paintings?”

Ah, good point. Let’s do that.

Applying our criteria to APIs

Let’s return to Twilio from above. In 2010, at a meetup in Heroku’s basement, Jeff Lawson gave a demo that blew my mind when his live-coding made dozens of phones ring at the same time. By getting a Twilio API key, I could make a phone ring, too, with a few lines of PHP. 🤯

• Producer: Twilio who made it almost trivially easy to program communications

• Consumer: me/you/Catherine/etc., all willing to part with a few dollars if it worked as well as it demoed

• Transaction: with a market cap today of over $10B, clearly there were some transactions

• Repeatability: ditto

Let's try another example. Say I am building a backend service for a mobile app that I also operate. I need orders to be created and managed across two different systems, meaning that I will create an API so they can talk to each other.

• Producer: me

• Consumer: me again

Uh oh. When there is no second party, there cannot be an exchange of value. For something to be a product it must have customers who are distinct from its producers. Without that, there can be no transaction.

This implies that when APIs are products, they fall into the realm of sociotechnical phenomena.

Wait, so that’s the big idea?

Well, yes, actually. It is the fundamental nature of APIs to solve a technical problem. But when you productize any API by inviting other people to use it, it means you are wrapping your technical API contract with a social API contract.

As I mentioned in a previous post, “… neither the social nor the technical system can be understood or optimized in isolation; they are deeply intertwined and influence each other.”

So the next time you see an API that is not used by people outside the team that produces it, try looking at it as an implementation detail. It addresses the technical challenges of a distributed system. Or when you next come across an API that has any consumers outside its producing team, try looking at it as an API product.

That second group of APIs? Those are much more interesting. APIs have been around for a really, really long time (1968!), but what makes network-transported APIs so special is the opportunity to solve the problems of people beyond the producers. The impact of a service grows as more people use it, increasing the leverage of a technical effort/investment made in a service.

On-boarding the first non-producers is when an API crosses a key threshold. At this point an API begins its journey as a product. It has entered the sociotechnical realm!

There is a lot more to cover on this topic, especially how to manage APIs as products. To get notified of new posts, I hope you will subscribe to Sociotechnical (it’s free).

Addendum: other APIFutures

Special thanks to Matthew Reinbold (I recommend his piece on API product management) for conceiving the idea of APIFutures and for getting the community so involved. I’m looking forward to reading what other people see as the biggest opportunities in the API landscape in 2024 and beyond. Some of the early posts that touch on similar themes to mine include:

• Opportunity #3: The Growth of the API Product Manager - James Higginbotham
  I agree with all of the three of the APIFutures points that James’s touches on, especially the third point that touches aspects of API product management. Connecting it back to my post here, certainly not all APIs deserve to have a dedicated (or even fractional) product manager, but public APIs or directly monetized APIs may often benefit from someone in such a role.

• API Management is for everyone. It's time to talk about it that way. - Emma Kriskinans
  Emma touches on a point that resonates with me about how the phrase "API Management" as a framing isn't accomplishing what it should. Her commentary similarly shares a product-focused orientation.

• Taylor Barnett-Torabi's The future of APIs is (still) beginners
  In which Taylor implores producers to, "Meet developers where they are," in particular by embracing the perspective of beginners. The end result should be more intuitive API products that better anticipate the needs of users.

• In APIs are Interface Utilities, Kristof Van Tomme tackles similar issues. His statement, "APIs are not products, they are utilities that enable API products," seems highly aligned with my point above, though his fiery post reaches something of an opposite conclusion. In my opinion the critical distinction comes from identifying whether you're focused on a purely technical solution or one that is sociotechnical (for others). Where we agree is that not all APIs should be products.

This post may be updated after publishing to include the works of others, too!

Did you enjoy this? If so, then you should subscribe to be sure you don't miss the next one (it is both free and low-traffic).