Why to treat and manage your APIs as products

By now, all of these decisions make one thing clear: You need to treat your API as a product if it is to succeed.

The web — and even at times, ProgrammableWeb's comprehensive public API catalog — is littered with good API intentions gone wrong. Too many businesses have realized they "need APIs" and have created them as a tick-a-box feature without thinking about their broader strategic value. Once an organization creates an API it needs to:

• Maintain the API
• Promote the API
• Onboard consumers (customers, internal developers, partners, etc.)
• Enact governance (rate limits, security, and other management techniques)
• Instill testing and performance monitoring
• Regularly communicate uptime to API consumers
• Provide developer documentation
• Support consumers

An entire API product lifecycle awakens once an API is published, and this can be just as true for private (internal) and partner APIs as with those that are opened to a wider developer audience.

Jérôme Louvel, CEO of API and software development tool company Restlet, says that when an API is significant enough to your business model, you need to consider it as a product and you need a product manager who will develop the team and identify the best workflow. "This key person needs to own the project; they will care about the final business result and will interact with the consumer. It's very important for them to collect requirements and understand the expectations," says Louvel. He says that first you need to identify the developer personas and map their customer journeys (or user stories). Once this is completed, you need to define how this links to the wider business model and vision. After this, the product manager can then document the API requirements.

In line with the team building decisions, Louvel suggests that the product manager select a technical writer early on to help document the API from the start. The product manager will also help select the workflow and tools that the team will use.

Jarred Keneally, group product manager for Developer Relations at Intuit (which makes QuickBooks accounting software), says there's significant usage of the QuickBooks API, with QuickBooks having over 500 apps in its app store and 1,700 applications that are not listed publicly.

Keneally says that as Intuit moved away from a downloaded software business approach to an online Software-as-a-Service (SaaS) model, the entire company began to understand the importance of working with external developers. As Intuit began moving to the new cloud-based model, Keneally says the company identified four main customer segments: consumers, accountants, small businesses, and developers.

"Two years ago, we put developers in as a customer segment. We found that if you're using QuickBooks and one additional app that connects to the Quickbooks API, the customer lifetime value goes up, and it goes up pretty significantly," says Keneally. "We also found that new subscriptions to QuickBooks go up through developers, as third-party apps introduce their customers to us."

Keneally says that Intuit started its QuickBooks developer program in 2001, and "as we realized there was functionality we couldn't build, we saw that external developers could build and offer that to our customers."

"Developer success is something we own and we're making sure devs are successful in our program: the fun bit for me is to make sure these developers are successful just by virtue of being on our platform," says Kenneally.

Keneally says one of the key tools they use to help product manage their QuickBooks API is Postman . Originally an API mocking tool, Postman has grown into a fully fledged API consumption toolkit that can help third-party developers test API queries and responses. API developers can also use it to collate all of the APIs they're interested in into "collections" that store documentation, code snippets, and other supports all in the one place. Given the complexity of the QuickBooks API — which has authorization and authentication requests, for example — using Postman with external developers helps Keneally teach third-party developers how to use the API.

He says that this has also helped Intuit product manage APIs internally. As APIs became the preferred internal technology for connecting various services and functionality, and with over 100 engineers on board, they needed to find a way to help internal teams better use APIs collaboratively. Intuit chose to use Postman to help them improve this collaboration. With Postman, all internal developers could be aware of any changes to a new API as it was being created.

"Our teams are divided by domains and we have five or six domain managers," explains Keneally, referencing a team model similar to Spotify or Buffer. "These teams cover things like accounting, payments, and payroll, and each of those are domains has one or more architects and product managers for each. Postman is where they can collaborate together, and also that's how they keep track of changes. Then teams like myself are bringing in third-party requirements from the Quickbooks API." Keneally says this sort of collaboration speeds up product development by helping keep all teams on the same page when describing and implementing resources. This approach also encourages the sharing of best practices across the organization.

