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.
Architect
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.
Strategist
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.
Dev Lead
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.
Product Manager
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/
Join the discussion at Hacker News and Reddit
Pingback: HACKERNYTT.se - dagliga nyheter för dig som bygger framtiden
In my experience the Strategist was the person who went to the big tech shows and became ‘evangelised’. They didn’t especially know what they wanted, but they believed it would be good mostly based on trends.
The architect chose the platform and was responsible for ensuring we didn’t get painted into the corner and that we could support the API forever-ish.
The dev lead was responsible for delivering the software on time. However at our company it was such a new technology that the whole project was really an investigation and therefore the project was time boxed which meant, deliver as much as you can by this date ( rather than asking when can you deliver this by? )
The product manager OR product owner was responsible for finding the business value and making decisions which drove the outcome in the most profitable way and to decide on the trade-offs between short term gains versus long-term gains. Actually they struggled because it was too new for them and they didn’t understand how to sell it or many of the intricacies of the technology and market.
It was fair enough that our product managers struggled because our target customers were the developers at other companies. Our end customers were two hops further down the track. There is a saying about eating your own dog food (dogfooding). Perhaps this is a scenario where the dogs are making the dog food! I call it “empathising developer” (copyright 2013 hehe).
The problem is you get into a chicken and egg scenario where the product manager has to go to the developer and ask, what is it that you want me to get you to develop?
You might think that the product manager is an inefficient middleman, however its preferable not to burden the developers with the responsibility of developing something that wins. Its good to pass the risk onto some poor soul with a lot of fortitude, who has the stressful situation of managing a team from a mentoring point of view.
Anyway if you have a bunch of wise, proactive, effective communicators, everything works out fine.
To your point, I think that it’s unfortunately all too common to find that product managers are not wise in the ways of API. To some extent, this post is about imagining what we all want PMs for API development to look like. I agree that it is an important role for developers to have requirements translated into buildable terms…when PMs are merely echoing business wish lists to developers, and then asking how to do it, nobody wins.
Pingback: Who are the best API Product Managers? | API Ma...