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, learn – and three artefacts: ideas, code, data. The build-measure-learn cycle is presented in the following figure.
Lean Startup is based on the build-measure-learn cycle
Everything starts with an idea. We implement or rather build up the idea, which results in a piece of program code or an app. We then make the app productive and accessible to users. Afterwards, we measure the relevant data from the users and how they use the app. Based on the acquired data, we learn and gather insights. This leads to new ideas on how to improve the product. And the cycle of build-measure-learn starts again.
The Lean Startup Methodology is suitable for Application Programming Interfaces (APIs) because of the very nature of the APIs: fast to develop and measurable. However, APIs are technical, contractual interfaces. Let’s imagine that you develop quickly an API and a consumer is using it in an app. You change it frequently breaking interface contracts. As a consequence, the consumer has to frequently adapt his app to the new API. This leads to the consumer spending massive amounts of effort just to maintain the current functionality of his/hers app, which in turn, results in a very bad consumer experience.
The Lean Startup methodology is an iterative, lean process and hence it is ideal to test ideas and to learn from the data. This is particularly interesting when we are uncertain about the customers’ problems and how we can provide value to them.
Overview of the Lean API Product Development
The build-measure-learn cycle promises speed, low costs, and low risk. However, APIs are ultimately technical interfaces or rather contractual agreements. As engineers, we know the rule: Don’t break the interface contract! Imagine that you build an API, customers integrate it, and you change it, frequently! Your customers wouldn’t appreciate it much, to say the least.
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 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. This 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. This 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.
Lean API Product Development
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 in terms of an API product. This 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 also 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 to first validate that the API is solving the customer’s problem. Since you are not actually accessing the backend, make sure that the API prototype mocks some realistic data.
The key 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 an 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 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 in 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: if we understand the problem, if we know the jobs that the customer has to get done, and if our solution actually delivers 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?
- Free comments
The following picture presents an example of such a customer feedback form.
Feedback Collection 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. This is totally 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 key 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 value proposition of the product is delivered to the customer.
Build
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
This is not about measuring number of requests, rate of successful requests, number of customers. This 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 ultimately increase the conversion rate of users. From that, we can derive to key metrics that showcase how well this API product serves the our customer:
- Rate of successful vs. unsuccessful identity verification requests.
- 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 it’s based on assumptions, the metrics give you insights about 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.
Learn
In order 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.
Personally, 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 greatly use it for the Daily API pitch.
great “knackige” overview -> I am missing one important part in the “measuring value” part –> how to derive the best suited business model and price? While engaging with the customer these topics should be on the table as well from the beginning b/c only if the customer has an interest to pay the delivered value it will be a successful project, and it is interesting to understand how the customer “perceives” the value – it might differ a lot from what the API provider thinks
Bulls-Eye, Frank. We added a new chapter in which we discuss business models for APIs. There is more than just transaction-based pricing (pay-per-use), etc.
I think he key is knowing the pain of your customers and their gain when they use your API. This way, you can do value-based pricing. One single API request might cost 1000$ instead of 0.01$. If we just expose APIs without knowing customer’s problems and the value the API provides, we cannot reasonably price the API (or we have to sell it very, very cheap).
Additionally, there are many possibilities to get indirect revenue from an API product: collect data for other purposes, sell more other products and services, integrate business partners, etc.