Do All APIs Need Product Managers?
Some people think only monetized APIs need Product Managers
Do all APIs need to be managed from a product perspective? If not, which ones do? What do Product Managers need to own and build APIs effectively?
This article is brought to you with the help of our supporters: Zuplo and Speakeasy.
Zuplo is the only API Gateway that runs your OpenAPI definition directly. If you care about high-quality developer documentation, API analytics, and zero configuration deployments, give Zuplo a try today.
Speakeasy provides you with the tools to craft truly developer-friendly integration experiences for your APIs: idiomatic, strongly typed, lightweight & customizable SDKs in 8+ languages, Terraform providers & always-in-sync docs. Increase API user adoption with friction-free integrations. Try Speakeasy now.
Well, some people think only monetized APIs need Product Managers. Let's try to understand why by looking at the definition of "product." Generally speaking, a product is something that is traded in a market to serve a specific purpose. In our case, you can define an API product as an API that serves a specific need and is traded in a market, usually in exchange for money. In other words, an API product has to be monetized.
If, for an API to be considered a product, it needs to be monetized, then all free APIs aren't products. One type of API you can consider in this category is all the internal ones. These are the APIs that are private to your organization and are never exposed publicly. They're essentially free to use inside your company. They frequently fulfill the needs of some internal team whenever interfacing with another part of the organization. In fact, internal APIs, if done correctly, can constitute the majority of all the APIs your company maintains.
There are other free APIs. Those aren't internal, but they're also not being monetized. They're typically part of a business strategy where offering the API for free increases other relevant metrics, such as customer retention. These APIs aren't monetized, and their usage isn't metered. So, according to the definition I shared above, they're not products. And they don't need to have a Product Manager.
You could also argue that even some monetized APIs don't need a Product Manager. APIs that are purely developer-oriented don't really fit into what product management can provide. I mean, developers can build those APIs themselves. Since their consumers will be mostly other developers, there's no need to manage them as a product. In the end, those APIs will be consumed in technical environments, where the usual product management mindset isn't needed.
But, why are there APIs, in the first place? Isn't the ultimate goal of an API to enable the integration between products? In that case, you could say that all APIs, somehow, are a part of a product. APIs integrate products and, even if you don't see them as something that can be monetized, someone else will. Your internal APIs can directly or indirectly help you and your company build features, so they're enablers of your product. Your public free APIs will surely be integrated by someone into a product that you don't control. Your developer-oriented APIs help engineers build products. In the end, all APIs are, directly or indirectly, a part of a product.
Your APIs will carry your name however they're used. Even if one of your APIs is being consumed indirectly through an application that integrates it, your brand is at stake if that API doesn't work as it should. Not understanding how an API can influence the quality of products that integrate with it leads to bad alignment with the needs of users. Sooner or later, your business will be hurt by friction introduced by your API to third-party users.
Someone has to be the guardian of your APIs, then. Whether you call that person a Product Manager or something else doesn't really matter. What's relevant is what that role encompasses. According to Deepa Goyal, author of "API Analytics for Product Managers," there are a few traits fundamental to anyone doing API product management. The first one has to do with defining the API strategy. It involves creating a plan that aligns with business objectives and guides the design, implementation, and management of the API. You start by clearly identifying the goals that the API will help you achieve. You then outline the entire API lifecycle, including design standards, development processes, security measures, and scalability considerations. Likewise, you also identify and document integration with existing systems, ensuring compatibility and interoperability. Finally, you implement robust security measures, adhere to regulatory requirements, and establish analytics and monitoring mechanisms.
The second skill of an API Product Manager has to do with managing the development of the API. This skill includes being able to plan the implementation, testing, and deployment of the API. This requires a lot of technical knowledge and collaboration with engineers. Being able to understand how you can implement an API involves knowing about programming languages, frameworks, and methodologies that not everyone knows. Testing an API requires knowing the importance of contracts, understanding what an end-to-end workflow looks like, and establishing guidelines for unit test coverage.
Something else that requires at least some empathy with developers is documenting the API. That's the third skill on the list. Even if you think your API doesn't need any developer documentation, at least some instructions are helpful. Depending on the complexity of the API, you'll have to fully understand it to be able to translate what it does into something that developers will understand. Documentation is often accompanied by other artifacts such as code snippets or full SDKs, examples, and tutorials that are adapted to the most important use cases.
Analyzing use cases is the fourth skill of an API Product Manager. Without knowing how your API will be consumed, it's almost impossible to understand how to implement it. Even internal APIs have their specific use cases that you should learn about. Use cases play a central role in the definition of the functionality of an API. Another area that depends on use cases is testing. Without knowing how your API will be used, you won't be able to test it and validate its implementation.
Finally, the last skill of an API Product Manager is related to monitoring and performance. Observing the behavior of an API over time is crucial to understanding how it can be improved. This skill involves setting up observability tools, alerts, and regularly executing performance tests to ensure the API operates according to its initial design. It also requires understanding what is needed to troubleshoot any incidents and who to communicate with in case the API has an issue.
So, altogether, these skills form the basis of whoever takes care of an API. I prefer to identify this person as the API Product Manager, but you can call it something else. As you can see, most of the skills of an API Product Manager come from a technical background. However, there's also an overlap with business and customer relations. The role of the API Product Manager is crucial independently of the API's size, scope, visibility, or monetization. Without this figure, all the responsibilities I mentioned before wouldn't be owned by anyone.
While I agree with you that monetization is not what makes an API a product or not, I do have to disagree with the premise that all APIs should be managed as products. In a typical enterprise, there are going to be APIs that, whether with intent or not, are designed for one, and only one, consumer. When that consumer is also controlled by the same team/organization (think one level of hierarchy), it's common that the product management is occurring at a level above the APIs. Trying to do product management at the lower level winds up adding unnecessary overhead.
The questions I would ask to answer the question, "Should my API be managed as an independent product?" are:
1. Does the API represent an interaction point between digital interfaces and back-office business processes?
2. Does your API encapsulate clear business processes?
3. Are there external parties that are potential consumers of the API?
4. Are there teams from outside of your organizational domain (i.e. different internal teams) that are potential consumers of the API?
If any of these are yes, then treating it as a product is probably a good thing. Also note that 1 and 2 go hand-in-hand. There are plenty of APIs that are certainly a point of interaction between digital and back-office, but really don't represent a good encapsulation. If the consumer has to have intimate knowledge of the back office details, it's not likely to make a good product beyond that consumer.