The mantra in the API industry is to manage APIs like a product. Product management could apply to any software. In addition to having great technical acumen, good software managers incorporate planning, forecasting, production and oversight of the lifecycle of all their software. So what is different about, and what makes up a Rockstar API product manager?
First, the aforementioned mantra about treating APIs as though they are products applies to both private and public APIs programs. In other words, it doesn’t matter whether the API is being offered for internal or partner consumption (as part of a private API program) or for consumption by anonymous developers (as a part of a public API program). Regardless of audience, both use-cases demand attention of a talented product manager who is responsible for ensuring the API’s success.
But, there is one product management practice that is more centric to public APIs than typical software management. This practice, along with the others mentioned, truly completes the conventional definition of product management. That practice is marketing; specifically, a particular vertical of marketing. Public API marketing targets a peculiar consumer, the customer-developer. Understanding the nuances of this separates the stars from the unknowns.
Marketing is about communicating the value of a product. The product may be the best in its class, but if its packaging and advertising do not convey that, or at least entice trial, then the product is doomed to a short life.
Let’s look at what “value” and “marketing” mean in the space of APIs.
Value for an API has some major components. First, the API must support the strategy of the business that sponsors it. If the entity that funds the API does not persist, the API will not persist. The strategy may be for compliance to a mandate like the government “open data”, or to recruit developers, or to generate revenue or channel expansion. The primary value of an API, like any product, is to help its benefactor meet strategic objectives. Second, the API must provide valuable data or service to its market. This value may come from a unique nature of the data or service that is otherwise elusive to find if not exclusive to the API. However, often the data or service may be more like a commodity and available from many other API providers. Weather and mapping APIs are examples of this. In this case, the API value can still be established, even amplified, by the third component of value for APIs, the developer experience.
Developer experience can be mastered with just a few understandings. Developers want things to be intuitive, fast, reliable and cool. It’s hard to say which of these attributes is the most important, but it’s safe to say they all have to be there. Don’t try to weigh them out, just make sure they are all strongly present in your API offering.
Which brings us to marketing, because API marketing overflows into the developer experience. How a developer discovers and engages with an API offering is a mash-up of the marketing and the on-boarding process for the API.
The on-boarding for an API needs to be intuitive and fast once the API is discovered. The discovery of an API is great when that discovery is cool, and there is nothing cooler than another developer or industry proponent mentioning or even recommending an API.
A shared notion with API marketing and general product marketing is that word-of-mouth is the very best marketing you could hope for. Developers do what other developers do, but not because they are followers. Indeed, developers are innovative and creative with their solutions and approaches. But the choices of technologies, and elements like selective APIs, definitely are influenced by popularity. Developers communicate and collaborate better when they use common tools. This common context of tooling creates momentum in a solution space for advancing the core element of developer innovation, problem solving.
If it’s obvious an API needs to have these mentioned values, and needs to be marketed appropriately to developer communities, then what is the challenge? There are several, but of those, perhaps the most significant, is that while developers produce APIs, it’s a “developer-marketer” that needs to be put at the wheel to product manage APIs.
Remember what developers find valuable: intuitive, fast, reliable and cool. The challenge comes when developers are creating the on-boarding processes and marketing plans for API programs. They will do what is intuitive, fast, and cool from their perspective of getting things done. However, this will not always produce something intuitive and fast for the consumer, the customer, the other developer you want to use your API.
As an example, assume you are using a developer portal that integrates with the services gateway housing your API. This integration delivers helpful features such as automatically exposing new services and documentation in the public developer portal when a new service is configured in the services gateway. Next, consider a creative API developer that decides to define an abbreviated path (api.company.com/v1/*) in the services gateway, so that the gateway can easily capture malformed paths in calls. The feature described before suddenly becomes a challenge when the developer portal presents the abbreviated path to the public. Now there is an element in the developer portal that has to be overlooked or manually hidden from the customer to prevent clutter. Developers trying to on-board to your API do not want any clutter. We have to remember the customer-developer.
There have been software product managers for a long time but their customer has often been a business user. For APIs, the customer is a developer user.
Understanding the API life cycle and the perspective of the delivering developer is crucial, but so is understanding the customer-developer. Finding someone that can fill that role effectively will be the Rockstar API product manager you are looking for.