Just like you can physically go to a store and buy groceries or a t-shirt (instead of producing them yourself), your product services can “go” to one of the “API stores” and get a weather forecast via WeatherAPI, a translation via Google Translate API, a meme from MemeAPI (we’ll use that later today), and even… a ChatGPT response via OpenAI API.

To take advantage of the thousands of APIs available, a product manager needs to understand the basics of API structure: an endpoint, an input (or request), and an output (or response).

Below you will find four API examples, from simple to more complex, and one of them you’ll call yourself! Let’s get started.

Think of an API is a way to ask a computer system to do some work for you. You give the system something as an input, and you receive the answer as an output.
Whatever the system performed in between to get the results should not concern you per se — this is the very point.

For example, when you order a coffee, you exchange money and coffee choice — the input, for the cup of coffee — the output.
You don’t focus on how the coffee was delivered from the sorting center, and which shelf it was placed on in the storage room. But you do care about the quality of the result in your coffee cup.
This is how the API documentation for the coffee purchase might look:

Notice that this simple exercise already forced us to consider a “contract” between the client and the service provider — in this case, it’s a customer and a coffee bar. Now we clearly see the minimal requirements for a service provider to do their job (they need to know the type of coffee and milk, and get the payment).

A product manager can build on top of this structure, for instance, by introducing new parameters, or extras:

Or maybe later, they can think of a sustainable option “pour-it-in-my-own-cup,” which saves a buyer forty cents:

Or maybe later, they can think of a sustainable option “in-my-own-cup,” which saves a buyer forty cents:

Notice how we moved from an abstract “buying a coffee” to a very clear set of rules: what comes in, what is returned, and what can go wrong. A product manager can now have very substantial conversations with the stakeholders. For example:

• The supply department can review the contract and state that they do not have oat milk but can offer soy milk instead.
• The financial department can immediately ban cash payment methods and ask the PM to switch to cards only. Later, they might introduce another payment method, “stamp cards,” a mini version of the coffee bar loyalty program.
• Developers can mention that “Syrop logic” is a bit shaky, so it might happen that a customer sometimes ends up with creme in their cup instead. So the PM should decide whether to wait until they fix it or temporarily remove it from the API contract.

In other words, a good discussion starts, details are clarified, and all stakeholders leave the meeting happy as they understood what will actually be in the solution. This clarity is the main task of the product manager, who wants his idea to work in the end. When everyone is happy, the ball is in the court of the technical team, and they start coding —  the product manager no longer gets involved.

Let’s imagine you’re the PM of an app for runners and you would like to integrate weather forecasts into your app (not everyone enjoys running in the rain). So, you googled a bit and found this documentation of a (paid) weather API:

What does it tell you right away? You can pass the city name (you have it!), date/time, and get back the temperature in Celsius plus weather conditions. And also:

• Your customers will have problems in suburban locations further away from cities (because API doesn’t support plain coordinates, only cities)
• The temperature is in Celsius only (customers from the US and other countries using Fahrenheit will suffer. So you will need to add your own simple "translator" from one temperature scale to another.
• It says nothing about wind (which can be not okay for runners if the wind is stronger than a certain value)

This is enough to either set a task for your team to integrate with this API or continue searching and find something else. Note that we performed this analysis in a few minutes without any help from the technical specialists.

Enough theory, let's get to practice. As I have already said, there are many APIs in the world, and you can get anything from them: from the weather forecast to the exchange rate or a poem written by ChatGPT. And now let's generate a couple of cool memes via API. To do this, just click on the link, and you will see the picture:

https://api.memegen.link/images/buzz/PMs/ PMs_calling_APIs_everywhere.jpeg

This was a real API call (so congratulate yourself!). Here's what happened:

• Your browser accessed "https://api.memegen.link/images" (this is the full address of the API endpoint "Image")
• It passed the parameters of the background image ("buzz"), the text to insert at the top ("Product Manager") and at the bottom ("Just called an API")
• The meme service found the right image, overlaid our text on it (as we asked), placed its watermark in the lower left corner (even though we didn't ask), and returned the image to us
• Our browser rendered the image on the screen

Since all the parameters had to be passed in one line of the address bar, they simply go one after another, separated by "/". There are other ways to pass parameters to the API (you've probably seen something like &utm_source=blog), but these are details; the essence doesn't change. Here you can look at the cheat sheet image of this API call.

Let's say we want to add a cool new feature to our running app — routes for runners. Yes, Google can build a route for drivers and pedestrians, but runners need something slightly different. We assume that the user can specify training parameters and get the perfect route for running. We request the following API from the backend team:

What you need to notice here:

• We don’t mention how this will be achieved — via fancy machine learning (ML) or some simple ruleset. But we state what users send and what we expect back — this is a good start for negotiations with the clients and the team.
• We moved from a fuzzy “route for runners” to a more concrete API input/output contract. The tech team is already debating how to build it, and where they see gaps in terms of requirements. For example, they can mention that they cannot support the preference parameter at all because map data doesn't specify details like "riverside" or "urban," etc. So, PMs can lower the bar of their dreams right away and remove this requirement instead of promising it to all the clients and two months later, discovering it was impossible from the start!
• Once the API is ready, you can offer it to your client team (for example, the team of the main app) for integration and first testing.
• In case of internal success, we can think about "selling" the API to sports companies around the world and charging for every thousand API calls. Even the creator of MemeAPI, which we called above, offers to transfer him money for a cup of coffee, why can't we do so? But seriously, many well-known APIs (OpenExchangeRate, Stripe, SendBird) were once just functionality within the product. And then they decided to start a separate life and turned into separate companies.

The product manager should remember the following:

• API is a way to delegate work to another service or provide your services for others to do so
• API description consists of an address (API endpoint), input data, output data, and potential errors.
• The product manager should focus on the core value of the product, and call ready-made APIs for the rest. It is highly likely that smart developers around the world have already created the logic you need.

More materials and practice on the topic:

• Cheat sheet image of API calls and situations in which the product manager encounters APIs at work
• A whole lesson on API with examples and the ability to call APIs via Postman (without registration and SMS)
• Want to pump up your technical skills in general? Come to the "Technologies for the Product Manager" simulator, where we cover important topics such as API, architecture (Service Diagram), project complexity assessment, SLI/SLOs, and so on...