The API-as-a-Product strategy is gaining traction among developers who seek to expose their API to the outside world. With a suitable business logic layer around a service, productizing your API can be a relatively straightforward method to monetize your functionality and data on a per-call basis. However, the API product approach can also greatly benefit indirect API business models, private APIs, and partner-to-partner integrations.

Just as product owners seek to design sleek and usable products that consumers love, API developers should consider how they can apply a product technique to their APIs, no matter how or where they’re consumed. Doing so means improving the documentation around the service and setting higher benchmarks around availability and ongoing maintenance — items that significantly improve the onboarding experience for developers. API owners who adopt a product perspective tend to also understand usage patterns better and are more open to human feedback to refine the offering further.

The Product Mindset

What does it mean to apply a product mindset to our APIs? Before answering that, let’s consider what product management must take into account for generic products and services:

• Design: The product must be high quality and serve a specific need.
• Production: The product must be amply tested before release.
• Distribution: The product should be positioned to be easily purchased or consumed.
• Relationships: The producer must maintain the long-term integrity of the product, upkeeping relations with suppliers and users in the network.
• Profitability: The product should deliver real-world business outcomes for the producer.
• Safety: The producer should ensure the product causes no harm to the consumer.
• Customer Experience: The product or service should be intuitive and iterable upon user feedback.

These are just some highlights of the many facets of product development and ownership. Interestingly, if we apply these principles to APIs, we see many parallels. High-quality APIs are designed around common web standards and built to fulfill the needs of specific programming tasks. Quality APIs have navigable documentation that is easy to understand. They ensure backward compatibility and provide alerts to avoid breaking change. Safe APIs also adopt complex token handling strategies to ensure secure integrations that don’t expose sensitive data.

In a recent LiveCast, we brought in API experts Jason Harmon, Stoplight, and Shelby Switzer, US Digital Service, to talk about what it means to treat your API as a product and the benefits therein. Below, I’ll review some highlights from each presentation to further discover how to apply a product mindset to your APIs. We’ll explore the benefits of treating your API as a product and consider methods to improve the human experience associated with these tools.

Aligning Around API-as-a-Product: See The Entire Network

Jason Harmon has spent years in the API-driven SaaS world at Expedia, Paypal, and Typeform, and also hosts API Intersection, a podcast that interviews key players in the API economy. To put it short, he’s seen many strategies and has a solid perspective on business success in this economy.

There are many ways to go about API productization, Harmon says. For example, in 2013, John Musser identified 20 API business models on the market. Since then, the space has birthed even more monetization strategies. It’s easy to quickly dive into the nitty-gritty technical details of how you want your API to be constructed and delivered to consumers.

But before touching any code, it’s essential to take a breath and answer the business growth and customer-centric questions first, Harmon says. Due to their technical nature, developers tend to think of APIs as only technological artifacts, when in fact, “your API is just another product,” he reminds. “A healthy dose of old school product management goes a long way.”

“Come for the tool, stay for the network,” said Chris Dixon in 2015. Harmon recognizes that a critical piece, often overlooked, is the relationships forged through an API offering. As we’ve covered before, the network effect benefits of an open API platform can greatly overweigh direct monetization techniques. Thus, Harmon encourages API developers to consider potential values beyond direct usage.

Instead of viewing it as a traditional pipeline, think of the API like a marketplace, he encourages. “Know who the customer will be in the business relationship that you will be building. How can you succeed together?” For example, automating connections between suppliers could be the lifeblood and true value proposition for a transactional platform, as was the case for Expedia. Or, if the API is directly monetized, it should enable free tiers and a path for future scalability. He acknowledges that networks can take years to form, but when they’re successful, it’s a substantial win-win on both sides.

Of course, you’re bound to hit certain roadblocks when trying to get an API endeavor off the ground — especially in larger organizations that require executive sign-offs. In his experience, Harmon recognizes that getting business buy-in can be a tricky process. To get buy-in, communicate the benefits in a way executives can comprehend. “Getting caught in technical weeds will do you no good with MBA types,” he says. Instead, present realistic business outcomes, such as reducing customer churn, the network effect, or the potential for more seamless partner integration. When pitching APIs, it’s a good idea to anticipate your expenses too. (Thankfully, we’ve already estimated the total cost of running an API product here 😉).

Know Thy Dev: Use Human-Centered Design

Even intergovernmental software collaboration could take a page out of the API-as-a-Product book. Shelby Switzer is another API trailblazer with a unique perspective on how civic, government, and healthcare arenas utilize APIs to better interact with data. Throughout their career at US Digital Service, Healthify, and other organizations, Switzer seems to have identified one resounding truth to API use — it’s all about human empathy.

Human-centered design is a theory popularized by DesignKit. They define human-centered design as “a process that starts with the people you’re designing for and ends with new solutions that are tailor-made to suit their needs.” As one might guess, these principles can be applied to many different schools of thought around design for physical and digital products. Regarding APIs, thinking more about the human interaction point can bring valuable dividends.

Switzer emphasizes the need to incorporate human-centered involvement at every stage of the API product lifecycle, which they generalize into three main phases. First is the inspiration stage, in which you find your audience. Here, it is critical to discover who you are trying to reach and why. Switzer recommends garnering user empathy by actually going on-site to learn more about how end-users interact with your tool. Of course, in the age of COVID, this may equate to interviews through the screen.

The second phase is ideation. This involves iterating with developer consumers, listening to feedback, and acting on it. Rapid prototyping with a tool like Spotlight or API Blueprint and spinning up a Node.js server to quickly mock endpoints can underline user experience issues and highlight room for improvement. Switzer even suggests taking the hackathon concept a step further — perform equitable research by offering financial incentives for product feedback.

Lastly, the third stage is implementation. This involves defining what success looks like for you. And, as Harmon explained, too, APIs are only successful when developer users are successful. This success must be supported throughout the entire API lifecycle, as well. Reminds Switzer — “iteration doesn’t stop with the launch.” Though we all want backward compatibility, the truth is APIs will change to deliver new features. APIs thus require a continual feedback loop to collect feedback and implement changes well after version 1.0.

Nail The Human Experience

Perhaps the most important takeaway is the human experience aspect. Though it may seem like API consumers are just scary murderous robots, jokes Switzer, on the other side of the screen are actual human developers trying to integrate multiple services into a chain of interlinking APIs. These workflows will only get more complex as the industry expands, meaning that quick and easy API onboarding is crucial to maintaining a successful API strategy.

Also, measuring success in an API business venture doesn’t just boil down to the financial return. Often, it is the network effect or marketplace strategy, as Harmon calls it, that defines success. Other metrics that may indicate API sucess include:

• Total user numbers, like the number of monthly developer users.
• Average usage details, like average requests per minute.
• Onboarding statistics like Time to First Call (TTFC).

However, Harmon cautions against entirely relying on a TTFC KPI, as this isn’t always an indicator of accurate, valuable usage on the consumer end.

I hope you enjoyed watching our Treating APIs as Products LiveCast. If you have ideas for our next event or want to participate as a speaker, feel free to pitch a talk here.