APIs for Product Owners- 101

APIs products are widely used when developing software solutions. As a Product Owner/Manager (PO/PM) you may come across several situations which involve having a good understanding around the APIs, such as: (1) deciding on when to integrate third party APIs, (2) developing and releasing your own APIs to customers, or (3) developing APIs for internal use within the department/company.
This post aims to give a solid introduction to people dealing with the scenario number (2) and (3)- so, PMs/POs who are involved in the API development project.
We’ll start by quickly going through some basic technical concepts of APIs to be aware of; then explore the steps that are involved in building an API from a product ownership perspective; and finally look at a tool to test an API, and some metrics on how to measure the success of an API product will be discussed.
Basics concepts of a REST API
API stands for Application Programming Interface. This interface allows two applications to communicate with each other using a set of common rules (also called communication protocols) which are defined by a contract.
At its foundation an API works using requests and responses- request is carried out by asking for something specific and then the API will respond with something specific in return.
There are mainly two types of protocols for APIs to use: SOAP and REST. In this article we’re only focusing on REST, as it is the most likely communication protocol that one would come across when building products.
There are several articles and tutorials explaining the API concepts in depth available online, so we will only be touching the surface in this section when it comes to the technical concepts.
HTTP Methods
The action to retrieve the information, resource or image from an API is done via HTTP methods. These methods allow you to create, read, update and delete data. CRUD is a acronym that is used to refer to these four functions. RESTful Services use the following methods to perform these actions:
- POST: to create new resources;
- GET: to read or retrieve a representation of a resource- which is the data that has been requested;
- PUT/PATCH: to update/replace data.
- DELETE: to delete data.
Status Codes
Everytime that a response is retrieved, then a response code is also obtained, which comes in a form of a number. The list of response codes can be quite exhaustive, but the following are the response code examples that are the most common:
[Status Code]:[Meaning]
- 200: Success
- 301: The resource that has been requested has been moved permanently
- 400 : Problem exists on the client side
- 404: This is a very common error status code which indicates that the client has been able to communicate with the server, but the server was unable to find what was requested
- 500 : Problem exists on the server side
As a product owner, having an understanding around these status codes can be helpful when testing the API through tools such as Postman, etc. (which is something discussed later in this article).
Steps to build an API
Defining your API Strategy & Roadmap
An API Strategy is a plan that
- takes into account your current API capabilities
- defines your API aspirations
- presents a roadmap to achieve API reach, innovation and growth.
Treating your API as a product, even if it is being built for the internal developer will allow you to utilise your business capabilities to the maximum. Just like a website, an API can be continuously monitored and iterated, using analytics and user feedback. And hence having a strategy and roadmap allows you to visualise how you can leverage your digital and business strategy alongside.
To build your API strategy you can use any template similar to the ones used to build a product. We would recommend using Roman Pichler’s vision board which forces you to think about:
- Your vision
- Target Group
- Needs
- Product features
- Business Goals
Once you have a clarity around what you are aspiring for, you can start getting into the details. Answering questions like:
- Strategic fit: How does the API strategy have to be designed such that it contributes to the overarching business strategy? This is related to the benefits of APIs and influences on which to focus on.
- Value proposition: Which value does the API deliver to whom? How is it different than competitive offers?
- Business model: What API business model best supports the organization’s overarching business model? How does the organization create and capture value internally? How does the organization define value in this context (could be one of the benefits)?
- Technology: Which technological decisions need to be made? These decisions address things like to make or buy an API gateway solution, hosting (cloud or on premise), access protocol (mostly either REST or SOAP), security, or the scope and scale of a developer portal.
- Marketing: Who are the customers and what are their pains and potential gains? How is the APIs’ value communicated? How is the product sold and delivered to the customers?
- Operations: How are the APIs deployed, maintained, and supported? How do developers on-board?
It is highly recommend doing a workshop with your business stakeholders, technical team and SME’s to develop common understanding across all the above mentioned areas.
Post this stage, your team can start looking into deep-dive analysis, this would involve coming up with :
Use case
- You enlist the different actors who are to be using the API (using a context diagram for example)
- You detail each actor’s typical needs of the system with use cases
User Story
- For each use case, you develop a set of scenarios on how the imagined system would be used
- You either create sequence diagrams or activity diagrams, but you design behaviour based on the scenarios to make out what messages are needed to be passed
Data architecture
- From the messages, you deduce underlying data architecture, by looking at what parameters are needed for each message to be successfully communicated.
Testing an API and measuring its success
During the development stage, and especially once the API is developed, then it is required that it passes through the testing stage. For a Product Owner it may be required and useful to understand how to test if the endpoints are working correctly and if we are getting the right response back. In order to do so, there exist several applications that provide the graphical interface to perform this task (eg. Postman, Swagger, etc.).
Alongside that, it is also important to understand what are the key performance metrics to track on an API project, so this section will also cover that briefly.
API testing with Postman
As previously mentioned, API testing can be done using several tools, and one of the most used tools for this purpose, is Postman.
By performing this testing activity, several types of bugs can be captured before the product goes live, such as ‘functionality bugs’ which will allow to confirm that creating, reading, modifying and deleting the data via the API call is working properly, etc.
By using Postman, one can request any of the CRUD HTTP methods plus some others that may be useful. This application has extremely simplified the process to send request and visualize the response. Postaman’s website contains easy to follow documentation that will allow a PO to get started with testing in a matter of minutes.
Measurement

Once the API product is released, then it is important to answer to the following question: How can we measure the success of the API product?
The following metrics can be useful when measuring the performance of an API:
- API calls (requests / responses): total number of API calls during a period of time can help to prove how much the API is being used
- Failure rate: the number of API calls that failed
- Uptime & Downtime: total uptime and total downtime for a API
- Client retention: monthly retention of API customers
- Performance: how long it takes for APIs to return responses
Department of product explores this topic in detail, and provides a number of other metrics that can also be tracked in this type of the product. These metrics can be tracked by using some tools available online (eg. Runscope, Uptrends, Pingdom, etc.).
(ref: 1. https://www.wired.com/insights/2013/12/leveraging-apis-part-digital-strategy/)
Authors of this article: Prabhjot Kaur, Nabeel Nasir