API: What to know

In 2012 Paul Graham tweeted: “API = self-serve biz dev”. I couldn’t help but reverse engineer what that means. In 2020, it still holds true today and I’ll share why. If you don’t know who Paul Graham is, he is, one of the product industry leaders who shares a breadth and depth of knowledge in his career as well as having co-founded the well known accelerator Y Combinator and blog, Hacker News (where he shares his blog).

What is business development or ‘biz dev’? It is a function of the business to utilize partners in selling to the right customers. Creating opportunities for value to be ongoing in the long term building new growth with customers, markets, and relationships. The set of activities for pursuing strategic opportunities for a particular business or organization, for example by cultivating partnerships or other commercial relationships, or identifying new markets for its products or services.

What does it mean to be self-serving or self serve? And no, I don’t think it’s the self serve definition in the context of an entity preoccupied with one’s own interests, often disregarding the truth or the interests of others.

Instead, think of it as self serving in the way where it describes a facility in which the customer does the work rather than being waited. In other words, no business operations to be involved.

Why is it important to know about APIs? When would API’s be brought up in discussion?

There are two main reasons it’s important to know about them: Adding value to your business and team.

Adding value to business:

API’s are a gateway to opportunity and growth for your business. They add value to new or existing functionality for your product or they’re an avenue to generate value for other businesses that may turn into your customers and partners. There’s essentially three scenarios that come into play using APIs with pro/cons conditional on the products and business model your company has:

  • Team builds an internal API for feature
    • (may be slower development depending on technical knowledge and resources, lower risk but more functionality for users)
  • Team uses or connects with a third party API
    • (may be faster development, higher risk because of dependencies if third party API fails but more functionality for users)
  • Team open sources APIs to the public
    • (variable development time, but great long term value add to business; think of Facebook Oauth or Google Oauth APIs and how much they are used on so many different platforms)

In essence, APIs are the keys to delivering relevant functionality, imperative to building delightful user experiences, and potentially becoming a growth strategy for your product.

Adding value to team:

In product management, time is of the essence and resources are limited. By simply knowing what APIs exist and knowing where and who to ask about your APIs will give you an advantage in being able to do the following:

  • convey the expected full end to end user experience of the features to the right team for them to help you define what API(s) are exactly needed
    • answering questions such as how often the API will be used so the team can account for how many servers they need for the intended requests
  • build APIs accurately and strategically so they’re reusable
  • build a relationship with API SMEs’
  • understand what APIs exist and what may be used for new features you come up with
  • predict development time as well as being prepared for communicating needs of your new feature when discussing with your engineering team

All tech products that have a digital interface use API’s. Chances are, if you have new features that need to process and display information that it hasn’t before, your team (or another API dedicated team) will need to allot perhaps 1 to 2 or more sprints of development time to design those new API’s and make that feature work. If you come up with a new feature that you know there is an existing API for and produces a higher impact relative to customer growth and/or retention oppose to another new feature that requires a new API and produces a lower impact, you’re definitely going to go with the existing API with higher impact, right? All this must be validated with your engineering team when you have prioritization and trade off discussions. The fact that you did your research and can explain your basis of why the feature makes sense to work on based on ROI before your discussion will certainly help with effectiveness of your communication and credibility with your team. You don’t have to remember every single API your company uses, but it will be beneficial for you to know which APIs may be relevant to your scope of work and to be familiar with what they do. Ultimately, it will help aid you in prioritizing your road map and backlog.

Most of the time, larger product organizations have their own API and integrations teams that are the subject matter experts of all existing and new APIs relevant to the product and you can directly ask them to assist with your new features or help you answer questions about existing and potential new APIs. Smaller product organizations will usually keep (ideally) a repository of existing APIs to retain and reuse and engineers typically are familiar with what APIs there are and are a good source of the truth.

Recalling the first time I heard Application Programming Interfaces, or commonly known as ‘API’, it wasn’t something easy to grasp. As I obtained knowledge of how a computer works and how information is processed (with computers) it was easier to understand. I felt naive once I did discover that mostly every app I use everyday leverages APIs. If you work on a tech product, your product most likely uses APIs as well.

What is an API?

