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

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

For context on the widespread use of APIs today, consider the following…

Netflix can 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 considerable investments in their open API strategy and are reaping the rewards. But it’s not just the most significant companies in the API game. Companies of all sizes are creating APIs. As a result, the growth and adoption of APIs have sky-rocketed 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 were built in-house, it would take a tremendous 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 would be consumed and its value 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, having this ability is a must. Your product strategy needs to inform which APIs you need to build first so that 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 need 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 widespread 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 to 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 integrate it 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.

To Learn More

• Behind the Scenes of Dolby’s New Cloud Platform with Stephane Giraudie
• 7 IoT Business Models That Are Transforming Industries
• How to Build an IoT Product Roadmap
• How to Validate Your Product Idea

Look Before You Jump: What You Need to Consider First

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

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. Building an API might also result in specific needs in marketing, sales, support, documentation, and security. These needs are entirely separate from your core product, though they should be strategically consistent. 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 Product Manager should own the overall approach and functionality.

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 sell the value to the organization and make sure they understand everything that it takes to succeed. 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) instead of 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 good documentation, good tools, and a strong community.

When building a very technical product for a very specialized audience, I 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 can navigate it more quickly.

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

Opening an API can be a significant 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 to do this, you’ll need to build all the tracking mechanisms as well.
• Improve sales conversion. Increase the revenue of your core product because the API makes it more attractive and easy to sell.
• Sell professional services. This requires creating a professional services team, but the margins can be excellent if done correctly.
• Sell applications. Use the API as a platform to build new components that you can sell for additional revenue through an app marketplace. Or charge a markup on apps built by others and sold in your marketplace. Or both!

Recommended podcast episode: How to Incorporate Services in Product Companies

#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, your current staff will likely 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 answer their questions.

In contrast, when you add a user of type “Developer” into the mix, you probably need to add technical people to your existing staff and conduct training across all teams to ensure they understand the Developer persona. That’s why 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 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 average Tech Writer won’t be enough. It would help if you had somebody with experience in technical and API documentation.
• Product marketing. Creating the message and spreading the word to developers and CTOs is different from targeting business users. Ensure 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. 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 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 nurturing relationships with developers and building a community. Developer communities give you external credibility and increase your product’s adoption 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 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. Ensure you discuss the security and performance approach with your Architecture team early in your innovation journey. Define the KPIs, measurement criteria, and QA process before starting development. Otherwise, you’ll end up chasing your tail.

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

Showing progress in the development of your API 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 on 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 by looking at code. There’s nothing worse than losing the trust of your Executive Team due to a 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 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.

What To Read Next

• B2B Product Innovation: A Map for B2B Product Managers
• How to Become a Great Product Leader
• An IoT Framework for Product Managers
• How to Use Design Thinking to Build Better IoT Products

The Bottom Line

Adding an API to your product can bring a significant competitive advantage and increase revenue. In the B2B world, not having an API can 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, please leave a comment below, and please share it with your network.