Seven Principles to Consider when Building an API Product

Editor’s note: the following was written by a guest blogger. If you would like to contribute to the blog, please review the Product Blog contribution guidelines and contact [email protected]

API integrations are a critical part of the SaaS economy. The reason is that many products solve a slice of a bigger problem by focusing on the user flow. For example, when you schedule a video conference without integration, first, you schedule the video meeting in the video conference system, copy the meeting information, and schedule the same appointment in the calendar system with the video conferencing system information—this is redundant. With integration, the sub-user flow is squeezed into a single button click. Integrations like this deliver a unified user experience, enriched datasets, enabling superior business decisions.

Schedule video conferencing with a single button click. 

In the following post, I’ll review the seven principles to discover, plan, scope, design, implement, and roll out an API product.

In an agile environment, it may take several iterations to figure out what is required and the best solution to get to a product-market fit. Starting small with an MVP is a good approach.

Principle 1: Your business goal is the king

Ask yourself, what are you trying to achieve? Typical examples include increasing product adoption, retention, engagement, reducing churn, and decreasing operating costs. 

Once you understand your goal, you can map the problems at hand. Use any product discovery technique to zero in on customer problems. Collect and analyze data, interview prospects and customers, perform market research, and so on. The result can be a list of opportunities with criteria to prioritize them. Choose the most valuable opportunities based on your business goal.

For example, you are working on a data product like AppsFlyer. A data product collects, processes, and makes its data accessible via a user interface. Some of your customers need to join your data with their data. When you deep dive into the problem, you identify a range of customer segments. Some customers have minimal automation capabilities. Other customers are savvier and have advanced capabilities. If your business goal is to drive retention, your product requirements can vary across the segments. However, for an MVP, you can focus on a single customer segment.

Principle 2: Know your personas

When you plan an API product, know who your target audience is. 

In APIs, consider the persona types that will use the API:

  • Consumer: Design and build a new capability using your API. These are typically developers but can also be product managers: 
  • End-users: Benefit from the capability delivered by the API. In the example of the data company, these are the users who analyze the data to get actionable insights.

In API products, user experience matters—a lot! Understanding personas help you focus during the design. For example, developers typically look for a quick and easy way to get the API up and running. A mandatory part of an API is authentication. That is the ability to get requests processed in your system based on user identification. The authentication step can make or break API adoption, so it’s essential to keep it lean and straightforward.

Easy retrieval of the authentication token in the AppsFlyer platform

It’s also crucial to plan the user experience when it comes to error handling. What happens when your API is not available, how do you recover it after the fact, what tools are available for troubleshooting, and so on? 

For error messages, work with your UX and micro-copy teams if they exist. If not, test them on several team members and improve them based on feedback. Remember to tell the user what the problem is, then tell them how to remedy it.

Principle 3: Start simple

When you’re in solution space, time to market is everything. Nothing can replace usage data, analysis, and feedback from people who use your product. Getting fast to market means you must provide value but in the simplest way.

In the example of the data company, customers want to join their data with your data. 

There are two possible ways to achieve this using an API solution.

Exports vs Import table

For the sake of simplicity, export is a better choice.

Principle 4: Design your data scheme based on the 80/20 rule

Data scheme is a tricky part of an API product. On the one hand, you’d like to provide some flexibility. On the other hand, you’re setting a standard by firming your requirements.

After you understand the problem, you can find similar patterns across use cases. That is to find the typical requirements that provide the most significant impact. Consider the remaining problems on a case-by-case basis.

In the AppsFlyer example, the data domain is marketing data. The base dimensions of interest to most customers are the publisher platform, campaign, and country. If you’d like to support additional dimensions, like keywords, they may be relevant to a few customers. So, you need to prioritize and ensure you’re not overcomplicating your design but rather support enough use cases to solve the problem based on the business goal.

Once you know what elements are part of your API, you must determine the API request and response structure, including the naming convention, representing the hierarchy between elements and the data format. If you already have a data element naming convention, even if it’s imperfect, maintain consistency, and stick with it.

You might also be interested in: How Product Managers Build A Data Story

Principle 5: Scale gradually

Scalability is a fundamental aspect of API products. Your product should address the primary use cases, support a growing number of customers, change to usage frequency, and provide the required data refresh rate.

You don’t need to build a fancy product from the get-go. When you plan your MVP, you can choose to work with several design partners who don’t have volume intense use cases. Before you design something complex that is expensive to build and maintain, you can validate your API product. As a next step, you can improve your API scalability based on the actual needs you observe when your product is in the market.

Failures in production due to the high rate of API calls can cause disappointment to users and customers. Thus, it’s good practice to implement API rate limits so that nobody breaks your system. The API rate limit controls the frequency for which consumers can run your API. This limit is per second, minute, hour, or day (aka queries per X or QPX). Another benefit of rate limits is that they control API operational costs.

When you choose what actions your API supports, you should think about data freshness. It depends on the business need. It could be real-time, several times a day, daily, or weekly, etc. When you plan the scope of your MVP, start small, even if it doesn’t meet all the requirements. For example, if your customers need the data refresh every several hours, you can start with once a day and watch how your customers use and react to this. You can improve the frequency in future phases.

Principle 6: Prepare your roll-out plan from the beginning

API rollout has several important considerations, and hence it’s necessary to think about them upfront. Involve the marketing team as early as possible in the process.

These aspects include where the API should be available and how and when it gets distributed. It could be on your website, in your help center library, or it could be contingent on a business agreement with a third-party company. When you plan your roll-out, work with your relevant business stakeholders, the biz dev team, the legal team, and others to ensure you have the business infrastructure to roll out this product.

A different option could be to make the API open-source and community-driven. If that is the case, you can use a community management tool to announce the launch and share the code in a repository like Github.

Once you know what channels you’re going to use for distribution, you may also want to run campaigns to spread the word. Like any other product, API products are not different. You can use owned media like emails to customers and prospects, paid acquisition, or any other form of marketing. Here the marketing team is your safest bet. Work with them to develop a plan.

What’s more, you must prepare and train your internal team. Depending on your use case, you may want to involve customer success, biz dev, support, and others.

Documentation is the last but critical piece of your roll-out. Not only does it have a part in the user experience, but also your teams see it. You need to document all the technical aspects and the how-to of your product. After your product is live, this document should continuously change and be adapted to meet user expectations.

Principle 7: Learn and improve

Learning from your API product is critical to understanding requirement prioritization. As a result, it’s imperative to document your desired learning before you develop the product. And when you plan the scope of the project, define the monitoring mechanism and the KPIs you’re going to track. Even if you don’t achieve your goals, you know what you learn. Next, you can use the data, talk with customers, and understand what to improve to get to the right product-market fit. The key is to have all the data you need to reach the insights.

About the Author

Dubi Furie

Dubi is a seasoned product manager and leader with extensive knowledge in business and technology. Driven by doing the right things right, UX, and innovation he executes with a sense of urgency to get things done.

The Product Podcast banner

Enjoyed the article? You may like this too: