Lean Agile API Product Development
We derived the Lean API Product Development method from the innovative Lean Startup methodology, which became increasingly popular. The Lean Startup methodology is a revolutionary method that’s transforming how companies build new and innovative products or services. Its core principle is the so-called “build-measure-learn” cycle. It is a scientifically proven approach for creating new products or services under conditions of uncertainty.
What is the Lean Startup methodology?
The Lean Startup methodology is an iterative process of how to build products, refine or even pivot them depending on the market demand. It consists of three activities: build, measure, and learn — and three artifacts: ideas, code, data. The following figure presents the build-measure-learn cycle.
But what if we will apply the build-measure-learn cycle a little differently?
The Lean API Product Development method consists of two consecutive build-measure-learn cycles instead of a single one. With such a bi-cycle approach, we can first quickly validate our ideas (problem/solution fit) with minimum efforts and without breaking the API’s interface contract. After the validation, we can safely build it and verify how well the validated idea works out (product/market fit).
The first build-measure-learn cycle is to validate the idea until we reach the problem-solution fit. That means we have understood the problem and found a viable solution. For the first cycle, we apply the prototype-first approach.
The second build-measure-learn cycle is to verify the solution until we reach the product-market fit. That means that we built a complete product that is profitable. For this second cycle, we apply analytics.
The following figure presents the Lean API Product Development methodology.
The first cycle is the Prototyping cycle. The second cycle is the Realization cycle. The blue arrow indicates that both cycles are part of a sequential process from initial idea to the final product.
The meta-process of Lean API Product Development is validate-develop-verify.
Prototype-First in the Lean API Product Development
In the Lean API Product Development method, we make use of the prototype-first approach. We already know our customers and early adopters. Nevertheless, we still have just an idea of customers’ real problems and what jobs they have to get done. Thus, in this first cycle, our primary focus is to understand better the problem and find the right solution regarding an API product. That is also known as the problem-solution fit. To this goal, we apply the core principle of Lean Startup that is “build-measure-learn.”
In the following, we explain the process of finding the problem-solution fit.
Build the API Prototype
As a first step, we need to define the product feature that forms our value proposition. We often refer to the product feature as the business feature. From this product feature, we will then derive the technical features of the API. As the last step, we design the interface of the API. Having the functional knowledge of the backend applications is crucial for a good API interface design. But don’t try to map the interface to the backend interface yet. Remember that we need first to validate that the API is solving the customer’s problem. Since you are not accessing the backend, make sure that the API prototype mocks some realistic data.
The critical success factors in API prototyping are speed and low costs. To achieve this, we use a tool to generate a working API prototype from an API specification (e.g., Swagger). With this tool, we don’t have to invest time and effort in building an API prototype. Instead, we save time and effort.
As a result, you’ll have an API specification, an API prototype for demonstration, and incipient API documentation to share.
Measure with Customer Feedback Collection
We collect feedback from the customers or rather early adopters for the following two reasons:
Problem validation: Do we understand the real customer problem?
Solution validation: Did we provide the right solution to solve the problem?
From our experience, it is crucial that we do the customer feedback collection face-to-face with the customer. In the past, this helped us to establish a good and honest relationship with early adopters since face-to-face meetings create a much more open space for communication.
When you meet the customer, make sure that the most relevant people participate in the customer feedback collection. We don’t want to waste our time and theirs with a useless meeting. So, ask the customer to bring to discussions always the same people with the following roles and background.
Business Owner: He’s crucial to understand the business problem. He can decide upon financial aspects and evaluate the relevancy of certain aspects.
Architect: He understands the current solution, the technical dependencies, and the impacts.
Engineer: He’ll use the API to integrate it into the app. He’s helpful to check the simplicity of the concepts and API design.
Feedback Collection Process
The feedback collection process is lean as well. It consists of the following steps, per scenario or use-case:
Present the scenario or use case.
Demonstrate with the API prototype how to use the API to get the job done.
Ask early adopters to provide structured feedback, via a feedback form.
Structured Feedback Form
Our goal with the structured feedback is to validate:
Do we understand the problem?
Do we know the jobs that the customer has to get done?
Does our solution deliver on these needs?
From this goal, we defined the following questions to get the relevant feedback for each scenario:
How relevant is this scenario for you?
How well has the API solved the problem?
Explain why you rated the above question the way you did?
The following picture presents an example of such a customer feedback form.
With the first two questions, we can validate how relevant the specific scenario is and how suitable our proposed solution is. The third question will provide us insight on the customer feedback. Typically, customers want to discuss the scenario rather than to write down the explanation. That is fine. Please make sure that you take notes because it’s crucial. Ask a lot of “Why?” questions; they help you understand the motivations and goals of the customers. Otherwise, you’ll implement the infamous ‘Faster Horses.’
“If I had asked people what they wanted, they would have said faster horses. — Henry Ford”
Learn from the Customer Feedback
It’s time to get insights and learn from the feedback from multiple early adopters. It is vital to understand that the customer feedback is not the set of requirements. The purpose of the feedback is to help us solve the right problem and to shape the right product.
The customer feedback can help you to prioritize the feature according to their value and effort.
Analytics-First in the Lean API Product Development
In the Lean API Product Development method, we involve the analytics-first approach. The primary goal of this Lean Start-up cycle is now to verify, quantitatively, if and how well the product delivers the value proposition to the customer.
We all already know how to implement APIs with the technology or with the API management platform of your choice. Make sure to record or log relevant key metrics when building the API. If you don’t log the right things, you can’t measure them.
Measure with Analytics
It is not about measuring the number of requests, the rate of successful requests, or number of customers. It is about measuring the value that you provide with each call.
We need to derive relevant metrics from the value proposition. The primary goal is to check how well we deliver our proposed value. E.g., let’s refer to the Identity Verification API presented in here. This API proposes to verify the identity to increase the conversion rate of users ultimately. From that, we can derive key metrics that showcase how well this API product serves our customer:
The rate of successful vs. unsuccessful identity verification requests.
The rate of identity verification requests for individuals we don’t know.
Estimated conversion rate. Let’s assume that a successful verification request leads to a successful onboarding of a customer.
Often, you need to make assumptions to get quantitative insights. Even though , the metrics give you insights into how well your product works out to provide value. Make comprehensible assumptions and don’t forget that the resulting numbers are to get insights and see relative improvements. They aren’t facts.
To learn, you need to understand the data as well as the metrics you are analyzing. Visualization methods have proven useful to understand data and deliver insights. From our experience, it is straight-forward to visualize the log data, specifically the content.
Make it a habit to publicly (within the organization) publish these metrics and be proud of it. In our case, we built a visual dashboard and displayed it on a screen at the entrance to our office.
I used the insights from the dashboard to from time to time a small quiz with engineering to engage with the results of their efforts. In this quiz, I ask them for instance how many successful identity verifications we do per week, etc. The team loves it and are more engaged. Furthermore, they can significantly use it for the Daily API pitch.