The Business of APIs: What Product Managers Need to Plan For

Share this article:

In today’s cloud computing world, many Product Managers will be faced with the decision of whether to open an API to their users. Open APIs have many advantages, but they also bring significant business challenges. In this post, I describe key benefits and challenges of open APIs, and why Product Managers should treat an open API as its own product instead of as a feature.

As technology advances, there is constant pressure to release more functionality faster. Through APIs (Application Programming Interfaces), cloud software providers are able to leverage each other’s functionality in real-time. (If you are new to APIs, here’s a good introduction.)

To get some context for the widespread use of APIs today, consider the following…

Netflix is able to stream to over 200 different device types thanks to its API.

60% of eBay’s listings are done through their API.

50% of Salesforce transactions are done through their API.

Twitter receives over 13 billion API calls daily.

These companies made huge investments in their open API strategy and are now reaping the rewards. But it’s not just the biggest companies who are in the API game. Companies of all sizes are creating APIs. As a result, the growth and adoption of APIs has sky-rocketed in the last 5 years alone, and doesn’t show any signs of slowing down:

The growth in companies exposing APIs has been driven by the need to deliver more functionality and faster time-to-market. As an example, think about a company launching a new eCommerce site. If every single feature was built in-house, it would take a huge amount of time and investment to build all the functionality needed to run an online store. Instead, the company can leverage best-of-breed software and integrate them into their solution via APIs. The image below shows some integrations they might include in their eCommerce solution.

Each of the products indicated by the red boxes exposes an API that is consumed by the team building the eCommerce site. The Product Managers building those third party products made a business decision to open their API. They had a strategy on how it was going to be consumed and the value it would bring to their users.

Including an open API as part of your product has many business advantages that can boost your success…but also significant business challenges that as a Product Manager you must consider and be prepared for. First, the advantages…

The business advantages of exposing an API

#1 An API allows your customers to innovate at their own pace.

No matter how fast you release new features, you’ll never be able to meet the needs of every single customer. Having an API gives your customers (and their development partners) the freedom to customize your software and build the exact solution they need today, not six months from now when you release the next version of your software.

If your product is targeted towards mid and enterprise markets, then having this ability is a must. Your product strategy needs to inform which APIs you need to build first, so you can expose the most critical functionality as soon as possible.

#2 Having an API enables professional services revenue.

If your customer is looking for a feature you don’t have or needs specific customizations, having an API can help you close the deal and bring in additional revenue in the form of professional services. In Enterprise software, it is very common to have an implementation team that focuses on developing one-off features for specific clients. This also helps keep your core development team focused on developing strategic features that will solve problems for your critical mass of users.

#3 With an API, you can build a partner network.

While your Sales team is finite, a partner network can bring scalability and additional revenue to your organization. Once you have an API, partners can either integrate into your product (like the eCommerce example above) or they can build custom tools and functionality on top of your product.

The key advantage here is that partners will help you sell your product because they want to sell their products or services on top of it. By creating a partner network to leverage your API, you have automatically created new sales channels and have scaled your Sales and Marketing teams in a way that otherwise might not be possible.

Look before you jump: what you need to consider first

Satisfied customers, more revenue, accelerated growth…sounds great, right? Well, before you jump headfirst into building your open API, consider the following:

An open API is not a feature. It is a product in its own right.

Just like any product, an open API needs a business justification, user personas, clear use cases, a roadmap, a revenue model, a pre- and post-launch plan, and specific needs in the areas of marketing, sales, support, documentation, and security. These needs are completely separate from those of your core product, though they should be strategically consistent. In fact, it’s not unusual for companies to assign a dedicated Technical Product Manager to their API and partner/develop community. Engineering will provide a lot of input, but the overall approach and functionality should be owned by the Product Manager.

Open APIs are one of those situations where “with great power, comes great responsibility.” It brings a lot of new challenges, and as a Product Manager, you need to be able to sell the value to the organization and make sure they understand everything that it takes to make it successful. You also need to be able to walk away when it’s not the right decision for your product, or maybe just not the right time to tackle it yet.

Following are important questions and considerations you should address as you develop your open API product plan:

#1 Realize how different the “Developer persona” is from your existing users

Congratulations! You’ve just added a new user persona: Developer. And this persona is radically different from your core product’s business users. Even if their domain knowledge is similar (i.e. both work in CRM or consumer electronics companies), their tools, objectives, and views of the world are very different from each other.

Focus on “Developer Experience”, meaning that your product needs to provide usability paradigms that align with that persona. For example, most developers prefer using an SDK (software development kit) as opposed to coding directly against the API. Providing SDKs in their programming language of choice decreases ramp-up time and allows companies to leverage the training and tooling investments they already have on a particular technology. Other developer experience areas include having a good documentation, good tools, and a strong community.

