Every Cloud Service Needs an API Product Manager

Guest Author, April 16th, 2013

This guest post comes from Elie Chevignard and is inspired by a talk that he gave at API Days. Elie is the Head of Marketing at Mailjet and you can follow him @Elie__ .

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.

There Were no APIs Before the Product Manager Came in

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.”

“As a service” Means you are Selling a Product, Not a Service

Back in the day, economists tried to clearly distinguish between these two concepts:

  • Products tended to be consistent, physical goods: “something you can touch.”
  • Services were immaterial and defined as “an action performed by someone.”Problem: this view doesn’t work so well in our world full of immaterial goods. I can’t really touch an MP3 file, and machines can now perform actions, just like humans. One could argue that I can touch my music by listening to it, and that software “actions” are being delivered “as a service.” So this old classification would still apply. However, let’s pay attention to the expression “as a.”"As a service” implies there is a “product” behind it. This expression is only referring to the way the product is delivered. The expressions “SaaS” or “Web Service” designate nothing more than a business model and a marketing notion coined to formulate the following value proposition: “get the advantages of a product, but consume it like a service.”

    Nowadays, a lot of products are immaterial and delivered “as a service,” but their most important attribute remains untouched: they are consistent.

    “Products” are Consistent While “Services” are Not

    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.

    Turning Your API Service into a Product

    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
    4- Provide words of caution = Terms of Use and Anti-Spam Policy 5- Barcode it = Pay as you go, SaaS model

    6- Copyright it = Proprietary MTA built from scratch

    The API Product Manager Makes the Magic Happen

    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.

Both comments and pings are currently closed.

One Response to “Every Cloud Service Needs an API Product Manager”

April 16th, 2013
at 10:03 am
Comment by: Fernando Correia

APIs go much farther back than you would know. For instance, the Windows API was released in 1985.

Follow the PW team on Twitter

ProgrammableWeb
APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.