API Product Management is a fairly nascent discipline. Just a few years ago, the industry thought of APIs as technical endpoints, so these endpoints are built around Functional Specification Documents (FSDs) such as the OpenAPI specification. They’re often built, deployed, and operated by technical teams.
But now those API endpoints have matured and been integrated into the functioning of business to the point where they need to be managed as products. As such, they need to be driven by a vision that is aligned with the business.
They also need all the trapping of traditional products––a business plan, KPIs, customer focus, UX/DX, marketing, sales enablement, and so on. This means that the role of the API product manager has emerged as one of the key drivers of “digital transformation.”
Today, the concept is becoming more broadly adopted. API thought-leaders, including folks like Mike Amundsen and Erik Wilde, provide great explanations of “APIs as products” in their recent discussion, What is an API Product? How a Product Mindset helps with designing Good APIs.
What is an API product?
I recently had a great conversation about API products with Andrew Brown of APImetrics. Andrew pointed out that the API product concept was originally developed at Apigee around 2012 to address the use case of a specific customer.
The customer wanted to expose a set of endpoints to three different customers: developer, small businesses, and enterprises. But they also wanted those APIs to have different rate limits, pricing, security, and other attributes based on the plan.
Today, over a decade later, very few tools and platforms actually implement API products as a formal construct. API product managers are left to cobble together a toolchain to partially address their specific needs.
Key Success Drivers for API Products
It doesn’t matter if you design a great API. Who even really knows what that means?
You have to design APIs with customers in mind. And here is the tricky bit––different customers will have different needs and requirements, even for the same API endpoints.
One topic of our discussion was success metrics, or KPIs, related to APIs as products. The drivers for measuring any API products are:
- Problem statement – Any API product should be able to address the problem statement received from early feedback.
- Business use case – Gone are those days when we used to call API simply an endpoint. It’s become a full-fledged product that requires a proper use case, along with business metrics to justify the use case.
- Adoption and acceptance – It’s important to know how the developer community reacts to products. Higher adoption indicates success, though consistency in adoption is equally important.
- Understand the Total Addressable Market (TAM) – Feedback and interviews are very important while you are building any new product, especially if you are building any abstract product like APIs.
- Growth and monetization – Every product has its own value proposition and growth ratio, measuring the growth vis a vis monetization is important driver points for success metrics.
API Product – What about packaging and brand awareness?
Like any other product, APIs need solid packaging and branding. The API product marketplace is fragmented and crowded. A well-packaged API product has a distinct and differentiated presence. To provide a differentiated API product offering:
- Use cases and artifacts – Each API product has its own use cases, business cases and data flow. Make a well-planned document on the usage and relevance of the product.
- API descriptions, specifications, and collections – If you can’t make a visual of your product then the product will have lesser market adoption. A well-designed OpenAPI specification, API contracts, and collections can help developers grasp the coherent vision behind your API products.
- Easy onboarding experience – The only way for your API products to achieve market-fit is to relentlessly hone the developer onboarding experience. Never forget that developers have one primary goal: to become productive as quickly as possible. In case of APIs, a well-designed Developer Portal, a vibrant and responsive community, clear and relevant code samples, and an easy authentication configuration all contribute to a quality developer experience that will drive adoption of your API products.
My hope is that more platforms and tools will begin to offer built-in support for capabilities that directly benefit API product managers. As an API product manager myself, I’m glad that people in the industry like Andrew, Erik, and Mike are thinking in these terms.
An API product manager by day, Abhijit Dey speaks and writes on topics of interest to the API community. The opinions and insights in this post are his own and don’t necessarily represent those of his employer.