Author: Patricia

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, 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

With knowledge of product infrastructure you can apply it to your potential or current product manager role and reap the following benefits:

  • EFFECTIVE COMMUNICATION: You’ll know exactly which team and who to seek out or speak to for a feature you’re building which will allow you to make yourself and your team productive; 
    • Depending on what the feature is, you’ll need to identify whether it encompasses front end, back end tasks or a combination of both.
  • HIGH INTUITION: You can be ahead of the game on technical components relevant to the feature so you save time for your team in discussions to explain it to you; 
    • For example, understanding what (Application Programming Interface) API’s exist or don’t exist for the feature to work
  • TEAM EMPATHY: You can empathize with engineers when sizing work that needs to be done. Writing code is not trivial, it’s complex. The engineering role requires thinking thoroughly through design, information processing and storage. If you know how a computer works you can begin to understand and empathize why your feature you propose may take more or less time to execute while considering performance and user experience for your product. 
    • Since you’re responsible for your product’s roadmap and you will work with engineering teams day in and out to define features from concept to deployment and make technical tradeoffs as necessary influencing your feature release timelines.   

Too many people over index on the importance of a technical degree. As long as you’re a voracious learner, there is a high chance you still be successful over someone with a technical background. Without further ado, here are a tech product’s infrastructure every non-technical PM should know: 

Type of Application (or Product)

Company tech products may include only a web, mobile, or a combination of both. Most companies who develop tech products will have different types of applications; insert ‘application’ as a suffix to each word below for the full conventional name:

  1. Web
  2. Mobile
    1. Within mobile; you can either download from an Apple or Android smartphone
    2. iOs (Apple)
    3. Googleplay (Android)

Application Layers (3) 

Each product has 3 layers of code that make it up. There are three main layers that comprise every product. 

  1. Front end (also known as the ‘Client’; a fancy way of saying ‘front’ or what customer see)
  2. Application programming interfaces (APIs) 
  3. Back end 


Each layer comprises its own language that builds that layer. Quick google check shows:

You’re absolutely not going to know every single language out there. It’s only important to know which languages may be relevant to your product and there may just be a handful depending on whether you work on a web or mobile application. There are languages for front end; the three main are HTML, CSS, and Javascript, and there are languages for back end such as Python, .Ruby, PHP, Java, .Net. 

Example: Instagram

Application: Web and Mobile application

Languages: See Exhibit A

If you don’t know what Instagram is (everyone and their mother should know) it is a free photosharing and social networking service available as a mobile application on iOs, Google Play, web browser. It possesses brilliant and beautiful user experience (UX) that has dominated  the social media market. People or businesses socially share awesome filtered stories and now videos of themselves to friends and more making it one of the most addictive social engineered products on earth. This is what Instagram mobile  app is composed of:

Exhibit A

  1. Front end (Client) 
    1. What each of us interfaces with on our screens. Everything you touch and can take action on is built with front end code. This includes log in or sign up, take photos, add a filter, add a picture and post/share. You can also view, like, and comment on other photos and follow people. With the web page, you can view, like, and comment on other photos.
      1. It hosts the UI and UI related logic. UI means User interface which explains exactly what it is. You and me are the user and it is literally what we interface with. 
  2. APIs – Application programming interface – a set of instructions or protocol to have two applications talk to each other to complete a set of actions. I would call APIs the middleman and connector between the front end and back end client to perform the specific task a customer gets value out of when using your product.
    1. There are many other types (SOAP, JSON-RPC, etc.). REST apis are commonly used. They are essentially contracts that communicate the terms between two entities, the front and the back end. Think of it like a real estate contract where it communicates instructions with terms applied that is communicated from buyers to sellers. The same applies where there must be inputs entered in the front end and those inputs such as price, closing date or contingencies, must be communicated to the seller to generate a response back to the buyer. 
  3. Back end (Server side)
    1. This includes the servers, database, and programming that makes it all work together. The back end is everything that happens when you take an action on page. So when you sign in, you send your username and password to the server. The server is the back end. On that server, your credentials are checked against a database (Database is the back end). A response is sent back to the front end which tells the app to perform the action. In this case, whether it lets you log in or not. This is the job of the back end.
    2. Same thing happens with the photos–once you hit “share”, the photos and whatever caption you enter are uploaded to the server (back end). They’re stored in the database (back end). When you or others view your photos, you send a request to the server (back end) to serve up whatever photos you want to see.

Each ‘end’ has coding languages that are used to program each ‘end’ or API – Python Web framework, Django. To learn more about frameworks and why they exist check out Why Frameworks. In this case, Instagram’s mobile applications for both IOS and Android were built using React Native. React Native is a hybrid mobile development framework made by Facebook. Each product has different languages that they use to build their front/back end and APIs. 

So we’ve covered the following:

Why and the benefits to learn technical concepts, every product may be comprised one or multiple types of applications (web or mobile), every application essentially has 3 layers, each layer is programmed with different languages, and we provided an example using Instagram. The first of the series to prime your confidence in technical concepts. What would you like to learn more of? 

As a product manager, having context of how a computer works will greatly help you understand the reasons or complexities that may arise when working with engineers for building your product. 

As an aspiring product manager with no technical background, I did not go through any formal training to understand exactly how a computer works and how it’s relevant to tech products that are built today. 

Knowing how well give you a leg up on the following:

  • Productive product feature discussions (especially for tradeoffs) with your engineering team which will help delivering results faster
  • Speak to other teams or leaderships about reasons why work may take longer or the needs for your product which will help credibility and effective communication

