By Gregory Brail and Keith Danekind
On Google Cloud’s Apigee team, we’ve repeatedly observed the importance of outside-in strategies to digital business execution, and to the development of API programs in particular.
Successful API programs not only fulfill integration projects but also treat APIs as products that empower developers to create new applications and digital experiences — that is, they treat developers as a type of customer, and they seek customer data from outside the enterprise to inform their strategies.
Even if a company makes its money from end consumers, for example, it may work with third-party developers to build applications and connected experiences with its APIs to help it reach those end consumers. This relationship only works if the company treats developers and consumers as different customer constituencies whose experiences matter. Likewise, a business’s internal developers may play a critical role and are no less deserving of intuitive, productivity-boosting experiences.
Part of a business’s outside-in perspective should focus on the experience application developers have using the business’s technology platform and on using developer feedback and data to shape strategies and roadmaps.
This concept is simple enough in the abstract — but what does it actually look like in practice? To illustrate how outside-in strategies manifest in the real world, and why they are important to software-driven businesses, we’ll look at the situation from both sides of the coin — the developer’s experience and the experience of the API team responsible for serving that developer.
The Developer’s Experience
Most application developers are focused on creating user experiences. They want quality data from somewhere but they generally don’t want to be troubled by backend complexity or have to go through a lot of trouble to get the API that will let them access the data.
If an API provider isn’t offering its APIs through a self-service developer portal, it probably isn’t meeting these developer expectations — just like a retailer without an e-commerce presence isn’t meeting the expectations of end consumers.
A developer portal should be a one-stop shop where developers can find, access, learn about, and experiment with APIs. At minimum, it should let developers browse an API directory, sign up for API keys, and access documentation and sample code. In our experience, enterprises that build robust developer communities are likely to also include testing tools, blog posts and forums, reporting features to help developers understand how their applications are performing, and more.
In some cases, the portal is not only a mechanism to let partners easily access a company’s digital assets for shared innovation but also an opportunity to directly monetize digital assets. If an API provides access to something valuable, in other words, lots of developers will want to use it, and demand may in some cases be so high or so passionate among certain groups that the API itself can establish a new line of revenue. A portal may include a variety of API packages from which developers can choose, for example, from free trial packages, to options that let developers share revenue from their apps in exchange for API access, to paid packages that provide different levels of traffic overhead or feature richness.
Whether developed for monetization or simply to improve developer productivity, it is not uncommon for API teams to assess their portals based on whether a developer can go from accessing an API to “hello world” within 30 minutes.
Here’s an example of a simple developer portal from a fictional API provider that specializes in weather data. What we’re seeing here is this API provider’s — this company’s — developer experience.
An application developer can visit this portal and start reading about what APIs are available and what can be done with them. It even includes sample code to help her get started.
Scrolling down the page, she’ll encounter a way to start experimenting with the API immediately, with 100 free calls included — very convenient for someone looking to quickly try out an API to see if it is suitable for her application.
Clicking in, she’ll find a list of APIs in the left column — one that will look up particular weather stations, one that will return temperate data, and one that will return wind data.
Suppose she decides to try out the weather station API. She’ll immediately find some documentation to read through and a “Try this API” button — all very easy to navigate, and all arranged so it’s easy for her to quickly evaluate whether these API products match her needs as an API consumer.
After reading through the documentation, she learns that an API key is required. She consequently creates a user profile and registers an application, at which point she receives credentials to try out the API.
Now that she has a key, she can go back to the weather station API, enter her key, and search for weather data based on locations — say, San Francisco.
This returns a series of weather stations near that location.
The call returns data for a variety of weather stations, but she decides to grab the first one and continue experimenting. To try things out, she inputs this weather station location ID into the wind and weather APIs to call data for that specific station for the year 1950.
As expected, this provides the desired data from this weather station near San Francisco. The developer sees that these APIs can easily be used to build applications that enable users to search for historical weather data by location, and she decides it is perfect for her needs.
Before long, she’s showing off her application, which lets users input a location, then returns a list of nearby weather stations, allowing the user to toggle between data from each one.
All in all, this was a very nice developer experience — but what does it look like on the other side of the equation, to the API product manager whose job is to keep the APIs relevant, easy to use, and adopted by the targeted developers?
The API Product Manager’s Experience
Over the last few years, more and more enterprise leaders have recognized that establishing an API product team, headed by an API product manager, is one of the best ways to create productive developer experiences such as the one described above.
For example, in the January 2017 report “Create the Role of API Product Manager as Part of Treating APIs as Products,” Gartner analysts observe, “Application leaders responsible for APIs and integration must support project teams, but treating APIs as products with an accompanying product life cycle increases the chances of digital business success. Creating the role of API product manager is key to managing this project/product dichotomy.”
To fulfill their mandates, API product managers have to keep track of who’s using the company’s APIs. They have to think about how the company’s various digital assets and services can be packaged so that they’re most useful to developers. They should think about different constituencies of developers and whether they should offer multiple packages to cater to different groups’ varying needs.
For example, suppose an enterprise has numerous partners, some of which are allowed to do some things with APIs and some of which are allowed to do other things. One group may be rate limited whereas others are not — things like that. To effectively execute on such partnerships, an API team can’t just produce APIs — it needs management tools to mediate access, define policies, bundle APIs into products, and much more.
All of these are considerations the company should make setting up its developer program (which should include not only a developer portal but also other engagement efforts, such as hackathons, conference appearances, meet-ups, webinars, etc.). But building the developer program is also an ongoing process — and that’s where analytics come in.
Is the response time for an API slowing? If so, is it a sign of creeping systemic problems and the risk that the company might not be able to fulfill its API’s SLA — or is it a DDoS attack? Questions such as these may occur on a daily basis and must be answerable in near real-time. Visibility and analytics are central to the API team’s ability to perform its job.
API product managers should always want to know who’s calling their APIs, what’s being done with the APIs, and how the APIs can be improved. They need to know if APIs are available, if they are responsive, which ones are driving the most traffic in given geographies, which devices are accessing the APIs, and so on.
This information helps them to prioritize roadmaps, polish developer engagement strategies, detect problems before they impact customers, and align executives and other internal constituencies around the value a given API is producing.
For example, if the company providing the weather APIs has robust API management and reporting capabilities, its API team may be able to run custom reports that look not just at the weather station location API’s traffic but also the traffic for specific weather stations within the API — perhaps which of the multiple weather stations near San Francisco is called most often. Such a report might start out of curiosity, but if interesting trends are discovered, the report could provide insights into the use cases that are proving most popular with users. Extremely popular use cases might inspire new products and even new lines of revenue.
Indeed, application developers don’t always use APIs in the way providers envision. This emphasizes that API providers must watch diligently for abuse and implement monitoring mechanisms to help automate the process — but it also emphasizes that API providers should be looking for unexpected opportunities. A developer leveraging an API might bring the provider’s services to a new audience. Sometimes an API can become the backbone for a new industry — such as the mapping and navigational APIs that have enabled developers to create ridesharing applications.
Invest in Developer Experiences
At many companies, developers have traditionally played a backseat role. They’ve been seen as the curators of existing technology investments or as contracted workforces to which website revisions and new mobile apps get outsourced. Anything resembling this approach is no longer viable. Developers are the people who build the digital experiences that drive today’s economy. Few if any businesses can escape this reality. Developers are strategic contributors and are as important as any other players in a business’s product pipeline.
Developer engagement should therefore be a priority. Businesses cannot treat APIs as middleware, as some historically have, but must rather look at them as products for developers. Just like any product, APIs require a team to manage them, customer engagement, feedback cycles, and iteration. Getting the desired results on the outside — great developer experiences that spur innovation and expand the business — demands the right approach to management and operations on the inside.
[Looking to learn more about creating great developer experiences? Check out our ebook series “Inside the API Product Mindset.”]