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.
Great share! Keep posting!
Wow, I just love the way you write. Thanks for the great share. Waiting for the next one.
Great Share! Thanks for the information. KEEP GOING!
Great article, thanks for publishing.
APIs are the best tools that allow businesses to put that data to use — by inspiring innovative developers to create new business opportunities and improve existing products, systems, and operations. You explained it very well. Great article.
software testing company in India
Thanks for sharing such a nice article of The Business of APIs .
This article is very helpful to build a business.
please keep sharing.
That’s cool that APIs could help you with sales transactions and other aspects of your business. I could see how that could help you be more productive, but it would be important to make sure that it is secure. I’ll have to keep that in mind if I decide to start a business and use an API.
Love this! Just what I was looking for.
Very nice article. Thanx for sharing this article with us. I really loved it.
Great Article. Thanks for the sharing
i’m wondering as API’s growth .. will it may use sharing database with business partners ? just to keep secure and agility
Very nice article. Explained with proper diagrams and language that you have is understandable. API testing plays important role in software testing part.
When it comes to API testing, determining who should test them can be a point of contention in some organizations. There really is no simple or easy answer since the really depends on the QA and Development teams themselves.
APIs can be formidable to many, but not to those with some programming knowledge. At one point in time, that knowledge was held only by the developers. However, testers have become increasingly capable of programming since many automation tools now require it…
Great article Daniel!. I am writing my thesis on Platforms and a part of it is about APi’s and their impact on business models. Your article has given me a few more ideas on how to shape the flow of my work. Thank you so much.
A couple months ago Prof. Van Alstyne did bring out a paper about “The Role of API’s on Firms Performance”. The link is below.
Look forward to reading more from you
Fab article. Really enjoyed it. This is exactly the journey the company I work for has been on for the last 12-18months. You hit the nail on the head with the comment on the Exec team and demos. In the last few weeks we’ve done just as you suggested and its been amazing the positive noise it has created. It’s like a light switch has gone on – people understand what we’re doing. I’m not a Technical Product Manager so its all a huge learning curve for me. This has proved to be a good resource – Thanks!
Great article! Best i have read on APIs
Fantastic article. I actually work for a company that has opened up ecommerce API’s and we integrate our platform with various front-end order taking channels. So you hit the example perfectly on the head. there are lots of best of breed components in the value chain that an integrator can pull together by using the right API’s from various external systems. But you are also perfectly correct that knowing the consumer of your API is critical. not only knowing what data elements they need, but also what types of calls and the appropriate granularity. For example, if one call can be used to bundle functionality, that may be the right move in some cases, while in other cases having discrete access to individual components might be better. So it is important to know how the consumers want to and how they are able to use the API based on the systems that they are using to integrate. So more than anything, since a product manager can’t always be an expert in every target system, the most important part of an API product is the ability to support change and communication with the implementation ecosystem.
Nice job! Thanks.
Very informative article! Thanks Daniel.
great and very comprehensive post about various internal and external considerations before embarking on an API project.
I also agree on setting aside a budget for marketing and promotion similar to the engineering budget. Most of that budget will have to be used to drive adoption among developers — ie, “developer marketing” or B2D (business to developers). B2D is substantially different as you also outlined, and IMHO it is crucial to understand and target developers accordingly, which is true for external as well as internal developers. After all what’s the value of an API if no one finds and adopts it?
Regarding your point #5 “Internally, it can be hard to show progress” because APIs don’t have a UI. One way to address this is by using API documentation solutions such as Swagger, which allow to execute live API calls and display request and response with an easy to understand user interface. That can surely help to get understanding and buy-in of the Executive Team.
Thanks Daniel for this insightful piece. I’m a non-technical co-founder of an eCommerce startup, we intend to create open APIs for different categories and sections of our services. I know the power of APIs, been following the trend since 2011. We’re based in Nigeria and the tech adoption is very low, I believe we can encourage more people to get into technology by incentivizing them (opening our API enables them to make money, without keeping any inventories), by building stuffs on our services.
There are lots of untapped opportunities here I believe.
I also believe we would be able to sell more stuff with this, without needing to hire too much salespersons, as our developers would have to independently market our services. It also opens us to a pool of more talented developers that we can hire, going forward.
Do you think this is an advisable approach for an eCommerce startup?
Also, is there any specific advise you’d give considering that I’m a non-technical person, we’re currently outsourcing our development requirements, but we would soon begin hiring new developers.
Very timely article, Daniel! Thank you for the insights.
I am currently working on figuring out all the details for our API (enterprise software) and partner network. I was wondering what are your thoughts on a deeper integration with some of your partners (in our case it is Salesforce: we are looking to eventually build an app on AppExchange)? Also, given all the partners in the network have different data poinst (e.,g. CRM vs ERP, etc.) would you standardize your single API or build a separate API depending on the partner?
a well written article. totally agreed with your points with respect to exposing your APIs to outside world.
Great article! very helpful to build a business case, what is the source of your trends? is there any place i can find more of this market trends? Thank you!