What is API Product Management?

Recently I've noticed some good discussions in the API community around what API Product Management actually is and what it entails. Of the content I've come across I can highlight What is API Product Management by Bruno Pedro and Erik Wilde and What API Product Managers Need by Deepa Goyal and Kin Lane. 

Given that in Oracle Hospitality I am responsible for leading an entire API and Integration Product Management organisation which manages / oversees over 3k API capabilities and over 2k postman collections publicly available, naturally this topic is of huge interest to me and perhaps needless to say I have my own opinionated views on it which is why I decided to write this blog.

As Erik said in his opening statement "A lot of people are talking a bout API Product Management but I still think a lot of people are not actually practicing API product management", I think this is true in many different ways being one of the main reasons the fact that not everyone is clear about what "Intangible Products" actually are or mean and as importantly, the implications of it especially in terms of investment and organisational attention (e.g. priorities).

So before I continue with my point of view, below an extract from section API Products Target Operating Model of my Enterprise API Management book defining what a product is:

"A product is any good and/or service that satisfies a need (a lack of a basic requirement) or a want (a specific requirement for products or services to match a need) and thus can be offered to a market. From a customer standpoint (someone who acquires the good or service, the buyer), a product is something that delivers a benefit as otherwise there is no point in acquiring it.

Products can be tangible or intangible. Tangible products are physical goods (objects) such as phones, cars, drones, or anything that can be seen and touched. Such products are easily identifiable and don’t really require further explanation. 

Intangible products, on the other hand, are trickier to appreciate as they can’t be seen and/or touched as they are not physical objects. They can be virtual goods such as mobile apps purchased through an app stores, software as a service purchased from a cloud vendor, or services offered by an organization and/or individual such as catering services, hospitality services, and even software development services."

If we apply this definition to APIs then API products can be defined as intangible goods (because APIs are digital goods, not physical objects) that satisfy the needs of application developers and/or product owners who seek quicker access to information, functionality, and/or innovation deemed necessary in order deliver a basic, expected, or augmented product.

I go into A LOT more details in the chapter around what treating API as products actually entails from different dimensions such (team topologies, roles and responsibilities, communication models, communities, etc), but back to the original topic of this blog, what API Product Management actually is? my definition is in fact quite simplistic to begin with:

API Product management is the discipline responsible for the planning, developing, launching (commercials/pricing implications, sales enablement, runtime support, etc), and managing an API product through its full lifecycle including communities around it.

Although simplistic it align wells to the definition of "Product Management" in general. Which is why with my teams I go a level deeper.  If APIs are products then APIs require designated API Product Managers.

API Product Managers are responsible for Good API products that address real market needs (outside-in thinking) and for which there is a known target audience who would be willing to pay (directly or indirectly) for the value they get when using the API.

API Product Managers are responsible for:

• Understanding the API target audience, its needs and the competitive landscape 
• Defining API functional and non-functional features roadmap
• Planning and prioritising API features based on insight
• Ensuring an API meets all requirements and standards
• Authoring the required user documentation, marketing collateral, usage samples and recipes
• Overseeing the full API cycle and ensuring it occurs smoothly and there is no blockers
• Converting user and usage feedback into creative features
• Promoting, deprecating, retiring API capabilities based on user needs and usage
• Evangelising and supporting the API user community.

The above-mentioned definition however only works if there is a clear understanding of what constitutes a Good API.

We define a Good API as one that ultimately offer capabilities that are (ideally) unique and relevant to a known audience but most importantly it gets used because it has a low entry barrier, solves real problems and thus delivers value. Furthermore, Good APIs require careful outside-in thinking so they address real market needs for its audience, when it matters and differentiate thus creating demand for its use and willingness to pay (directly or indirectly) for the value they deliver. Good APIs are products on its own right. 

Good APIs are by design:

• Intuitive – easy to use with just few clicks and steps
• Affordable – low entry barrier, free sandbox, low dev costs
• Well documented – API spec, good user guides, usage examples/recipes, commercials, limits
• Discoverable – easy to find capabilities and usage samples
• Consistent – common semantics and usage experience
• Performant – fast response times
• Available – zero downtime
• Stable – clear versioning strategy, doesn’t break
• Observable – rich analytics on performance and availability
• Secured – API OWASP top 10 complaint
• Well supported – responsive and timely incident resolution
• Evolvable – evolves based on user and usage feedback.

Last words:

Before talking about API Product Management, it's crucial to have clear understanding not just of what an API Product actually is in theory, but the implications of it especially from an organisational and financial standpoint. The investments required to truly launch successful API products (whether internal and external) are significant and there are no silver bullets or short cuts. There also isn't one way to do it right. In this blog I've shared 'one way'.

That being said, IMHO successful API products have one thing in common, first and foremost they solve real problems and therefore there is real demand for it. Such demand drives investment meaning the product continuously evolves and that is in my opinion a clear distinction between real API products vs APIs that are defined as products in theory but in practice they lack business investment and organisational support.