When he was a technical product manager at Esendex, Andrew Seward gave a presentation at ProgrammableWeb's APIcon in London (video below). During that presentation, Seward echoed Keneally's opinion that your API is a product. "It has features, quirks, bugs, customer journeys, things that are great, things that aren’t so great, things that suck,.. it’s got packaging, it’s got instructions, people who love it, and people who don’t love it so much."

Seward goes on to point out that an API has all the same properties as a Mars Bar (the chocolate bar) and asks if you’re not treating your API as a product, then how do you think about things like the target audience, the marketing strategy, the sales strategy, the development plan, and the support process. “It leaves you in a situation where you’re likely to be flawed” says Seward.

Keeping multiple development teams, both internal and external, on the same page is just one role for an API product manager. At Amadeus Hospitality, Product Specialist Melissa Jurkoic has helped steer an API strategy towards success by taking a product management approach.

"At first, no one was ready to discuss how to do things differently with APIs," Jurkoic told API Strategy and Practice in Boston in November, 2016. "I realized I wasn't going to get a product off the ground in a world of complacency." Jurkoic reached out to API stakeholders and leaders across the community and talked with her external business colleagues about how they were leveraging APIs. She says learning from your network is an essential skill for an API product manager.

Reflecting many business trajectories where APIs are created outside any substantial strategy because the business wants to tick off on having an API, Jurkoic inherited a number of APIs that existed without a broad strategy. Amadeus had some sort of inkling internally that they could speed up new product development, better leverage data, and begin opening up to third-party developers, which is why the APIs were created in the first place. But there was a lack of any concerted efforts to make those APIs part of a strategy that could be harnessed as the company needed to continue down a path of digital transformation.

Given that mishmash of previous work, Jurkoic chose API management as the key starting point, as she saw that this would help internal and external developers consume what they already had. "I convinced myself we needed API management. We had APIs, we had the way to connect things, but we had no way to see what was possible," she says. To make that happen, Jurkoic saw the need for an API evangelist. She spoke to directors across the enterprise and enlisted budget from their data intelligence line item. But after securing budget, hiring an API evangelist brought a new challenge. She says they had no template for that sort of position. "I had just disrupted human resources," Jurkoic says. Being unfamiliar with such a position, the HR department was unaccustomed to understanding how to recruit for the role, so Jurkoic wrote the job description based on a Twilio position and they hired someone internally to take on the opportunity.

Working with their API evangelist, Jurkoic's role was now to encourage departments to make use of their APIs, and she again had to fight against internal complacency. Several departments felt that the current system of forwarding data via a ZIP file to partners was sufficient. "But I did not want to be product manager of a ZIP file," says Jurkoic.

Instead, using the budget secured, Jurkoic and the API evangelist built a prototype using Microsoft Azure's off-the-shelf API management product and drafted a press release to share with partners.

Here, using her internal advocacy skills was paramount. "I didn't appreciate prior to this role that you need to understand your audience," she says. When targeting the C-level for example, she needed to understand that good press was a very important goal for some of them. Previously, she hadn't really been paying attention to what their needs and motivations were, but by really targeting what they said they wanted (in this case, a good press message), not only was Jurkoic able to build upper management support, but the process of being concise and describing the API strategy in a press release increased her product management skills. This strategy also helped her bring the API management portal to the attention of third-party integrators.

"I treat my APIs like products," says Jurkoic. "I define market problems, I identify who our customers are, and I work on making sure we solve market problems for those customers."

By matching target personas, use cases, and market needs to their existing APIs, Jurkoic introduced an API product management approach that required little risk internally. However, she does warn that becoming an overnight success with her API work took close to three years. "I started in the role in January 2013. We didn't actually start to gain any traction until 2014, and the press release was written in October 2015. We spent time gaining consensus and momentum along the way, so that our strategy would be tangible. Now we have two whole scrum teams working on APIs, a public API strategy, and we're able to talk about developer experience all the time," she says.

Now that we have made all of the decisions necessary to align our business successfully with our API strategy, it's time to move on to some of the technical decisions that come with APIs. Next in "Part Six: What Architecture Styles and Specifications Format Do I Use?" we look at what decisions you need to make on architecture styles and specifications.