Is API Product Management a Role or a Person?

First, thank you for all the wonderful comments, likes, and re-shares on last edition's deep-dive into what makes API product management unique. The topic may have hit a nerve. Or, perhaps, this August's tech news has been slow. Either way, the reaction far exceeded my expectations, and I'm energized that so many people found that piece useful.

In this newsletter, I want to "double-click" on a sentiment that came up during the research phase. I heard it in several places, and people expressed it in various ways. However, Jeremy, a former API product manager, summed it up best:

"-the most difficult part of being an API product manager was convincing the engineering managers a pm should exist for a 'technical' thing they want to own."

Why would an API be construed as only a tech concern? Are there situations where that delegation makes sense? What are the advantages and challenges of different types of employees performing the API product manager role? I attempt to answer those questions and more in this edition of Net API Notes.

Are APIs a 'technical' thing? A business concern? Or both?

Software engineering teams perform lots of work that doesn't require product management. These tasks include code refactoring in various forms: improving readability, reducing complexity, optimizing performance, and resolving technical debt. Other "technical" tasks involve security hardening and patch maintenance, implementing or broadening automation, writing automating tests, performing environment updates, juggling dependency management, and tuning the monitoring and logging strategies. While a development team would need to resolve and prioritize these tasks with more product-centric needs, executing them would require a minimum amount of product input.

So why are APIs seen, at least by some engineering leaders, as one of the "technical" concerns, above? There may be several reasons:

• Since developers are the primary users of APIs, producing the API product requires familiarity with programming, data structures, and software integration. While software product managers may understand the challenges of catering to a broader audience, an engineering team is uniquely positioned to inform these decisions.
• Similarly, building an API necessitates decisions about server infrastructure, data flow, scalability, and performance. APIs also need robust security mechanisms, like authentication, authorization, rate limiting, and data encryption. Implementing these features requires deep technical knowledge that a product manager may not have.
• The API (Application Programming Interface) product requires familiarity with several specifications, conventions, and protocols during creation (HTTP, OpenAPI, JSON Schema). Defining endpoints, methods, and request/response formats are technical details more likely to be understood by a team's technicians than product management.
• Historically, integrations were treated as one-off projects, something to be done on an as-needed basis to existing software capabilities. This legacy might lead some engineering teams to treat APIs as a feature to be added, not a product in their own right.

Because the engineering team can recognize the importance of having this specialized technical knowledge for API development, they may see APIs as "their thing". Coordinating with a product manager to whom they feel they'll have to repeat this information to may be seen as an additional (and unnecessary) "cook in the kitchen".

APIs Without Product Management Are Like Gardens Without A Gardner: Growing, But Without Coherence

Treating the API - even APIs only consumed internally - as only a technical concern risks the following:

Technical Complexity Over User Experience

Engineering teams might assume that as long as the API works and is efficient, it's good enough, overlooking the developer experience (DX). Technical measurements of good (efficient, scalable, maintainable) do not automatically translate to intuitive, well-documented, and user-friendly interfaces, aspects of good DX.

Increased Siloing Between Technical and Business Teams

Most organizations already exhibit some information siloing between various boundaries: different divisions, disciplines, and job tiers. Many corporate policies and processes exist for the express purpose of ferrying info across these boundaries. When engineering excludes product management for all but the most "external", or user-facing API products, these divides are exacerbated.

Lack of Direct Feedback

An API may launch and calcify without someone expressly assigned to cultivate business-aligned success metrics and gather feedback. "Is it running?" is an adequate technical question, but the answer doesn't advance the business agenda. Unlike user-facing products where feedback might be more immediate and visible (e.g., app reviews, user surveys), feedback for APIs can be more indirect. And hunting down that feedback and squaring it with existing priorities may not be obvious or prioritized for engineering teams' Business As Usual (BAU).

Misunderstanding the Market

APIs, especially in the era of SaaS and cloud computing, can be products in their own right with their own market dynamics. Engineering teams might only sometimes be attuned to the competitive landscape, monetization strategies, or market demands for APIs like a product manager could be. While this is less of an issue for an internal API, misses here are magnified with a public (or even a partner) offering.

Which is easier? Teaching an engineer product management? Or educating a product manager about technical concerns?