Flashback to when I didn’t really understand the parts of a computer…

Back in the 90’s, most of us non tech folk hear the word computers and visualize an Apple Mac desktop computer we used to surf the nascent internet on in the 2000’s and use AOL (for email) and AIM (Instant message) with our friends and family. 

When I hear computer, I visualized this:

Or this:

Ah, such fond memories. 

And now it’s exponentially changed to this:

Can’t really get enough of the screens nowadays eh. Almost as humanity has thought it’s evolved to have more than 5 pairs of eyes and exponential growth of multitasking skills. 20 years later we may have a minimum of 6 screens for every office desk. I digress. But really, today, this is what most people think when they say they need to get to their computer or portable clamshelled computer, AKA laptop with connecting wires to even larger LED screens. 

What most nontechnical folk don’t realize is that this is a computer:

And this is a bunch of super large computers stacked together, also known as servers:

A computer is basically comprised of two parts:

  • Processor
  • Storage

The Processor is like a brain. It does computations such as multiplying and subtracting numbers (aka information). Storage on the other hand holds information like a refrigerator stores food until it’s needed. So how do the two work together?

Let’s use a chef analogy to break it down:

Say the kitchen is the computer which is where the chef and refrigerator live.

A chef is the brain or processor, refrigerator is storage. Guests are the input. When a chef is asked by the guests to make a dish, the chef needs to figure out which foods to be transferred from the refrigerator in the hands of the chef for her to prepare the food, make the dish, and serve. 

Types of Storage

Depending on the dish and kitchen, the chef will need to take food from the freezer or refrigerator. Food from the fridge can be taken out and processed immediately. This means it’s faster to transfer this food to be processed by the chef and make the dish to serve to the guests. 

If food is needed from the freezer it needs time to thaw so it’ll take longer to make the dish and serve to the guests. 

Which is a great segway to how this really works in a computer’s context. Food in this case is the information that needs to be transferred from storage for the processor to do its job. 

Depending on the computer and the type of storage it has will allow for faster or slower information processing. Different company products have different types of storage depending on a product’s requirements.

Below are basically the 5 types of a storage out there a computer may have:  

Pyramid of storage

For simplification using the chef analogy let’s just use two types. In a chef’s context, think of food from the freezer as Tape storage, whilst, L1 Cache as fridge storage.

The lowest level is tape, a type of storage which takes the longest time for information to be transferred to the processor. Freezer food needs more time to process.

Alternatively, the top layer, L1 cache is a type of storage which takes the fastest time for information to be transferred to the processor. Refrigerator food needs less time to process.

(Note: L1, L2, L3 cache are grouped into one layer classification but L1 is the fastest with L3 being the slowest within that classification.) 

Typically, storage that allows faster processing is way more costly to the business than storage that is more accessible. 

Putting it all together, the key point is that information needs to be gathered and processed efficiently for things to work in your product. If you have food in the freezer it’ll take longer to make things happen for your guests. If you have food available in the refrigerator, it’ll be faster to make the dish for serving.

The type of storage and processors you have is directly correlated to how well your restaurant or product performs. Depending on the size of the restaurant and the number of customers (or addressable market) it serves equals the 1 to n kitchens made up of 1 to n refrigerators, freezers, and chefs required. So the smaller your product is, the less kitchens you’ll need. The larger your product, the more kitchens.

Taking in how a computer works directly applies for understanding this in an engineer’s context. In a way, an engineer is the general manager of the kitchen(s) who deeply cares about how to make the guest’s experience delightful.  

When asking or having discussions about product features, it’s great to be cognizant what engineers must think through around inputs, storage and processing of information. Further, the things they care about directly affects what a product manager cares about – the guests experience which make up the following:

  • Performance – how well they perform with a guest’s request
    • Usability and Functionality – how well they satisfy the guest’s experience in making and fulfilling the guest’s request in real-time
    • Reliability – how reliable they are in serving guests
    • Availability – how available they are for their guests
    • Scalability – how many guests they can serve at once
  • Cost – how much food storage and chefs are needed or how many kitchens would it take to serve all guests
    • This directly affects the restaurant’s total cost and can be translated to the business cost of making the final product experience to be great for the guests while solving for how to minimize cost if there is higher demand or specialized requests but still achieve the same delightful outcome for guests.

Depending on how complex the guest’s request is, the less or more time it will take to deliver. This is why building epics, features, or stories for your product vary in time to completion and it is a concept that’ll help you accelerate your workflow as you define features for your product and gain empathy and offer effective communication with your engineering team.

Having interviewed tens of times with companies ranging from tiny startups to large enterprises, I still get most nervous about the technical portion of the interview. That’s because I come from a non technical background. To pile onto the anxiety, no two companies I’ve interviewed with have had the same expectations for the depth of my technical knowledge.

So what’s a rule of thumb for how to think about it? You need to know enough to minimize suffering for the engineering team and be effective in understanding the ROI of investments. Specifically,

  • the cost that goes into it
  • decisions that affect speed
  • decisions that affect quality

Here’s an overview of all the concepts that will make you an effective technical counterpart for both the business and your engineering counterparts:

  • Pace of development to test worth with customers
  • Acronym: QCAE
    • Quality, reliability, functionality and performance as it directly impacts the user experience
      • Requires extra code, process, monitoring, diagnostics
    • Code cleanliness
      • Refactoring
      • Simplicity of coding; aka speed
    • Architecture
      • Cost of development
      • Cost of hardware
      • Scalability
    • Existing code
      • APIs