APIs are invisible to your users’ (or customers’) eyes, visible to engineers, and are a set of coded instructions or also known as as procedural code between multiple applications. In other words, it is that thing that communicates between different applications to get a specific job(s) done in your product. There are different contexts APIs are used. For example, an API could be directly used for a user using a feature of your product involving the front end talking to back end, or may be used to complete a job that has nothing to do with your customers using the product – back end talking to other back end. Or middleware to back end, or frontend to middleware. There’s a multitude of combinations but you should just at least know it’s that set of instructions between two exclusive application entities.

For simplification, in a front to back end context, I wake up and use the following apps religiously in no order to do a specific task – and they all use APIs to help me complete those tasks:

  • FitBit (get sleep tracking report)
  • Chrome (get the answer of whatever question I’m curious about)
  • Google Maps (get directions and fastest route to where I’m going)
  • Weather Channel (get weather forecast)

The point is that with these apps I’m getting the information served that I need (and to help me navigate my day). This doesn’t just magically happen. Someone, a fabulous computer engineer, put thought into how to write a set of instructions (API or APIs) to do exactly that for a user like me. They wrote a set of procedures that need to happen for me to be served the information I want which involves at least two systems ‘connecting’ with each other. Which, in this case, involves:

  • User requests a task
  • Input – Information collected and inputted
  • Information processed
  • Output – Processed information must be outputted (to me in the front end)
  • User completes task
ApplicationAction from meInput (Request)Output (Response)
FitbitRefresh Fitbit app to view sleep dataSleep data tracked through using Fitbit watch sensors (data pulled from Front or Back end)Display hours slept on Fitbit app sleep module
ChromeType in my spontaneous curious question in search barInformation I type into the search engine barDisplay relevant results on the Search engine results page
Google MapsType in address I’m going toAddress I inputDirections

To put it tangibly, the web Fitbit API looks like this:

For the apps to do this for me, they must have information inputted to be processed somewhere in the background which generates the output of information I want to use. To reiterate, the API is the set of instructions that does the following jobs from an action by me:

  1. Receives the request of information
  2. Sends it to the right place for collection and processing
  3. After processing, sends an output of processed information back to where it was requested

APIs are basically like a contract between two entities. I like to buy/sell real estate as a past time. Whether you’re on the buyer or seller side there’s a contract that needs to be written with clear terms of what will be agreed upon between the buyer and the seller in the transaction. It’s the contract that connects the two entities, buyers and sellers, to deliver an expected outcome.

Most Common Type of API

There are several different types of APIs used based on application type (mobile, web, desktop), data or formats (i.e. HTML, JSON, XML, etc.) The most common used are REST APIs. REST stands for representational state transfer. Not the most thrilling convention for that abbreviation to recall. They are commonly used for mobile, web, and desktop applications. n architectural style and approach to communications often used in web services development. A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. The API spells out the proper way for a developer to write a program requesting services from an operating system or other application.

You probably won’t get into too much of technical details of the API unless you’re on the API product team or your product heavily relies on API’s for its function but you should at least understand what a REST (also known as RESTful) API does and how they may be used for your product as it may affect development time.

Where do API’s live?

Your company will most likely have a repository of internal APIs. These are typically called private APIs.

There are also open source (public APIs) available on platforms such as RapidAPI.com, ProgrammableWeb, Github.

Then there are partner APIs that you can pay for buying the specific rights or licenses to access this API from people or companies who’ve created them.

APIs secret superpower

In a nutshell, while knowing business development is a key proponent of company growth you can imagine this would be an extremely powerful tool for the company who creates the API. We’ve covered why APIs are relevant, when you’d be using APIs in a personal and professional context, the most common API, and that leaves us with a hopefully memorable quote you can reference when you come across an API in your work. 🙂 “By exposing often complex services as simplified code, API-first products are far more extensible, easier for customers to integrate into, and have the ability to foster a greater community around potential use cases.” – TechCrunch

about author



Patricia is a product manager based in Seattle. One of her many missions is to help enable aspiring or existing product managers without a technical background to feel confident in their technical competence when landing and performing a product role. Outside of that she's a personal finance, real estate, and fitness fanatic.

23 Comments on "API: What to know"

Leave a Reply

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