At first, the phrase “my API is my Product” seems misleading. An API is a way to deliver a product, rather than the product itself, right? The term designates a “set of programming instructions designed to access an app.” Period. We’re talking about a means, rather than an end. That’s why there are so many different products relying on APIs: Twilio for phone, Mailjet for email, Google Maps for maps, etc.
To recharacterize APIs as products would simply be a misuse of language and we should instead say: “their product is delivered through an API.” However, at the same time, my common sense is telling me this latter assumption is wrong. Let me try to explain why.
Okay, APIs existed but they were internal tools called SOAs. Beyond developers, nobody knew about them. But things have changed. Today, any serious Internet user has heard about APIs. Some services are even packaging APIs for the B2C / prosumer market: IFTTT and Zapier are doing quite well!
This happened mainly because Amazon popularized the concept when they made their internal tools available to the public. Once the service interfaces imposed by Bezos were up and running, it was logical to package and distribute them as products: EC2, S3, etc. This is when APIs began to become well known by the public at large.
Here’s an analogy to clarify my point: when P&G discovers a new chemical to wash your clothes, there is no “product” until the laundry detergent is put on the market, right? The functionality exists: they’re able to clean your socks in their laboratory. But there’s no product, so nobody knows about it yet. Amazon was aware of this: productization is necessary before you can harness internal technologies and expose (or sell) them to the public.
This is what led Jeff Bezos to do for APIs what Steve Jobs had done for MP3 players, cell phones or tablets: he extracted killer features from a particular medium, and turned them into usable, marketable products. Bezos didn’t invent REST, just like Jobs didn’t invent touchscreens, but both have been able to leverage some existing concepts like nobody had before in order to build new kinds of products. Without Bezos the Product Manager, I really wonder what APIs would be today.
Not convinced? Here’s another classic example: Twilio. Their core value is the API; their product doesn’t even have a visual interface and all their revenues are API-driven. Do you really think it’s pure coincidence that Jeff Lawson, Twilio’s CEO and co-Founder, previously occupied a Product Manager position at Amazon? Of course not, and that’s probably how his venture also pioneered in API productization.
Note that companies such as Ebay and Flickr launched some APIs before Amazon, but they were only used to distribute and project products. These APIs were not “the product itself.”
Back in the day, economists tried to clearly distinguish between these two concepts:
Nowadays, a lot of products are immaterial and delivered “as a service,” but their most important attribute remains untouched: they are consistent.
Think about it: when you want a “product,” you just go to the store and buy it, right? The “product” preexists to your needs and only has to be delivered. However, the situation is different for a “service,” as it needs to be performed. In the former case there is consistency and in the latter, a lot of uncertainty. This is why it is preferable to deliver a “product” rather than a “service.”
People who sell services know this very well. Consultancy firms always use the phrase: “your most valuable assets walk in and out of the door every day.” They depend 100% on their people, more than any other business: they rely on their performances. To protect themselves, they try to productize their services by any means. That’s what made David Ogilvy say:
“To create a service business you can sell, do whatever you can to make your business have a product and a formula that predictably delivers results.”
In a SaaS business context, you want developers to build their own products by using your API. Hence, you want to offer consistency: you want your API to be a product, not a service.
This is nothing really groundbreaking. Of course, having a unique technology that consistently delivers useful features is the first step! But eventually, it’s more about product design and marketing.
Why not take Procter & Gamble’s model as an example? That’s what John Warrillow does by looking at a bottle of Tide and it works quite well. When you think about it, laundry detergent is not much different from an email delivery API:
1- Name it = Mailjet, because it’s fast and it happens in the cloud 2- Package it = Event API / Webhooks, REST API, X-Headers, etc. 3- Write instructions to use = API documentation
6- Copyright it = Proprietary MTA built from scratch
These six steps are probably a typical roadmap for any API Product Manager, whose role is to see this big picture. An API needs a coordinator, a dedicated mastermind who overviews the entire productization process.
These profiles already exist, but they will grow more and more popular, a bit like the “Developer Evangelists” did. The perfect skills are a good mix of programming, project management and marketing. Gathering all these abilities at once isn’t an easy thing to do, but you really need someone with this helicopter view.
The importance of having a strong product vision for APIs is probably why API Management Services like 3Scale or APIgee are becoming more and more popular. I have no affiliation with them, but these companies do a great job evangelizing the need for strong “API product management.” Lots of SaaS businesses are not really aware of the challenge and have difficulties in finding the right talent. If you’re curious and want to look into any of this, APIgee has some very interesting content about API best practices.