Defining the Personas that Drive API Programs

By Gitesh Koli

Application programming interfaces (APIs) are both the glue between systems, data, and applications and the mechanisms that let developers leverage functionality and data for new purposes.

APIs play an integral role in the digital economy and touch participants up and down the value chain, from the business stakeholders trying to understand and shape how their technology investments are advancing digital strategies, to the developers whose API consumption drives those strategies, to the end users and customers who engage with the digital experiences that developers create.

Fully managing APIs and leveraging their complete potential means engaging with this variety of personas. Put simply, API programs and API management solutions should not be devised with just one group of participants in mind.

How APIs Drive Business Value

A retailer might have created an inventory API for its own first-party mobile app— but that same API could be used by developers to make the retailer’s business available to customers in other apps and contexts. This in turn enables customers to engage with the retailer in numerous ways across digital ecosystems; instead of one or two dedicated channels, customers might browse and buy the retailer’s products from within another company’s messaging or social media app, with a voice assistant, or via a physical kiosk. Likewise, a mapping API built for delivery logistics may become the backbone of anything from a ridesharing service, to a large enterprise’s internal app showing campuses and office locations, to a hiking app that helps users find the least-crowded trails.

APIs, in short, express business capability in a portable, extensible manner that makes it easier for developers to innovate. Because of these capabilities, APIs have become essential to businesses’ participation in the digital economy — so much so that analysts and thought leaders are increasingly encouraging enterprises to lift APIs out of middleware obscurity and to support them with an API product team led by an API product manager.

These product roles are one of the most visible parts of enterprise IT’s evolution beyond the “integration tech” labels many have traditionally applied to APIs. But they are only a slice of the personas businesses should think about in order to position their API programs for success.

Enterprises can only hope to serve a community of developers, and the end users for whom they produce new experiences, by defining and acknowledging the various constituencies and contributors that the APIs touch.

Personas in the API Value Chain

At a very high level, these personas can be divided into two umbrella categories: producers and consumers. Businesses that want to grow their API programs — and thus increase their footprint in the digital economy — must consider the full range of personas when evaluating API management solutions and API program strategies.

API producers

API producers include the API architects who design APIs and API developers who create API proxies and integrate backend systems. The success of these APIs and the overall health of the API program are the responsibility of the API product manager, who is typically the program’s central figure. The API product manager oversees the full API product lifecycle, including:

• working with architects, developers, and (if applicable) the technology platform team during API ideation and creation.
• bringing APIs to market and encouraging developer adoption, possibly in collaboration with an API evangelist.
• overseeing the developer portal that provides users access to APIs. Portal management tasks may range from bundling API proxies into products aimed at certain developer groups to establishing policies regulating access and use of APIs to ensuring that documentation and other resources for API users are up to date.
• using monitoring data and analytics to ensure both that APIs are available when developer need them and improved over time.
• communicating momentum to business stakeholders and aligning the API roadmap with the enterprise’s strategic goals.
• aligning with operations teams to ensure APIs are available when developers need them, with security teams to ensure APIs are protected against bots and other threats, and with API designers to iteratively improve APIs based on user data and feedback.

As mentioned, some enterprises also include a platform team that provides tools to enable continuous integration and continuous delivery (CI/CD) and ensures that API architects, designers, and product managers follow established design and security patterns.

API consumers

API consumers are obviously the developers who create new applications and digital experiences by leveraging the data and functionality that APIs expose. That said, even though API consumers share this common trait and are central to the experience of end users, several distinct personas exist.

Strictly within the enterprise, a given API may be consumed both by the team of developers that created it and by other teams and business units throughout the organization. This diversity of users emphasizes the importance of the API product manager, the platform team, and others responsible for ensuring APIs provide a consistent, predictable experience. In the past, it was common at many enterprises for individual teams to create APIs for their own bespoke purposes, without documentation or adherence to standardized design patterns. This meant that many of those APIs may have been effective for the task at hand, such as connecting systems, but could not be easily harnessed for new uses or easily consumed by developers on other teams.

Outside the enterprise, key personas include third-party developers and partners. As with internal developers, external constituents need consistently designed, well-documented APIs— they won’t adopt a provider’s APIs if the APIs are difficult to work with. As mentioned above, providing a consistent and delightful developer experience falls not only to the API product manager, architects, and developers but also to the evangelists or relationship managers who engage with developer communities and cultivate enthusiasm for what the APIs can do.

Different personas have different needs — and all of them are important

Building a successful API program isn’t just an issue of creating APIs; it’s also about packaging APIs for developer needs, establishing control over and visibility into API usage, maintaining uptime and warding off threats, engaging developer communities and marketing to them, measuring the program’s performance, communicating that performance to stakeholders, and much more. The processes and solutions that enterprises invest in must reflect this multiplicity of users, needs, and use cases.

A company may establish a developer portal with documentation, for example — but if the company is truly thinking of the needs of developers, it should also include testing environments, offer analytics to API consumers so they can improve the applications they build against APIs, and so on. Likewise, a company may set up alerts to notify operations teams of API latency issues — but do those alerts merely declare a problem or do they provide insight to help operators remediate it?

It can be easy for enterprises to settle on partial solutions when ramping up their API programs — and to be blindsided when some unexpected use case emerges that the program is not equipped to support. Businesses should keep the users and participants, both inside and outside the enterprise, in mind, focusing not merely on tools and technologies but also on how those tools and technologies intersect with people, roles, processes, and day-to-day operations.

[Interested in tips for building a storefront for your API products? See Apigee’s new ebook, “Creating World-Class Developer Experiences.”]