API product managers are the Janus of the API world. They have multiple faces, looking to both the business and technology to deliver a complete API proposition. Doing this role successfully means looking after several crucial areas:
- Delivering a great developer experience that both defines the business while delivering the technology.
- Defining an API roadmap.
- Defining value through a language common to both business and technology.
The first of these areas – developer experience – involves building a proposition that is attractive to technologists and delivers value for money and hopefully a return on investment for the business. An API product manager does three things in balancing business and technology goals to create a great developer experience, namely:
- Giving the business context.
- Listening to the community.
- Knowing when to stop.
Giving the Business Context
A great developer experience is becoming a fairly well-established formula. Getting it right means providing concise, well-authored and relevant content that captures a developer’s initial interest and gives them everything they need to integrate with your API, from zero to hero.
The key features of developer experience are meaningful to those with a technical background. However, expressing the benefit of a great developer experience to the non-technical side of an organization (the “business”) can be difficult as they lack the relevant knowledge to put the features into context. Giving the business context is critical as they will undoubtedly be bank-rolling any investments in improving or extending developer experience.
A key part of the API product manager’s job is therefore to perform internal marketing and educate the business paymasters so they can make informed decisions on investing in developer experience. The benefit of adding a greater range of languages to the code snippets or creating an SDK to ease implementation won’t always be obvious to someone from the business. Don’t take for granted (but also don’t be patronizing) that business stakeholders understand APIs, instead begin with an API 101 mentality and build up from there.
Internal marketing is not, however just about teasing the purse strings open. An API is an important (and sometimes primary) part of an organization’s product offering. An API product manager should also look to evangelize the API with senior stakeholders so they can understand the basics of why it was created, what it does and how it can be of value to customers. Those stakeholders can then become important champions for the API.
Listening to the Community
An API product manager’s job is more than just providing context. They also need to listen to their external developer community and feedback their wants and needs to the business. They are both the conduit and the filter for information coming from a variety of sources including the industry, standards organizations, forums and helpdesk tickets, and the organization’s API or developer evangelist.
Clearly the feedback an API product manager chooses to share is going to be subjective. It will be largely dependent on the nature of the business and the level of empowerment the API product manager has. The feedback will also vary depending on the product offering, industry and technical capability of the business itself. Examples include:
- Feedback that might influence an APIs pricing structure if acted upon, such as making free trials available or implementing a freemium model.
- Issues with performance or availability of the API that might need money to fix and thus agreement of the business to fund the investment.
- Feature requests that might have regulatory or legal implications, especially in the areas like data protection or compliance.
In this capacity the API product manager is therefore the eyes and ears of the business and is responsible for providing the “on the ground” view, balancing the need to create the developer experience the community wants with business reality.
Knowing When to Stop
Technicians love great tech and a community of technicians can be highly demanding on the tech front. However, developing great tech and toys costs money. There comes a point where extending the developer experience stops giving value for money. Providing the right tools and tech should give a developer enough features to get going but not do their entire job for them or distract them.
An API product manager’s job is channel the demand for developer experience into features and functionality that delivers the most value. This is likely to include known quantities – an interactive console and well thought out and written documentation – but should avoid the frivolous. Indeed, a product manager might come from a technical background so part of their job is to resist the temptation to indulge the technical team and the community. For example:
- Sample apps and code snippets are great. However, providing too many means investment is sunk into their development with no tangible return and a future maintenance cost (unless you are prepared to rely on the community and open source them).
- Your API specification should be structured to communicate the maximum amount about your API while making the delivery efficient and effective. If it makes sense for you as an API provider to put all your endpoints into one specification document then do so. Splitting your specification into multiple documents might make it slightly more elegant and usable for consumers but it shouldn’t cost you money. As long as your developer community can still ingest this information via code generation or in an interactive console they won’t hold it against you.
- Being an API provider is a balancing act between technical elegance and product adhesion. Your technical team may come up with ideas in areas such as versioning that are a technical masterpiece for those who understand the product and the stack inside out. However, they may be hard for an external developer community to understand and readily consume, which might discourage them from using your API. As an API product manager you should judge which side of the wall such features sit.
In summary, be smart about what you channel the efforts of your teams into. You should concentrate on getting the most bang for your organization’s buck, and this means knowing where to draw a line on extending your developer experience.