When building a very technical product for a very technical audience, I do recommend recruiting a Technical Product Manager to lead the effort. The TPM won’t code or design the solution. Instead, she brings a deep understanding of this audience and will be able to navigate it more quickly.

#2 How will you increase your product’s revenue by building an API?

Opening an API can be a big investment. So how will you make money out of it? How will your product and company be better off after this investment? There are many ways to approach this, but here are a few possible paths to capitalizing on your API.

Charge for access. Monetize the API itself by charging for API usage. This approach has worked great for companies like DropBox, but keep in mind that in order to do this, you’ll need to build all the tracking mechanisms as well.
Improve sales conversion. Increase revenue of your core product because the API makes it more attractive and easy to sell.
Sell professional services. This requires the creation of a professional services team, but if done correctly, the margins can be really good.
Sell applications. Use the API as a platform to build new components which you can sell for additional revenue through an app marketplace. Or charge a mark-up on apps built by others and sold in your marketplace. Or both!

#3 Be ready for a significant increase in operating expenses.

Consider this. If your current product targets users in Sales roles, and now you add a new product module for Marketing professionals, then it is very likely that your current staff will be able to support this new user type. Your Sales team can still pitch to the CMO, your Marketing team can create the messaging, your Technical Writers can write product documentation, and your Support team will still be able to answer their questions.

In contrast, when you add a user of type “Developer” into the mix, you probably will need to add technical people to your existing staff, as well as conduct training across all teams to ensure they understand the Developer persona. That’s why from my point a view:

The challenges of opening an API are 50% technical and 50% business.

According to Dr. Rob Adams in his book If You Build It, Will They Come?, companies need to allocate roughly the same amount of budget for Sales and Marketing as they do for Engineering. I think that’s a big lesson. Otherwise, you will likely end up with a great product that will ultimately fail because your company wasn’t willing to invest equally in other critical areas.

Here are some non-engineering areas you’ll need to invest in to support your API:

Technical documentation. Chances are, your normal Tech Writer won’t be enough. You need somebody with experience in technical and API documentation.
Product marketing. Creating the message and spreading the word to developers and CTOs is very different than targeting business users. Make sure you have the expertise in-house or that your company is willing to invest in it.
Sales enablement and Sales support. Enterprise clients usually ask their technical staff to evaluate products that include APIs. Your Sales team needs to have people that can speak to the technical audience and help close the deal. If you are a Technical Product Manager, you will be called on to help close the first deals, but that won’t scale past a certain point. Sooner rather than later, someone else needs to take on that role full-time, or that person will end up being you.
Partner management. Needless to say, building and nourishing a partner network is hard work. Having the API is just the beginning since your company would need to invest in additional people and expenses within Business Development, Partner Management, Marketing, etc.
Support. Your Support team needs to be able to answer questions about the API and understand when it has an actual bug, and when the problem comes from the custom code built on top of the API. Chances are you’ll need to invest in some technical folks to handle the support.
Developer community. Developers communicate, learn, and get their work done in a very different way than business users. Companies with successful open APIs have invested in nourishing relationships with developers and building a community. Developer communities give you external credibility and increase the adoption of your product since developers can get up to speed more quickly.

#4 Security and performance are a must-have.

As you plan your strategy, make sure you bake-in security and performance from the very beginning. Opening your system to third-party developers can open a can of worms. Keep in mind that companies using your API are building their own product, so if your API is slow, buggy, or has security holes, it will affect their product and your customers using their customization.

It’s a big responsibility, so very early on, discuss the security and performance approach with your Architecture team. Define the KPIs, measurement criteria, and QA process before you start development. Otherwise, you’ll end up chasing your tail.

#5 Internally, it can be hard to show progress.

This might not be an issue in all companies, but it’s still worth mentioning. Executives love demos to assess progress, and these demos are usually based around the product’s user interface. The challenge with APIs is that they don’t have a UI—it’s just code. And for most people, it’s hard to gauge progress just by looking at code. There’s nothing worse than losing the trust of your Executive Team due to lack of understanding.

To mitigate this, plan to build small applications with a UI that consumes the services exposed in the API. That will help your audience see that you are making progress, and it’s also a great way to test your API by consuming it in the same way that a customer would. Although the focus should ultimately be on the functionality, and not on a polished UI, this approach may be needed to keep your Executive Team and other departments engaged and supportive. Account for it in your capacity planning, make sure to create stories for this activity, and plan for the time needed in your sprint.

The Bottom Line

Adding an API to your product can bring a significant competitive advantage and increased revenue. In our connected world and the era of the Internet of Things, not having an API could be the difference between rapid adoption or being left behind by the competition. But, as alluring as it might be, you need to consider all the challenges ahead and ensure that your company is ready to support this initiative with not only engineering, but with everything it entails across all departments.

If you enjoyed this post, feel free to leave a comment below and please share it with your network.