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

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

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 Business of APIs - API Growth

Source: ProgrammableWeb

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.

Leveraging_APIs

 

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

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

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.

39 Comments

  1. Very informative article. You have clearly done an in-depth analysis of the benefits and challenges of exposing open APIs for software products. Also, this article mainly emphasizes understanding the unique “Developer Persona” and the importance of delivering an excellent developer experience, including SDKs, documentation, and community support. I am sure that this one can act as a comprehensive guide for product managers and software development services organizations interested in incorporating open APIs into their product strategies. Keep up the great work!

    • Author
      Daniel Elizalde 1 year ago

      Thank you! I’m glad you found it helpful!

  2. Sankalp Sharma 2 years ago

    Great share! Keep posting!

  3. Dr. Sankalp Sharma 2 years ago

    Wow, I just love the way you write. Thanks for the great share. Waiting for the next one.

  4. Fleek IT Solutions 2 years ago

    Great Share! Thanks for the information. KEEP GOING!

  5. Vinod SV 3 years ago

    Great article, thanks for publishing.

  6. David johnson 3 years ago

    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.

  7. kirankumar paita 4 years ago

    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.

  8. Tyler Johnson 4 years ago

    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.

  9. Charliyn Tran 5 years ago

    Love this! Just what I was looking for.

  10. Vroclav 5 years ago

    Very nice article. Thanx for sharing this article with us. I really loved it.

  11. testvox 6 years ago

    Great Article. Thanks for the sharing

  12. jasa website 7 years ago

    i’m wondering as API’s growth .. will it may use sharing database with business partners ? just to keep secure and agility

  13. Alisha Henderson 7 years ago

    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…

    Regards

  14. Vasu peri 8 years ago

    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.

    https://apigee.com/about/resources/ebooks/how-apis-drive-company-performance

    Look forward to reading more from you

    Regards
    Vasu

    • Daniel Elizalde 8 years ago

      Hi Vasu,
      I’m glad you enjoyed my API article. I recently wrote an post with my take on IoT platforms. Given your area of focus, you might find it interesting as well. Let me know what you think.
      https://techproductmanagement.com/iot-platform/

      Cheers!
      Daniel.

  15. emma 9 years ago

    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!

    • Daniel Elizalde 9 years ago

      Thank you so much! I’m really glad you found the post useful. Best of lucks as you continue moving forward!

  16. Mohammed Anshad 9 years ago

    Great article! Best i have read on APIs

    • Daniel Elizalde 9 years ago

      Thank you Mohammed!

  17. Howard Pressman 10 years ago

    Daniel,

    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.

    • Daniel Elizalde 10 years ago

      Howard, thank you so much for your comment. I like your comment that “the most important part of an API product is the ability to support change and communication with the implementation ecosystem”. Well said!

      Daniel

  18. anusha 10 years ago

    Very informative article! Thanks Daniel.

    • Daniel Elizalde 10 years ago

      Thank you for reading!

  19. Manfred 10 years ago

    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.

    Manfred

    • Daniel Elizalde 10 years ago

      Manfred, thank you so much for your comment. Very good points about B2D. That’s a great way to look at it. Often companies don’t realize how different it is to market and support this audience.

      I like your suggestion about Swagger to show a visual representation of progress made. It also made me thing that modern documentation is very important to have a good “developer experience”. Tools like Swagger, APIary and others is what developers expect today. Having static documentation doesn’t give the same experience and can give the impression of an outdated API. Would you agree?

      What other modern API documentation tools would you recommend? I’m very interested in the topic.

      • Manfred 10 years ago

        Absolutely! You don’t want static documentation and a top developer portal is one central element of an outstanding developer experience (DX). The portal should provide the possibility to execute live API calls. That all contributes to lowering the barrier of adoption.

        Currently, the top API documentation solutions are Swagger, Blueprint and RAML. Kin Lane, the API Evangelist, did a lot of research about these. You can find one of his articles here: http://apievangelist.com/2014/01/16/api-design-do-you-swagger-blueprint-or-raml/
        We provide our own API documentation, too, which is called 3scale Active Docs and actually is based heavily on Swagger.

        Other useful tools for developers for API testing (before and after adoption) are APItools.com, Postman, and Runscope Radar. I found all of them quite useful for inspection but also for presentation of an API.

        Manfred

        • Daniel Elizalde 10 years ago

          Thank you for your great comment and insight. I’m familiar with some of the tools you mentioned, but not all. Got some reading to do!

  20. Chris 10 years ago

    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.
    Thanks

    • Daniel Elizalde 10 years ago

      Hi Chris. Thank you for reading and for posting your comment.
      I think eCommerce is an area that can definitely benefit from exposing APIs. It allows your company to integrate with many 3rd party providers that can provide value to your product without you having to develop that functionality. For example, look at all the vendors that go every year to the top eCommerce shows in the United States (like NRF or IRCE). The expo floor is full of companies that enable incredible functionality if you provide an open API to connect to them. It’s a very competitive market, but the opportunity is there.

      My first recommendation is to make sure that you have a clear roadmap (and business plan) on what functionality you want to expose through an API and what is exposed through user interfaces. It’s important to understand who is your main audience and why somebody would use your API. Like I mentioned in the post, opening an API opens possibilities, but it also adds the complexity of a new user persona. You’ll need to provide documentation, support, etc, so make sure you have the right budget allocations. Also, you might not need more sales people, but you’ll definitely need marketing and business development budget to attract developers and create partnerships with other companies that consume your API. APIs are very complex so the “if you build it, they will come” approach is very risky, specially for startups where the funding might be more constrained than in other, more established companies.

      The second recommendation is to hire a very strong Technical Product Manager that can help you navigate through the complexities of the API world. Don’t leave the strategy and business model of your API exclusively to the development team. An API can be a product on itself or at the very least a very, very complex feature. It’ll be important to have somebody experienced you can trust that understands the business side, understands your market and understands the technology to make the right roadmap decisions that will lead to success.

      Hope this helps and best of lucks!

      -Daniel

  21. Katia 10 years ago

    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?

    • Daniel Elizalde 10 years ago

      Katia, thank you for reading the post. Great question. I think deeper integrations with key partners are very important. That way you can offer your customers a robust and differentiated experience. It also helps customers buy into your product because they know you already connect with software they have invested heavily in (for example Salesforce).

      In my experience, I’ve been more successful providing a generic API instead of creating specific ones for each partner. Each partner will be different, so instead of providing an extensibility point, you’ll be providing just a hard integration. Your solution might not be as scalable since new versions of the partner software might not work with your existing API, plus you might not be able to integrate with other similar partners. For example, if you have a very specific API for SalesForce CRM, you might not be able to reuse it for CRM solutions from other vendors, and definitely not for other types of systems like ERPs.

      My suggestion is to understand the data that needs to be shared between systems and build a generic API that is capable of reading and writing that data. That way, your API can be reused to connect with any system. For example, creating an API that provides “CRUD” access to your “customer” data, would allow you or your partners to build an integration with any CRM, ERP or any system that requires access to customer data. This generic approach also enables you or your partners to build custom tools for import/export or even data migration tools. You can even take it a step further by providing “events” on CRUD operations and that way you can provide real-time integration with other systems. This approach is very flexible and will allow you to connect to any system and even empower you and your customers to build applications that you can’t foresee right now.

      What do you think?

      Thanks again,
      -Daniel

      • Katia 10 years ago

        I agree, Daniel. Great points, thank you.
        We have a list of about 20-25 of partners we would like to establish relationships with and make them a part of our Partner Network. I absolutely agree with you about making an API as generic as possible based on some common rules and logic (unless one day we decide to go further down and create almost custom connectors – like MuleSoft does – but it is a different business model), hence, the way I was thinking to approach it is to break down partners into categories: CRM, ERP, PoS, etc., create generic APIs based on the category rather than creating just one single API (hard integration, reading and writing data only) since data points will vary significantly going from one category to another (e.g. customer info vs pricing info vs inventory, etc), yet identify the most common denominator in each category – a 3rd party tool that is used by most of our customers (e.g. SF would lead CRM category, Oracle will lead ERP, etc.) – and build custom APIs for these ‘leaders’ in the category to reduce friction during pre-sales process, differentiate ourselves and provide more value to new and existent customers. What are your thoughts on this?

        • Daniel Elizalde 10 years ago

          Hi Katia,
          I think that’s a good approach. Using a key partner to guide your initial development is good because it guides you towards concrete targets and actually get something done as opposed to working on an abstract design making too many assumptions. On the flip side, I think it’s important to always step back and look at every design decision with a generic mindset. That way, even if you are building something based on a key partner, you are always making sure you build something scalable and don’t paint yourself into a corner.

          Good luck opening your API. I’d be curious to know what you decide and the challenges you encounter along the way.

          Daniel

  22. Sumit Pokhriyal 10 years ago

    a well written article. totally agreed with your points with respect to exposing your APIs to outside world.

    • Daniel Elizalde 10 years ago

      Thanks for your comment Sumit. I’m glad you enjoyed the article.

  23. Ana 10 years ago

    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!

    • Daniel Elizalde 10 years ago

      Thanks for reading Ana. You’ll find that close to the trends section I included a few links as the sources. They include the research pages from programmable web, an article from Rackspace’s blog (look at the infographic) and a link to API Evangelist.

      • Ana 10 years ago

        Thank you!!

Leave a reply

Your email address will not be published. Required fields are marked *