post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Co-founder of <a href="http://www.prodpad.com">ProdPad</a> and Mind the Product who run ProductTank, ProductCamp London and Mind the Product conferences in London and San Francisco. Blogs about Product Management at MindTheProduct.com &amp; ProdPad.com. Simon began his career in Space Engineering, where he developed a Fortran realtime program to automate satellite operations. He then traveled around the world before a stint in the Australian Army.

Simon Cast

<a href="http://mindtheproduct.com/wp-content/uploads/2011/11/API-timeline1.png"><img loading="lazy" decoding="async" class="size-large wp-image-1334 aligncenter" title="API-timeline1" src="http://mindtheproduct.com/wp-content/uploads/2011/11/API-timeline1-1024x371.png" alt="" width="614" height="223" srcset="/wp-content/uploads/2011/11/API-timeline1-1024x371.png 1024w, /wp-content/uploads/2011/11/API-timeline1-300x108.png 300w, /wp-content/uploads/2011/11/API-timeline1.png 1200w" sizes="(max-width: 614px) 100vw, 614px" /></a>
It is all the rage to use 3rd party <a class="zem_slink" title="Application programming interface" href="http://en.wikipedia.org/wiki/Application_programming_interface" rel="wikipedia">APIs</a> in products, such as <a class="zem_slink" title="Twitter Developer" href="http://dev.twitter.com" target="_blank">Twitter</a>, <a class="zem_slink" title="Facebook Developer" href="http://developer.facebook.com" rel="homepage" target="_blank">Facebook Connect</a>, <a href="http://directededge.com" target="_blank">DirectedEdge</a> and <a href="http://www.programmableweb.com/apis/directory" target="_blank">more</a>. APIs provide additional data or functionality such as user-authentication or product-recommendations. They can provide your product with fast access to data and features that would otherwise take a lot of resources and time to do yourself. They are particularly useful for getting that prototype up and running.
But there are drawbacks to using 3rd party APIs. Unless you go in with open eyes, these drawbacks can cause serious problems for your product as it matures.
Lack of control 
Twitter fail whale anyone? Every API you add to your product removes one more aspect you would otherwise control. Your product can only be as reliable as the least reliable API. You are also at the mercy of the API providers, who can change the rate-limits or terms of service with little or no warning. This is particularly true of free APIs. Even if you are provided with warning of changes, the changes can effectively kill your product if it is dependent on a particular characteristic of the API. Take for example <a href="http://pavo.me" target="_blank">Pavo.me</a> which had to shutdown after Twitter changed their permission model or Google&#8217;s recent killing of Google Translate API.
Even worse are the undocumented and un-communicated changes to the methods and data returned. Variable names change and data is removed from APIs (even versioned ones) all the time and you only find out when your product begins to fail.  This happened a month or two ago where Facebook removed a data field from the authentication data structure which in turn, broke the Facebook login to PeerIndex (where I&#8217;m Head of Product) until the developers finally isolated the cause.
Constraints to scale 
Rate-limits are the bane of anyone trying to scale a product. While initially these rate limits will be fine for early prototypes, you&#8217;ll quickly hit walls whether it is the number of calls per second or the number of calls per day. While you can move from free to paid versions of the API this adds considerable cost to the product and you are still ultimately constrained in scale by what you can afford. The rate limits will bite you in the ass if you are not careful.
APIs also put scale constraints based on their reliability and performance. An API that has a return time of 1 or 2 seconds limits both the scale you can reach and your own product&#8217;s performance. In effect your product can only perform as well as the worst performing APIs.
Engineering Effort 
APIs sound like a effortless method for developing but you&#8217;d be surprised at how much effort it can take to use an API. Even a well documented one. There are always quirks that are undocumented along with just plain oddities. An excellent example was found recently by a PeerIndex developer in the Facebook API where @ messages are represented two different ways within the same method.
Recommendations 
So how do you get around those issues? With a bit of planning:
1. Plan the inclusion of APIs with the rate-limits in mind 
Understand the rate-limits and how they are likely to effect performance as you scale. Plan how you will address rate-limits as you scale when you design in the product to include the API.
2. Understand that on-going engineering effort will be required 
Know that you will need to continually have the engineering team review the 3rd party APIs to address any changes (documented or otherwise).  We&#8217;ve had quite a lot of engineering time to be devoted to maintaining API related code and dealing with the undocumented quirks and oddities of APIs.
3. Use background calls where possible 
When including APIs in your product, carefully consider whether they need to be realtime or whether the use of the APIs can be done in the background. Background processing allows for graceful degradation and reduces the performance hit to the user experience.
4. API must solve a real problem 
Ultimately, know what problem you are solving with the API and carefully review whether you really need to use an API to solve the problem. As a product manager you&#8217;ll often be pushed to include APIs as either a) they are the current bright shiny object or b) the developers want to play with it. Although obvious, only use an API if it really does provide the best solution to a problem you need to solve.
5. Permissions matter 
This is particular to when using social APIs such as Twitter and Facebook. Asking for too much access to someone&#8217;s profile does seriously effect conversion (I seen a 70% funnel loss due to asking for too much access Twitter permissions) so consider how much access you need very carefully.
6. Avoid APIs for crucial functionality 
If an API is crucial to the functionality of a product, seriously consider bringing the functionality in-house. Having your product so dependent on another company is a recipe for disaster. Getting started this isn&#8217;t such a concern but as you go along try to bring the crucial functionality in-house or turn that API relation into a commercial, contract based one to establish some measure of control. Of course, sometimes bringing the API in-house is not practical but you need to make the decision of making the product&#8217;s survival dependent on an API with a clear head and if possible diversify to using multiple API providers.
APIs can be wonderful for getting a product off the ground and accelerating adoption. That should not be discounted. However, APIs can have serious a detrimental effects on a product. Product Managers must understand these effects and plan the inclusion of APIs accordingly.
What have you learnt in using 3rd party APIs?
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

core/freeform

Startup Product Management

10 years Wiser: Lessons learned from scaling Wise by Nilan Peiris

Org charts eat culture for breakfast: Why an agile mindset alone won’t help you by Björn Waide

The 3 stages of product development at a high growth tech company by Cameron Adams

API’s in your product – the good, the bad, the ugly

Simon Cast

Comments

Read next