Why are API Product Managers Hard to Find?

In my day job, I spend a fair amount of time advocating why APIs benefit from a "product mindset". However, despite my best efforts (and one hundred and twelve million "API Product Thinking" search results), well-executed API products remain a rarity.

Companies increasingly rely on API integrations not just to survive but thrive. To make those integrations successful, we need more product management involvement. Unfortunately, however, what often happens is like what I observed at a job several companies ago.

Gary (not his real name) was a nice guy. He was well-versed in product thinking and was happy to rattle off a list of his favorite industrial designers, from Apple to IDEO. After the successful delivery of a software product, he was assigned to a team contributing to a company-wide "AWS for our industry" effort, an attempt to mobilize third parties to create new experiences while addressing underserved markets. This AWS-like effort necessitated creating a host of composable building blocks, or APIs.

Gary jumped in with gusto, applying the same passion for user needs and an eye for visual design that had previously made him successful. However, as the weeks turned into months, Gary seemed to struggle. He waffled on important decisions while attempting to visualize the impact with a UI. While he used these initial renderings to "see" the theoretical end product, they increasingly constrained the possible solution space. What's more, these mock-ups, with their implied look and feel, didn't answer important questions about the API, such as the arrangement of the returned structure or the error object's granularity. Developers found themselves "wrapped around the axle" of imaginary use cases rather than solving the practical details of real-world applications.

Unfortunately, many API product developers find themselves working with a Gary. In this edition of Net API Notes, I will break down the differences between "conventional" software product management and API product management. I'll articulate what makes it unique and what you should look for when hiring your next API product manager.

To the note!

Every API Requires Product Management - Just Maybe Not a Product Manager

Product management is vital to the long-term viability of any API design. Product management defines what to build and why. Determining those things requires, among other things:

• Understanding User Needs
• Plotting a Roadmap
• Navigating Compromises Between Technical and Business Needs
• Managing the Product Lifecycle (pre- and post-launch)

It is not ensuring that dots are dotted and t's are crossed on time; that's project management. It is also not about herding several project cats to a coordinated outcome; that's program management. Regardless of how that product is manifested, software product management crafts a vision for a compelling offering and rallies a team to achieve it.

Even low-level, internal implementation details, like microservices, require someone to play the product management role. Rarely is an interface self-evident; a development team is constantly making decisions on what they're building. What a microservice's reduced scope may not need is a dedicated product person.

API Product Management Is Unique Within Software Product Development

An engineering team member can perform a limited form of product management on a microservice. However, in all but the most minor or most trivial cases, the product management work requires a dedicated professional.

However, the rub is that not all product managers are created equal. When companies embark on an API transformation, they may reassign whatever product managers they already have employed. Or they post job hiring using whatever product management boilerplate lies within their HR systems, not thinking to customize for specific technical considerations. "They can learn the API bit on the job," the thinking goes, "others will do the technical stuff".

There are product virtuosos equally adept at creating great mobile apps, internal platforms, desktop experiences, or APIs. And there are many similarities between software product management and API product management. Several key differences also exist due to the nature of the products and the customers they serve. Individuals who can "do it all" equally effectively are few and far between.

These following subtle but significant differences can trip up otherwise competent product managers.

The 'Customer' is Different

In software product management, the customers are typically end users who interact with a front-end application (the user interface or UI). These users are often non-technical and prioritize usability, aesthetics, and features that meet their needs (the user experience, or UX).

With APIs, the 'customers' are other developers. An API developer experience (or DX) must prioritize, as reported in the 2023 State of API report, excellent documentation, easy discovery, rapid integration speed, comprehensibility, and minimized cost. DX competency is different from UX competency.

The Roadmap Crosses a Different Landscape

In software product management, product specifications are driven by UX considerations, such as user interface design, feature sets, and usability. The product roadmap is then focused on delivering new user-facing features and improving the overall user experience.

In APIs, product roadmaps are driven by integration concerns between internal (or external, like mobile applications) systems, speeding up development timelines, reducing operation and development costs, and improving organizational security. Understanding these issues well enough to make educated decisions requires additional research and technical skill.

Marketing and Monetization Differ

As I've established, much software product management focuses on user interface design, feature sets, and usability. Subsequently, product marketing heavily emphasizes the inclusion or updating of those things to end-users. Monetization is typically based on selling licenses or subscriptions to end users or advertising for free-to-use software.

API product marketing is more B2B oriented. That necessitates demonstrating the value of the API to other businesses, developers, or partners. Monetization can be trickier, necessitating contractual relationships and long vetting cycles before integrations occur. Given the differences in audiences and the value each seeks, the storytelling changes.

An API's Key Performance Indicators (KPIs) Are Different

Key performance indicators (KPIs) for a mobile game include metrics like user acquisition, retention, and churn. As new features are introduced, techniques like A/B testing would be employed to gauge uptake and inform the next steps.

I have a hard time imagining what an A/B test on a service interface would be like - not returning different data to facilitate an A/B test in an interface, but the interface itself changing with the intent of following up with the developer to ask which return structure they'd like better. Instead, API product KPIs typically include technical metrics like uptime, response time, and error rates, business metrics like the number of developers, apps or partners using the API, or the number of API calls made.

Documentation Has an Outsized Role in API Product Management

Software product management has documentation. However, the emphasis often skews toward creating a user-friendly interface - one intuitive enough that additional documentation or training is largely unnecessary. In fact, if users are required to use a manual, it could be argued that the software has failed.

In API Product Management, documentation is a critical and expected part of the delivery. Developers must understand how to use the API, what data or functionality it provides, and how to integrate it with their systems. This documentation often "sells" a developer on a given offering. Because of that, documentation has greater importance to API product management.

More About API Product Management

API product management is a unique and nuanced form of software product management. Finding the right help that "speaks" API can be challenging but can significantly improve the likelihood of an API's success. Whether you're an experienced product manager adapting to the world of APIs, an engineer performing the product management role, or a business leader contemplating your cross-functional teams, embracing the distinct facets of API product management will create more attractive offerings better able to compete in today's interconnected ecosystems.

For more on API product management, here's a throwback to a piece I wrote several years ago while smack dab in a different digital transformation.

Milestones

• Postman has acquired Akita, a maker of monitoring and observability software. At the time of this writing, I couldn't find the terms of the agreement. There's a great write-up of the "making of" the deal in the Pragmatic Engineer newsletter.
• Poly API, providers of "an intuitive, cost-effective platform for harnessing the power of various APIs and event streams", secured a pre-seed funding round.
• RFC 9457 has a new revision for handling problem details for HTTP APIs. It obsoletes RFC 7807.
• OpenAPI is the dominant way of describing net-based API endpoints. However, one challenge that the specification has is describing multi-step workflows across multiple endpoints. To date, that has been left for "other" documentation - addendums that are usually not machine parsable. The OpenAPI Initiative's "Workflow Specification" is working to change that. If that interests you, read Erik Wilde's summary and then check out the proposed standard.
• The U.S. Federal Reserve launched a real-time payments network, the first significant upgrade since the 1970s. Called FedNow, they're looking for API help to build out their "innovation sandbox".

Wrapping Up

Thank you my paid subscribers like the newest member, Barry! People like Barry help cover the cost of grammar software, AI experiments, cloud repositories, and more that enhance this newsletter's writing. Without their support, I'd be tempted to take on advertising, put editions behind the paywall, or sell subscriber information. Thanks to the generous donations of a select few, the remaining majority benefits.

Thanks again!

Till next time,

Matthew (@matthew and matthewreinbold.com)