When I look around the little village of API specialists within the tech world, there are an increasing number, in the last year, with the title “API Product Manager”. Keep in mind that just a few years ago, this job title didn’t exist. There are so many other roles involved in what it takes to lead the build-out of high quality APIs. In my experience, the de facto product owner (title or not) for APIs needs to represent an amalgamation of roles to be the most effective.
The roles listed here are my perspective on what it takes. However, I’d consider this a survey of sorts, and I’d encourage you to leave comments about your perspective.
It’s easy to forget that in the emerging tech world of API-first development, that we’re really just doing the work of integration. Integrating companies, integrating devices with servers, or perhaps even integrating devices to devices. As such, understanding the systemic layers involved in integrating distributed systems is an absolute requirement. In order to connect systems together, there are often many barriers; firewalls, subnets, intrusion detection, authorization and authentication, just to name a few. These are the traditional playgrounds of integration architects. Understanding the underlying software, networks, and protocols is the first challenge; navigating the politics of tying these silos together takes deft skills in communication and minefield navigation. The technical and soft skills of a software architect are essential to the success of these types of projects.
It’s been said nearly ad nauseum in the last few years; an API without a strategy is fated for irrelevance. Some organizations, namely those whose profits are determined by the success of APIs, have dedicated roles for this (“API Strategist”). More often, the work of API strategy is straddled between a variety of players. Architects and designers have a role in maintaining interaction consistency; business stakeholders want business messaging inline with strategic initiatives; traditional product teams want the API to fit into the overall offering. Projecting a strategic perspective for every URI requires market knowledge, domain knowledge, and business perspective.
One of the greatest coaches in MMA, Ed Soares, once said of his championship stable of fighters, (paraphrased) “it’s like having a garage full of Ferraris and Lamborghinis; you can’t really keep them all running at top performance at the same time”. Running teams of backend developers typically means working with some of the most seasoned programmers in the organization. It takes serious leadership skills to keep high horsepower minds like this motivated, productive, or even content. Finding big challenges that are measurably achievable defines the work of building serious APIs. While this is true of most programming disciplines, the world of building APIs is often ill-understood by the rest of the development organization. As such, it can be a thankless job, which makes the leadership need all the greater. In a smaller organizations, API-oriented teams may look to a technical product owner, or even a senior developer for this kind of leadership. Lacking this ability risks leaving your best developers feel unappreciated, undervalued, and unchallenged.
Finally we reach the newest role in the field. The traditional product manager relies on tools like market research and user studies, and works with sales, marketing, and other stakeholders to create a product that will sell. While this is somewhat true in the API world, the technical nature of these products means there is a huge need to translate the capabilities into business terms. First there is a need to understand what developers want to use. Then there is the task of translating the needs of the business into terms that backend developers can actually build. At same time there is a huge need to explain to the business owners the risks and benefits of opening aspects of a platform to the world. This is a job of communication skills across a very wide range.
What is your experience?
For those of you who have the title “API Product Manager”, what is your experience with wearing many hats, across a wide range? Are these roles solely in the realm of big organizations with super specialized roles?
If your title is something else, but you fulfill these roles, what is your title?
Image credit: http://ehhsdean.com/2013/04/22/how-many-plates-can-you-spin/