Hopefully, I've established that APIs that are treated only as a "technical" concern create risk. At a minimum, they exhibit weak product characteristics that will age poorly over time. Someone involved with API creation needs to perform the API product management role. But this discussion raises an interesting question: is it easier to train someone on the software developer team to execute the API product management role? Or does it make more sense to educate a software product manager on the technical aspects related to APIs?

The answer is contextual for your organization. A vast degree of how that question is answered depends on the available talent. Some engineers naturally gravitate towards product-centric thinking, while certain product managers might have a knack for technical details.

Teaching Engineers to Perform the Product Management Role

The advantages of teaching software engineers these product management skills include:

• Engineers already have a deep understanding of the technical aspects, which can be called on during decision making.
• Engineers natural problem solvers, which can be applied to discovery and feedback triage involved in product management.
• They have a thorough understanding of the software development lifecycle, challenges, and constraints, which inform planning and prioritization.

The challenges of expecting someone on the engineering team to perform the product management role include:

• Shifting from a solution-centric to a problem-centric mindset can be challenging; engineers often focus on how things work, while product managers prioritize what to build and why
• Development of soft skills and communication abilities to interact with a broader range of stakeholders
• Learning about essential product management skills that might be new to engineers, like market analysis, business strategy, and monetization

Teaching Product Managers the Technical Aspects of an API Product

On the flip side, an organization may feel that imbuing their product managers with increased technical training is appropriate. The advantages of this approach include:

• A heavy user-centric focus, given product managers' traditional emphasis on prioritizing user needs
• Alignment with the bigger picture, market positioning, and business value that product managers bring to the table - aspects contribute to the success of an API product
• A higher likelihood of collaborating with diverse teams

However, this approach presents challenges:

• Product managers might need a deep dive to understand technical aspects, from authentication protocols to rate limiting, to make correct decisions
• Product managers may lack the "hands-on" experience building and integrating with APIs, which can make understanding and empathy for the problems to be solved more difficult
• Technical jargon, tools, industry trends, and platform constraints all require a certain level of understanding to provide greater certainty for planning and prioritization

Both efforts come with their respective challenges and advantages. In either case, success depends on the amount of organizational support available for the individuals performing the product management role.

Who performs API product management in your organization? What benefits does that provide? Are there any downsides? I'd love to hear from people what they've seen work and what others should seek to avoid. If I get enough responses, I'd love to collate them for a future follow-up issue.

Milestones

• I previously wrote about Reddit's API rate hikes and the angst it caused among the communities there. The fallout continues, as described in this Morgan Sung article on TechCrunch. Primarily, several large, well-known subreddits that lost their volunteer moderators are shadows of their past selves.
• Gordon Moore, the Intel co-founder, philanthropist, and namesake of Moore's Law, died at his home in Hawaii. He was 94. One of the many things Gordon was known for was his modesty. In 2005, he referred to the law that bears his name as "a lucky guess that got a lot more publicity than it deserved."
• Finally, I wanted to mark the passing of Stefan Tilkov. A frequent conference speaker and self-proclaimed "RESTafarian", Stefan was a luminary of the software space for as long as I've been doing whatever this is. In fact, he was even doling out guidance on Erik Wilde's YouTube channel as late as last week. While I never met him in person, I always appreciated his accessibility and the handful of interactions we had over social media. I'll miss his thoughtfulness.

Wrapping Up

A rousing welcome to the newest newsletter supporters, Ruby and Ann! It takes time and care to put together an issue. Sometimes, like talking about Product Management, I may have an inkling of what I'd like to express but I run it past multiple people first for a sanity check first. If I was beholden to advertisers, I'd have to print whatever I had at the marketing deadline - I wouldn't be able to hit pause while exploring a tangent or following up on some intriguing feedback. I'd be beholden to someone else's schedule and I'd fear that the overall quality would suffer.

Additional supporters also mean I can entertain more audacious projects. Based on the API Product Management reaction, additional analysis on API-related hiring trends, job descriptions, and salary expectations seems beneficial. However, one of the most promising datasets I'd like to use for that research (848 million job listings sourced from six different sites) starts at $800-a-month. (If you know of a more affordable dataset or alternative access for similar information, I'd love to hear from you.)

Obviously, that's more than "cover my caffeine" money. But continued support from fine folks like Ruby and Ann have me thinking bigger. In the meantime, free newsletter subscribers continue to enjoy ad-free and non-paywalled information. My subscribers make that possible.

Thank you!

Till next time,

Matthew (@matthew on the fediverse and matthewreinbold.com on the web)