API Product Management is a field growing in both size and importance. As more and more companies implement their own APIs and create dependencies on the APIs of others within their own organisations, the ability to design, develop, release, and improve your API product becomes more and more critical for digital companies.
A good API product manager needs to be able to properly identify product opportunities, support the actual development process, collect and act on feedback through multiple iterations, and know how to monitor and measure success for the product. In addition, they need to enable improvements for APIs already released into the market and in use by paying customers.
That's quite a bit to handle. Let's take a quick tour of the seven key aspects of successful API product management.
The first key to a successful API program is facing the fact that the only good reason for APIs to exist at all is to solve a problem for a target audience. And by audience, we mean more than something as vague as "web developers" or "database engineers." Like any product, you need to focus on who your customers are, what problems they need to solve, and how they typically solve them. Locking in these three elements will give your API product a decent chance of success.
A good example of a target audience definition is something like:
"This API is designed to help front-end browser app developers create real-time traffic graphs by dropping a predefined customizable HTML block into an existing browser page."
Here, you can see all three elements:
|
NOTE: |
But knowing your audience is just half the story. You need to make sure your offering is profitable for your company, too. It doesn't make sense to release a great product that costs so much to maintain and operate that you consistently lose money in the process. In other words, your API product needs to be "business viable". You have to solve the problem for your target audience AND make a profit at the same time.
Tim Brown, former CEO of the design and consulting firm IDEO put it like this in a 2008 Harvard Business Review article:
"[Use] the designer's sensibility and methods to match people's needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity."
There's a lot going on in that quote but it all boils down to:
Once you have a handle on both your audience and your market, you are ready to actually create an API product and test it in the marketplace.
The process of developing an API product is similar to developing any other type of product. You need to create some prototypes, test them with your target audience, refine and adjust as needed and, finally, release the product into the market.
The good thing about working with APIs is that you spend most of your time in the virtual world instead of the physical realm. Real-world products like consumer goods, automobiles, etc. go through a costly set of prototyping and testing phases long before they reach the point of "business viability" that we identified earlier. Often even the product packaging needs to go through the same cycle of test and refinement. APIs need the same attention to detail, too.
When launching an API product, you need to have a good deal of design detail captured and documented before you turn programmers loose to actually build your product. In his book, "Principles of Web API Design", James Higginbotham outlines a pattern for collecting and organising your API product details in his ADDR lifecycle process:
Align: make sure business, product, and technology are aligned
Define: map the identified customer requirements to viable business implementations
Design: do the work of actually designing an API that meets the defined requirements
Refine: through testing and feedback, improve the product design before release
There are lots of details to explore in ADDR that I won't cover here and there are other API product-centric methodologies to consider. The key element to understand here is that—just like any other product—you need to spend time diligently defining, designing, and refining your product before committing expensive engineering resources to creating the API.
|
NOTE: |
Another key element you'll need in order to build a successful API product is the right set of Key Performance Indicators (KPIs). You can use KPIs to monitor the way customers are accessing and using your API. This includes tracking the way potential customers find your API and the way their onboarding process goes (e.g. the way potential customers turn into actual customers). For example, you can monitor the number of new user sign-ups you collect. A high rate of sign-ups might indicate your marketing efforts are paying off.
You can also monitor the steps new users follow in order to get to their "Time to First Hello" moment—the moment they actually implement a working version of your API. You may find, for example, that new users start their onboarding process but never get to a successful "First Hello." This might mean your product documentation is inadequate, there are bugs in your onboarding process, or that that API is just too hard to use.
|
NOTE: |
Finally, you can use KPIs to track how customers use the API in production. Using the graphing API example mentioned in the section about target audience above, you can use KPIs to track things such as:
|
NOTE: |
Throughout the process of designing and implementing your API, it is important to collect—and act on—feedback from both your potential customers and your own internal developer team. Whilst KPIs can be helpful, you need more than that. Specifically, you need to hear from the people building and using the API, too.
The team tasked with implementing your design will likely be experienced API users themselves. They can provide important feedback on just how easy it is to understand your API documentation and whether your design is pushing the boundaries of stability and performance within your own technical infrastructure. Remember Tim Brown's comments (see above) mentioned "technologically feasible." Your own engineers can alert you if your design runs the risk of infeasibility.
Getting feedback from potential users is critical, too. Be sure to identify a set of customers that meet your design criteria (see "Developing Your API" above) and ask them to give you feedback throughout the product life cycle. And you don't need an expensive, time-consuming approach to taking advantage of user feedback. Publicis Sapient's Ronnie Mitra recommends what he calls "Participatory Design" as a viable, low-cost option for collecting and acting on feedback from your user community.
|
NOTE: |
As mentioned already, one of the advantages of working with API products is that you are spending most of your time in virtual space, not physical space. It is much easier, less risky, and more cost efficient to modify an existing API product than it is to update physical products such as consumer goods, clothing, and cars.
Kent Beck famously said that “Optimism is an occupational hazard of programming: feedback is the treatment.” One of the most critical things we learnt, first from the Agile, then DevOps and then Cloud Native movements, was the importance of ever tighter feedback loops between both developers and the business, and between developers and the code they produce.
One of your super-powers as a product manager is the ability to leverage early user feedback to influence the initial design and roll-out of your product. For example, early user feedback for your graph API might give the idea to package common use cases into HTML "snippets" that users can just drop into an existing HTML page. You can think of this as the "Idea to implementation" pattern. It is very powerful in early stages of your API development process.
This ability to collect and react to early feedback is an important part of the "Refine" element of Higginbotham's ADDR process mentioned above (see "Developing the API"). Paying attention to feedback and iterating on your design and development process will get you closer to your goal of releasing an API product people will actually use.
Even after you release the initial API product into the marketplace, you can leverage customer feedback as a way to improve your product through iteration. This is not limited to fixing bugs. You can solicit feedback from select target users and, if that feedback can help you match your audience definition goals and improve your product's business viability, your team can engineer a product update and release it in a controlled manner (see "Dealing with Change Over Time" below). This is your "feedback-to-feature" loop.
|
NOTE: |
It is also important to pay attention to the way your API product is marketed. APIs are unique products. Typically your target audience is a set of programmers and/or engineers charged with creating end-user solutions. In other words, the end-user is not your primary marketing target.
Another challenge you'll run into is that your primary audience (programmers and engineers) don't always have the purchase authority to licence one or more API seats for their company. Instead, the people with the authority to approve expenditures and negotiate contracts are a completely different audience—one that may not really understand any of the technical details of your API product.
A proven way to tackle this multi-segmented marketing challenge, according to the book "API Strategy for Decision Makers", is to focus on an inbound marketing strategy that increases product awareness through a strong developer relations effort that targets your key programmer audience. You can follow that up with a freemium model that encourages user sign-ups in order to draw customers into integrating your API product in their end-user solution. Once this happens, you're likely to find that your developer customers become one of your key advocates, encouraging leadership to sign a contract with you in order to put their end-user solution into production with your API.
A great example of this two-pronged approach to marketing APIs can be found in Twilio's "Ask Your Developers" marketing campaign used throughout Silicon Valley. In fact, Twilio's founder, Jeff Lawson has written an entire book on this approach. And the book's title is, of course, "Ask Your Developers".
By making sure you have a strong developer relations campaign that meets developer's needs you can improve your chances that your target audience will represent you well when they talk to their company's leadership about signing a contract with your organisation.
|
NOTE: |
As already covered in "Iteration" above, the virtual aspect of APIs means it is possible to continue to improve the product once it has been released into the market. APIs can be changed over time. Not just to fix bugs but also to add new features.
|
You can learn more about versioning your API products from the article "API Versioning: What is it and why is it so hard?" |
Modifying your API safely and effectively is often referred to as "Versioning" but a more accurate way to think about it is supporting change over time. There are two key approaches to doing this: 1) API Forking, and 2) Backward-Compatibility.
An example of API Forking, the most common approach, is implemented by Salesforce. They update their API at regular intervals, three times each year. And they do this by forking the existing API, making changes, and releasing the new API to run in parallel to the existing forks. At the time of writing, the current Salesforce REST API version is 57 and Salesforce supports versions 31 through 57. That means there are over twenty simultaneously supported versions of their REST API. Forking your API is the easiest way to introduce updates to your product but it can also be the most costly and complicated to support over time.
Another approach for supporting change over time is the backward-compatibility method. An example of this approach is Amazon's S3 API. This product has been in the marketplace for about 15 years and has undergone many updates. However, the very first release of the API is still supported by the current API. If you created a client application that uses "version 1.0" of the S3 API, that client application still works today—without you making any changes to your own code.
Werner Vogels, AWS's Chief Engineer has stated that one of the six rules of AWS's API product strategy is to "Never Break Backward Compatibility". That means every update to the product MUST NOT break any previous releases of that API. Supporting backward compatible changes can be more difficult but can also reduce costs in the long run.
|
NOTE: |
The job of an API Product Manager is a challenging one. You need the skills to deal with the complete API product life cycle from idea to release and beyond. That means supporting a design program that successfully identifies target audiences and matches their needs with business-viable solutions.
You then need to support engineering and programming teams as they convert your detailed design into working prototypes for iterative review and testing finally resulting in a production release into the marketplace. And, once released you need to continue to gather feedback, monitor key performance indicators, and improve the production API through a controlled program of change over time.
The good news is that a successful API product can last many years, solve new problems over time, and provide reliable review for your organisation.