API Product Management
Table of Contents
I Setting the Stage
- 4. Introduction
- 5. Why API
- 6. Understanding API
- 7. Understanding Digitalization and Digital Transformation
- 8. Two Breeds of API: API Products and API Solutions
- 9. Case Studies
II API Product Design
- 10. Value Proposition Interface Canvas
- III API Product Strategy
- IV API Product Execution
- V Closing
After passionately driving API programs for years, accelerating digital programs in Telco, Finance and Automotive industries, and after talking to countless experts and managers in both Business and IT, I am highly qualified to guess why you are reading this book.
Your organization is currently trying to leverage APIs and go digital. You have endless meetings on teams, roles and structure Debates rage over starting internally, externally, or even at all. And of course, you are discussing governance - with a large or a small ‘g’. The people you are talking to don’t know anything about APIs. They never wrote code, or they stopped coding twenty years ago Enterprise architects still buzz confidently through the office aisles They see the corporate future as a universe of omnipotent mega-systems - based on microservices, of course.
Your organization is trying to do it right, but getting it wrong …
Management keeps API design within the silos, thinking ‘integration-first’. There is a little understanding of products, services, design or development API-first, contracts, assets, resources and methods all take on new meanings. Analytics is yet another fancy-feature promoted by your gateway vendor. And of course, the first API your team has to expose is a point-to-point connection between two existing systems … so, nothing like an API !
Is this enough? How much is true? How can this be? It will always look like this until you learn Product Management. Amancio and Andrea learned the hard way because this book was not yet written. Here, they describe is the whole approach to API Product Management based on real-life experience and the deep conviction that Product Management is key to a successful API program.
Amancio, Andrea - your book is a huge achievement, adding value throughout our community. It will become the mandatory pre-read for digital practitioners allowing them all to benefit from your experience and opinions.
Kay Lummitsch - The Digital Journeyman | Zurich - Switzerland, Eastern 2018
3. About the Authors
We are working on APIs and API products for several years, and throughout that time we have been in search of a way for building successful API products that make the difference.
We started sharing our experiences and lessons learned of our API journey and API product management methodology at various occasions such as the APIDays.io with great reactions.
Our mission is to help product managers to create value. To this goal, we are writing the API Product Management book and share our methodology as early as possible, one after the other.
Andrea Zulian is a product manager, agile coach, digital transformation consultant, and entrepreneur. He helps companies and organizations to succeed in their digital journey applying Lean methodologies and intrapreneurship. As team leader and senior API product manager for a leading telecommunications company in Europe, he developed and applied the API Product Management methodology launching successful products and services.
How to get in touch with Andrea
Amancio Bouza, PhD
Amancio Bouza has a diverse set of experiences as principal consultant, product manager, API technical lead, startup entrepreneur, Lego creator, scientist, cardist. He helps companies to identify and create business value combining creative ideation, execution, and technology. As hands-on principal consultant, he drives new ideas like API vs VPI and co-developed and applied the API Product Management methodology launching successful products and services.
How to get in touch with Amancio
I Setting the Stage
4.1 What is API Product Management?
API product management deals with identifying, planning, forecasting, production, and marketing of API products at all stages of the API product life-cycle. In this book, we present our API Product Management methodology, which we developed, applied, and tested over the recent years.
The API Product Management methodology is a systematic process based and inspired by popular methods (e.g., lean product management, Lean Startup). The methodology consists of three pillars:
- Desirability: Find API products that customer wants
- Viability: Define the product strategy to build a profitable API product
- Feasibility: Develop the API product (feasibility)
4.2 Why are API Products Hard?
First, there is a misconception about the difficulty of developing APIs. Technically, it is quite simple to build the APIs right. Of course, there are some best-practices about good API design and various philosophies and perspectives on what is right and what is more right.
Build API Right vs Build Right API
It is simple to build APIs right. You just need to know what application you want to expose and expose the functionalities one by one. This is known as the inside-out approach.
However, it is difficult to build the right API that help customers getting their job done and is worth solving. And this is what this book is all about: Build the right API and how.
To build the right API, we need to get out of the building and use a customer-centric approach to design APIs. To this goal, we should even forget about APIs to focus on the customer’s job-to-get-done or rather customer’s pains.
This is what we call the outside-in approach. It’s hard but the best approach to build the right API. And this the one purpose of this book and the API Product Management methodology: make the outside-in approach straightforward to you.
You Own the Interface, Not the Application
A company’s asset (e.g., software application, service) is the foundation for an API product thus posing a conflict situation with stakeholders. Typically, an asset has an owner. The owner might be known as product manager, business owner, product or application owner, or similar.
We as product leaders want to build on top of these assets, which weren’t intended the extra use via APIs, internally or externally. Typically, API pose additional load on backend applications and further security requirements. This is one of the aspects why stakeholder management is essential, especially for API product managers.
4.3 What will You Learn from this Book?
In this book, you’ll learn the following:
Part I: Setting the Stage
- How to think about API with regards to interfaces to a value proposition
- Explain the differences between digitization, digitalization, and digital transformation and how they relate to API products
- Understand the difference between API solution and API products and their role in the company’s daily business, tactics, and strategy.
Part II: API Product Design
- How to find desirable API products
- How to match your company’s assets to customer’s needs and define proper API value proposition
Part III: API Product Strategy
- How to describe and communicate the product strategy for an API product
- How to manage the product life-cycle of an API product
- How to define the ambition of an API product
- How to find the relevant stakeholders and how to involve them
- How to select the right business models for an API product
- How to define the roadmap for an API product using business goals
Part IV: API Product Execution
- How to mitigate risks
- How do develop APIs in an agile and iterative way
- How to validate quickly and cheap with customers with respect to desirability
Part V: Closing
- How to engage your API developers with API products
- How to pitch an API product
4.4 Is this Book for You?
API Product Management is for:
- Product managers who want to either build API products or build APIs as features of existing products
- API program leaders who drive an API program in a company and want to create business value or for the company or even enable digital transformation.
- Product owners who are responsible for planning the development of API products
- Architects and technical leads who interested in well designed APIs and identifying opportunities to digitalize business process and most reuse.
- Innovators who want to unleash the power of API for the digital economy
- Developers who are interested in becoming successful product managers or entrepreneurs
- CDOs who drive digital transformation and new digital business model to establish the company in the digital economy and API ecosystem
- CIOs who look for how to facilitate innovation
- Business managers, directors, and vice presidents who want to understand the value of APIs
Please note that this book is not about API interface design, API architecture, micro-services, technology or tools.
4.5 How is this Book Organized?
Generally, successful products meet three essential criteria:
- Desirability: Do customers exist who want the product and will buy it?
- Viability: Should we build the products by means of making the product profitable?
- Feasibility: Can we build the product with the resources we have?
The key to a successful API products is finding the intersecting area between desirable, viable, and feasible API products. The following figure presents this criteria for the most valuable design.
Our job as product leader is to design the API product such that it meets all three criteria.
We built the API Product Management methodology around this three criteria. Therefore, we structured the book accordingly.
- API product design addresses desirability of a API product
- API product strategy addresses the viability of a API product
- API product execution addresses the feasibility of a API product
Part I: Setting the Stage
We need to know why we do what we do to make the right decisions and do the right things. Without this, we lose focus and get lost in irrelevant, technical details.
For that reason, this part describes why API are so relevant for almost all companies across industries and how you should set the context to make it successful.
Further, you’ll find a brief introduction to APIs, which might be valuable if your aren’t yet familiar with APIs.
Part II: API Product Design
When we try to find a problem for a solution, the chances for success are typically low. The better way is to start with a relevant problem and create a solution.
“Love the problem, not the solution”, Ash Maurya (inventor of Lean Canvas)
The chapters in this part will present how to explore customers’ jobs-to-get-done, problems, and pains to find and define desirable API products.
To this goal, this part presents the methods to explore and retrieve what customer needs and jobs customer wants getting done. This involves amongst other things design thinking, jobs-to-get-done, and value proposition interface.
Part III: API Product Strategy
Every strategy needs a plan. Most plan As don’t work. However, it makes it straightforward to pivot and iterate from plan A to a plan that works.
The chapters in this part explore the viability of API products. To this goal, this part presents the method to explore and define the strategy to make a profitable product. This involves amongst other things API product canvas, business model, stakeholder management, and roadmap.
Part IV: API Product Execution
The chapters in this part describe how to execute the product strategy, i.e., building API products. To this goal, this part presents the methods to apply lean startup and agile methodologies to the API product development. This involves amongst other things,
Part V: Closing
Being successful is simple if you are working in a perfect environment that perfectly supports you. However, the world is not perfect and neither our environment. Ultimately, success comes from adapting to environments and maximize the outcome.
The chapters in this part reflect upon some organisational aspects, draw some conclusions, and offer some recommendations.
5. Why API
6. Understanding API
7. Understanding Digitalization and Digital Transformation
Who is also confused by the terms digitization, digitalisation, and digital transformation? Hands up! Well, at least I was. That’s for sure because people use those terms as synonyms or mixing them.
Nevertheless, it’s important to differentiate between the three to grasp how they relate to both breeds of APIs, namely API solutions and API products.
In the following, we explain the three terms and how they relate to digital technologies such as API.
7.1 What is Digitization?
Digitization refers to creating a digital representations of physical objects. For instance, we scan a paper document save it as a digital document (e.g., PDF). In other words, digitization is about converting something non-digital into a digital representation or artefact. Computer systems can then use it for various use cases.
An API doesn’t digitize. However, an API can play the role of integrating two computer systems to reduce media breaks.
For example: a user enters personal info into a mobile app. The mobile app sends this info to an API that will push the info into a backend system or database. The data is then accessible for other computer systems and use cases.
What is the Business Value of Digitization?
Digitization itself has no business value. However, it lays the foundation for business cases that leverage the data. In other words, it’s the enabler to create business value, which needs data.
7.2 What is Digitalization?
Digitalization refers to enabling, improving or transforming business process by leveraging digital technologies (e.g., APIs) and digitized data. That means that digitalisation presumes digitization as described in the previous section.
For example: a company hires a new employee who will need a mobile phone with subscription to communicate with customers and his team. As part of his onboarding, the employee has to write an e-mail to the according fleet manager who manages both. The fleet manager will send a fax with the employee’s info to the telecommunication company (telco company) to order both. At the telco company, a customer agent will enter the info from the fax into the system and start the order fulfilment process. After some days the fleet manager receives the phone, a subscription, but without SIM card. The fleet manager waits until the SIM card arrives and sends everything to the employee. After two weeks, the employee is ready to communicate with his team and customers.
What if we digitalize the onboarding of a new employee? When HR employes an person, an HR process gets triggered that will automatically order a mobile phone, subscription, and SIM card via the telco company. The order triggers automatically the order fulfilment process. The telco company will send everything at once to the employees workplace address. The employee will already his working mobile phone from day one.
To this goal, the telco company offered an API to order mobile phone, subscription, and SIM card. The company integrated the API into it HR onboarding process and triggers it automatically.
What is the Business Value of Digitalization?
The business value of this digitalisation example consists of three values:
- Employee is productive and can create value from day one because he can communicate with customers and his team.
- Fleet manager gets automatically updated about the new employee, the mobile phone, and subscription. He can focus on supporting his employees rather than translating and e-mail into a fax and collecting goods.
- The telco company reduces costs for the order fulfilment process. The customer agent can focus on value generating interactions with customer and invest more time into a better customer experience.
Ultimately, part of the onboarding process (getting a mobile phone and subscription) is improved and even transformed. More specifically, the process is automated and reduces manual effort completely.
This is an example of two companies who leverage digital technologies like API to improve or rather transform business processes.
7.3 What is Digital Transformation?
Digital transformation is the profound transformation of business activities, competencies, and business models to fully leverage the opportunities of digital technologies.
For example: a company has personal information about many customers. Other companies have to verify person info to do business (e.g., insurance companies). Based on the customer info, the company provides an identity verification product for other companies who want to verify a person’s information. And since the company has so many customer info, other companies likely use this identity verification product.
What is the Business Value of Digital Transformation?
Please note that identity verification wasn’t a competency of the company until now. However, the company identified an additional business model based on customer info that might complement or even supplement its current business and market. This is digital transformation.
This is an example in which a company fully leverages digital technologies to transform business activities, competencies, and business models.
Digitization refers to creating a digital representations of physical objects. Digitization itself has no business value. However, it lays the foundation for business cases that leverage the data.
Digitalization refers to enabling, improving or transforming business process by leveraging digital technologies (e.g., APIs) and digitized data. The business value of digitalisation consists typically of efficiency in terms of cost reduction, speed, and simpler business processes.
Digital transformation is the profound transformation of business activities, competencies, and business models to fully leverage the opportunities of digital technologies. The business value of digital transformation lies in transforming business activities, competencies, and business models to adapt to changes.
8. Two Breeds of API: API Products and API Solutions
Everybody is talking about APIs, API products in particular, and its key role in digitalisation and digital transformation. Generally, we associate APIs with agility, rapid innovation, business transformation and digitalisation. No wonder that everybody wants to adopt APIs. So far, so good.
Well, when we start our API journey and build APIs, we quickly realise that reality doesn’t meet our expectations. For example, we may build APIs on top of Web services and end up with yet another layer of abstraction. Or we build an API to integrate two specific computer systems and replace one integration pattern (e.g., Service-Oriented Architecture a.k.a. SOA) with another one. Both adoptions of API are typically far away from what we want, namely agility, rapid innovation, and digitalisation. But why does it go wrong?
There are two breeds of APIs, namely API solutions and API products. Both are different in nature how they provide value to an organisation, how they impact business strategy, how they relate to digitalisation and digital transformation, and what approach we need to get it.
In this chapter, we provide you a model to understand where in an organisation API solutions and API products prosper and how both relate to business strategy, tactics, and operations. Further, we’ll show the business value of API solutions and API products with respect to digitalisation and digital transformation.
In the following, we present the two breeds of APIs, where in an organisation each prospers and the reasons why. This forms the model for understanding both breeds of APIs. It will help you either to setup API journey/program or to make the right adaption to your current journey to meet your goals.
8.1 Two Breads of API and Paradigm of Change
Peter Drucker was a master in the field of business thinking. I stumbled upon his Paradigm of Change Model, which I found very useful to understand both breeds of APIs.
Peter Ducker’s Paradigm of Change model suggest that an organisation can be described with the following three components:
- Strategy (What-Should-Be): strategy describes what an organisation wants to accomplish. In other words, where the company should be. Strategy is transformational.
- Tactics (What-Will-Be): tactics describes how the organisation is accomplishing the goal. In other words, what the company will do. Tactics is transitional.
- Operations (What-Is): operations describes what an organisation is doing. In other words, what the company is right now. Operations is traditional.
Strategy, tactics, and operations are the components that describe the constant fluctuations of an organisation.
The three components are depicted as Venn diagram in the following figure. As you see, they overlap. The intersection of strategy/tactics, strategy/operations, and tactics/operations is where the real power of APIs are.
In the following, we’ll use this model to present the two breads of APIs, where the prosper and why, and how the provide business value.
8.2 API Solution is the Bread of Operations
Every organisation has to ensure that their operative business runs as smoothly as possible. It’s the foundation of a healthy organisation and sustainable success.
Hence, it’s important standardise processes to optimise them with respect to time, cost, and quality. When you standardise processes, you can define meaningful metrics, start measuring, and monitor KPIs.
Naturally, every organisation runs into business problems, which needs to be solved. To this goal, organisations typically apply critical thinking to solve business problems.
“Critical thinking is the objective analysis of facts to form a judgement”, Wikipedia, Critical Thinking.
Hence, critical thinking is appropriate to solve business processes because you can analyse them and evaluate KPIs to make fact-based decision about what to improve or change.
Generally, API solutions are built to reduce costs and improve quality of processes through standardisation.
8.3 What is an API Solution?
An API solution consists of one or several APIs that solve an integration problem. More specifically, an API solution is an integration solution between computer systems to enable inter-communication.
In the beginning of an API journey, API solutions are the most popular breeds. If designed well, they may provide a simple layer of abstraction that can be used by engineers without profound domain knowledge. E.g., an organisation may have various systems with customer info. An API solution may provide one single endpoint that consolidates this info.
How can you spot an API solution? Typically, IT architects and business analyst work on API solutions. The computer systems are known during the API design phase. The reuse of an API solution is often limited due to its design dedicated to the involved computer systems.
Architects and engineers strive for generic solutions in general to enable reuse. This is no different for API solutions. In theory that works perfectly in practice. However, in practice theory doesn’t work.
We tried to create API products from API solutions. We had two motivations to try it:
- API solutions are funded by projects. So, let’s be smart and use it as seed money to build an MVP or enhance an API product.
- We may satisfy the project with an API solution and leverage the work for our own agenda. Let’s exploit synergies.
However, projects have many stakeholders (e.g., business project manager, architects, product owners) and goals (e.g., budget, schedules, staffing). Generally, time, budget, and staffing constraints are quite tight and don’t provide you enough space to create new products. Nevertheless, projects may be useful to enhance your existing product. But be careful not to add specialisations to your API products, which will render it less reusable. A clear product vision will be is key.
In the end, we were usually left with a highly specific API solution and many dependencies.
API solutions prospers within operations or the What-Is. The reasons are that the problems to solve are precise and the outcome measurable. Typical problems are integration of two computer systems or automation of business process X to improve speed and reduce costs.
8.4 What is the Business Value of API Solutions?
API solutions enable faster and cheaper business processes. Right, but how? Organisations leverage digital technologies such as APIs to enable, improve, or even transform business processes. This is digitalisation and API solutions are one approach to digitalisation.
An API solution enables the automation of the interaction between computer systems. Automation may reduce significantly manual efforts and thus making processes cheaper and faster. Automation requires standardisation, which fosters higher quality.
8.5 API Product is the Bread of Tactics
A sustainable organisation needs the ability to adapt or it will die. The proper adaption of new technologies is one element for sustainable business success.
As our friend once stated and became the slogan of one major API conference:
“Adapt or Die”, Kay Lummitsch
The right business strategy is essential. However, good execution of a strategy is often challenging without the proper tactics. The goal is clear but the problems to solve not. This is when design thinking shines. What is design thinking?
“Design thinking in business uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”, Wikipedia, Design Thinking.
Thus, design thinking is a feasible method to find optimal solutions that satisfies the strategy, limitations of an organisation and customer needs. Limitations of an organisation can be staff resources, skills, time, money, etc.
Generally, API products help customers getting the job done. To this goal, API products address customer pains and offer gains. API products have a business model and thus creating value for both the organisation and its customers.
API products prospers within tactics or the What-Will-Be. The reasons are that the problems to solve are precise and the outcome measurable. Typical goal is to explore and find new business models thus, impacting the strategy it self. This is digital transformation in its core.
8.6 What is an API Product?
An API product consists of one or several APIs that provide an interface to a value proposition. In other words, an API product consists of value proposition interfaces or rather VPIs. In contrast, API solutions consists of API, which don’t provide an interface to a value proposition. The value proposition of API solutions is creating the communication link between computer systems.
From my experience, every organisation has at least one obvious opportunity for an API product. For telcos, it’s SMS, an API to send SMS to people’s mobile phones. We call it the “Hello World” product, which demonstrates the simplest form of an API product: a monetized API that provides one simple interface to a digital product.
How can you spot an API product? Typically, an API product is owned by a dedicated API product manager. Nevertheless, APIs can also be used as an extra feature of an existing product. But that’s a feature and not an API product. Please note that there is a great potential for conflicts and opportunities between API product managers and product managers.
Since an API product has a business model, it targets a market out side of the organisation. But that shouldn’t restrict its usage only to the external market. You might apply a different business model within the organisation or rather internal market.
8.7 What is the Business Value of an API Product?
API products are the key to new or enhanced business models. You can target existing or new markets with an improved or new digital products powered by APIs.
It becomes interesting when an API product doesn’t support the current business strategy. Your management will either trash it or it will transition the strategy into a new one. This is digital transformation, leveraging the full capability of digital technologies that transforms the business of your organisation.
Essentially, there are two different breeds of APIs: API solutions and API products.
API solutions are APIs to solve an integration problem. For example, API solutions can integrate some computer systems or automate a business process. API solutions is an approach to adopt the capability of API as digital technology to current integration tasks and business processes.
API solutions enable the digitalisation of business processes, which become often automated. The business value of API solutions are typically faster, cheaper, and standardised business processes.
API products are APIs that provide an interface to a value proposition, i.e., VPI. A business model is fundamental part of API products. Products powered by APIs are an approach to fully leverage the capabilities of APIs as digital technology and thus, enabling digital transformation. API products are a tool of tactics to meet the goals of a business strategy.
API products enable digital transformation of your business models and strategy. The business value are complementary or supplementary business model. This helps an organisation to adapt to changing customer needs and market situation. This is crucial for sustainable success.
Be aware about the three components of this model that are operations, tactics, and strategy. Define your ambition and goals and how you want to contribute to the strategy. Do you want to drive digitalisation or digital transformation. Both have a different motivation and scope.
The API Product Management book focus on methods to create API products. Nevertheless, you can apply the methods to create API solutions as well.
9. Case Studies
II API Product Design
10. Value Proposition Interface Canvas
The Value Proposition Interface Canvas makes it explicit how you are creating value with your API for your customers and how you are providing value. It is a tool that helps you to systematically understand the customer needs and to design API products your customer wants. It makes the difference between building an ordinary API or an interface to a value proposition. We refer to an interface to a value proposition as Value Proposition Interface (VPI).
Let’s imagine you’re feeling sick and feeling pain just everywhere. You go to the pharmacist, and he tells you: “Listen, I can give you full access to chemical elements in the periodic table. You have the full freedom of combining them to create your cure. My offer consists of over 100 chemical elements that empowers you to build whatever you dream of”. Most enterprises fail with their API program because they focus on their internal applications and how to generically expose them without taking customer needs into account. We refer to this approach as application-driven API approach, which is about providing an interface to an application.
Now, let’s imagine a second pharmacist: “Listen, I’ve got medicine that will relieve your pains and will make you healthy again. You’ll enjoy life again and perform at work as if nothing happened.”. Contrary to the first pharmacist, the second pharmacist understands the customer’s problem and offers a medicine that promises to cure the customer. The medicine might combine some chemical elements (from the first pharmacist) to provide the right solution for the customer’s problem. But, why should we bother the customer to become a pharmacist expert first? We refer to this approach as the customer-centric VPI approach, which is about providing an interface to a value proposition (VPI) to help the customer.
Both approaches, namely the application-driven API approach and the customer-centric VPI approach, are viable approaches. Ultimately, every successful product, API product in particular, needs to satisfy a customer need by relieving pain or creating gains for the customer. Don’t expect your customer to be interested in becoming a pharmacist expert first. He just wants to get his job done.
The application-driven API approach is viable for enterprise integration. It’s the traditional approach when APIs are driven by the IT department, which is generally a cost center. IT architects and solution designers have the functional knowledge, power, and full control over what systems talk to which ones and how. For that reason, they might want to build a portfolio of reusable building blocks (APIs) to optimize for IT project costs, maintenance, time-to-market, resilience, and scalability. They are domain experts, API pharmacists. Fair enough.
The customer-centric VPI approach is viable for API products and intended for external and internal API consumers who are not domain experts and also don’t want to become one. That’s the difference between customer-centric API design and application-driven API design.
The following picture presents the application-driven API approach. Many API programs in enterprises start with identifying interesting applications exposing generic interfaces to these. To be honest, we did this too. In almost all cases, nobody cares about these APIs because these APIs either solve an already solved integration problem or they don’t help to solve somebodies problem. You can hope for a lucky punch at best or finally start to talk with prospect customers first.
10.1 What is the Difference Between Value Proposition and API
The value proposition is not the same as the API, which is a technical solution. More precisely, the value proposition describes what value you offer to the customer and why the customer should buy it. The API describes how you provide the value to the customer.
Every product has a value proposition and solves a problem. Same applies to API products. However, the nature of an API product is different to ordinary products and creates plenty of confusion about what is an API product. The reasons is that an API product not self-contained because it requires to connect to data, apps, products & services, or business processes. Nevertheless, when it is treated as a product it becomes an autonomous product that provides added value to customers.
Let me explain the difference between an ordinary product, a value proposition, and the role of the API or rather VPI with the Super Mario analogy, which is presented in the following figure.
Super Mario, the famous game character, represents an ordinary prospect customer. The Fire Flower represents your company’s product. What you sell is not the Fire Flower or rather the product. You sell Super Mario who can easily kill enemies (value proposition) to better save the Princess (job to get done). That’s what you sell and not the Fire Flower. In other words, a prospect customer doesn’t care about your product.
So, what is the API if not the Fire Flower? Well, the API provides an interface to your value proposition, which is Fire Super Mario who kills enemies with fireballs. That means that the controller is the API. As an API product manager, it’s your job to give the player the perfect tool to kill enemies. You can influence if it’s a fireball, guided missile, auto-fire option, etc.
What are relevant KPIs for a VPI?
Traditionally, success of an API is measured by the number of requests. However, the number of requests doesn’t reflect the value very well. So, let’s go back to the Super Mario analogy. What are relevant KPIs for the API? Is it the number of times a player hit the button to throw a fireball? No! Relevant KPIs indicate the value the player gets from throwing fireballs. More specifically:
- Number of enemies killed by fire balls
- Amount of score points received with fire balls
- Number of coins collected with fire balls
- Time until princess is safed
These four KPIs indicate how much value was provided to the customer. Nevertheless, such KPIs are sometimes quite difficult to measure and often requires you making assumptions. But knowing the customer’s processes, applications of the API, and usage pattern may provide valuable implicit feedback to estimate these KPIs. For more see Chapter KPIs for API products.
10.2 Foundations of Value Proposition Interface Canvas
The Value Proposition Interface Canvas is based on the Empathy Map to get a deep understanding of the customer and Osterwalder’s Value Proposition Canvas, which complements the Business Model Canvas.
In the following, we present both methods. But first, let’s clarify who is the customer.
Who is the customer?
We need to differentiate between the customer and the user. The customer is the one who has a specific need and buys a product to satisfy this particular need. A user is the one who is using the API product to get the job done and to satisfy the need.
- Customer: A customer is a person who needs a job to get done. He buys a product to facilitate getting the job done.
- User: A user is a person, typically a programmer, who uses the API within an application.
So, who is the developer or rather API consumer? Well, a developer is the user, the customer, or both. Typically, the developer uses the API in an app and therefore being a user. However, independent app developers or empowered developer may decide to use commercial APIs to develop the next big thing. These developers are looking for something to get the job done more easily and decide about making or buying (make-or-buy decision).
The user has different needs than the customer, which are more related to your API management platform. For instance, the user is interested in the API documentation to understand what it offers and how to use it, security mechanisms, error handling, sandbox to test and integrate your API, SDKs, test data, etc.
The job of an API product manager is to provide first a value proposition to the customer and then a great user experience to the user or rather developer. This is in accordance with the Hierarchy of API Design Principles, which declares providing value as the fundamental key for a great API product. Then, providing great user experience comes next.
Empathy Map Canvas
The Empathy Map Canvas is a method for gaining a deeper understanding of audiences, including customers, users, and any other players and stakeholders in any business ecosystem, within a given context (e.g., getting a specific job done). The method lets you walk a mile in the person’s shoes to gain his perspective. Even if you don’t understand the customer well, you can at least identify gaps in your understanding of the person.
The empathy map canvas consists of three main parts: context, observable phenomena, and internal thinking.
- Context: The context describes the person and the goal for which we want to gain deeper understanding.
- Observable phenomena: The observable phenomena include what the person sees, says, does, and hears. This gives us a notion of what information he gets and what impact it has on him.
- Internal Thinking: Based on the context and the observable phenomena, we can deduce what a person thinks and feels. From this, we can conclude his pains and gains.
How to complete an Empathy Map Canvas?
You start from the goal on the top to set the context. To this purpose, define the person or rather customer you want to describe and then the jobs they want to get done.
Then, you describe the observable phenomenas in clockwise order. Firstly, list the things the see, read, and observe from others. Secondly, list the things you heard them saying. Also add the things they intend to say and they say between the lines. Thirdly, list the things the do today. Lastly, list the things the hear from others.
Finally, describe what they think and feel. To this goal, describe their pains, fears, or frustrations as well as their gains, needs, wants, hopes, and dreams.
Benefits, Limitations, and Adaptations
You gain a deeper understanding of the customer with a completed empathy map canvas. The first step towards a great product is to feel empathy with your customers, understand their pains, needs, and wants. Hence, a completed Empathy Map Canvas is a great input to design a viable value proposition, which you can facilitate with the Value Proposition Interface Canvas.
The Empathy Map puts much attention on observable phenomenas. However, that is irrelevant to define a value proposition. For this, we need to know pains we are relieving and what needs and wants we are satisfying.
Hence, for the Value Proposition Interface Canvas, we take over both parts context and internal thinking, i.e., the customer’s jobs he needs to get done as well as what he thinks and feels. More specifically, who is the customer and what is the job he needs to get done as well as what are his pains and gains.
Value Proposition Canvas
The Value Proposition Canvas (by Alexander Osterwalder) is a method to express a value proposition and complements the Business Model Canvas.
The value proposition canvas consists of two main parts: customer profile and value map
- Customer Profile: The customer profile describes the jobs a customer needs to get done as well as the pains in getting them done and potential gains.
- Value Map: The value map presents the products & services that form the product. Further it presents the product features, which relieve some customer pains or create some customer gains.
How to complete a Value Proposition Canvas?
You start with the customer. Firstly, list the jobs that the customer wants to get done. Secondly, list the pains to get the job done. Lastly, list the gains customer would love to have.
Afterwards, you define your value map. Firstly, define the products & services you want to offer to the customer. Secondly, collect all corresponding features and classify them as pain relievers or gain creators.
Finally, connect the pain relievers from the value map with the corresponding pains from the customer profile. Analogously, connect the gain creators from the value map with the corresponding gains from the customer profile. As a result, you see how you create value for the customer.
Benefits, Limitations, and Adaptations
The Value Proposition Canvas helps to make it explicit how products & services are creating value to the customer. To this goal, it presents clearly which product features relieve which customer pains and what product features create gains for the customer. In fact, the Value Proposition Canvas is the base of the Value Proposition Interface Canvas.
However, the original Value Proposition Canvas lacks the notion of API as a product. An API relies on existing sources, (i.e.e, data, apps, products & services, business processes). Think of your API as an interface to a value proposition that allows you to select and alter features of these sources. Then, you’ll start shaping innovative digital products that create value to customers and reuse existing capabilities of your company. Hence, for the Value Proposition Interface Canvas, we extend this canvas by the notion of an interface to the value proposition. This interface is our API or rather the Value Proposition Interface (VPI). The customer doesn’t care what products & services, data sources, apps, business process, we use in the backend.
10.3 Value Proposition Interface Canvas
The goal of the Value Proposition Interface Canvas is to make an API’s value proposition explicit to validate it and eventually find a good problem-solution fit. The canvas consolidates the Empathy Map Canvas and the Value Proposition Canvas, which complements the business model canvas. The Value Proposition Interface Canvas consists of two parts: the Customer Profile and the Value Proposition Interface Map.
- Customer Profile: the customer profile maps the jobs that the customer wants to get done as well as the derived gains and pains that facilitate or hinder getting the job done.
- Value Proposition Interface Map: The Value Proposition Interface Canvas maps your company’s relevant apps, products & services, data, and business process. Based on that, it maps the derived pain relievers and gain creators, which are related to the customer’s pains and gains, respectively. Pain relievers solve a customer’s pain and gain creators facilitate a customer’s gain. Generally, the pain relievers and gain creators form the value proposition. The interface represents the Value Proposition Interface (VPI), which is an API. Th VPI describes the interface to the value proposition and how the customer can access them.
The Value Proposition Interface Canvas is rather about the flow that connects the Customer Profile with the Value Proposition Interface Map. Consider how each box talks to each other rather than thinking of each one as a separate lists.
In the following, we’ll guide you through the process of completing a Value Proposition Interface Canvas.
Pain Reliever Flow: Solve Customer’s Pains
Customers are primarily interested in solving problems and in relieving their pains. Therefore, relieving customers’ pains is crucial with respect to their buying decision. Truth is, gains don’t sell. But they make up for good differentiators and added value.
In the following, we present how our API product is helping the customer to get his job done by relieving his pains.
How to complete the Pain Reliever Flow
Start with the Customer Profile. Be very clear about the jobs that the customer wants to get done and what the pains are. Afterwards, continue with the Value Proposition Interface Map. List the value sources (e.g., data sources, apps, business processes). Find pain relievers from those value sources that relieve the customer’s pains. Finally, translate the feature to the interface (API). The following figure presents the pain reliever flow. The numbers indicate the order in which they have to be completed.
- Customer Jobs: Describe the jobs the customer needs to get done.
- Customer Pains: Be clear about why those jobs are painful. Validate those pains with the customer.
- Value Sources: List relevant data sources, apps, business processes, and other products & services.
- Pain Relievers: List the features of your API product that will relieve their pain.
- Value Proposition Interface: Translate the product features to API features. More precisely, describe the API’s resources and methods.
Step 1 and 2 are straightforward. Likewise, Step 3 is straightforward, which requires knowledge about the company’s capabilities and functional knowledge.
However, most of the people get stuck in Step 4 because they typically just negate the pains of the customer and miss to explain how they will relieve the pain. Actually, pain relievers have to explain how they relieve pain rather than what pain they relieve. You can draw a line between the pain reliever and the pain to indicate what pain is relieved by the pain reliever. Sometimes, multiple pains are relieved by a single pain reliever or a pain is relieved by multiple pain relievers.
Here’s a simple trick to define pain relievers: end your pain relievers with a noun to describe a feature of your API product. Further, don’t just pull the features from your products, applications, business process or data. Think about them as the sources of value, which you can alter and interpret differently to formulate new features. For example, your customer data are also sort of verified identities, which you can use to provide a service to verify identities. So, in other words, API products can be new innovative products that reuses your company’s capabilities in new ways to solve new problems.
Step 5 is also straightforward and involves API design. Consider the Hierarchy of API Design Principles as guideline for the definition of the API. The pain relievers provide the value, and the interface provides the user experience.
Finally, we have some elements (customer jobs, pains, and pain relievers) that we can combine to a sentence that describes a value proposition. Now, you can provide a prospect customer something tangible to contemplate and you can validate your value proposition.
Gain Creator Flow: Boost Value with Gains
Truth is, customers don’t buy your product because to get gains. If their business is doing badly then customers are primarily interested in cost reduction. If their business is doing well then customers enjoy the current situation and don’t care much about improvements. Nevertheless, gain creators make up for good differentiators and added value.
In the following, we present how our API product is helping the customer to get his job better done by creating gains.
How to complete the Gain Creator Flow
Typically, customers talk about their pains the have to get their jobs done. Gains are different, however. They can be completely new elements of feature. That’s why it’s better to start again from the customer’s jobs rather than from the pains.
Analogously to the pain reliever flow, start with the Customer Profile. Be very clear about the jobs that the customer wants to get done and what gains facilitate the jobs getting done. Afterwards, continue with the Value Proposition Interface Map. List the value sources (e.g., data sources, apps, business processes). Identify gain creators from those value sources that facilitate gains for the customer. Finally, translate the feature to the interface (API). The following figure presents the gain creator flow. The numbers indicate the order in which they have to be completed.
Let’s define how we create gains for our customer. It is quite common to repeat a similar mistake as with the pain relievers that negate pains. All to often, customer gains just negate the pains.
- Customer Jobs: Describe the jobs the customer needs to get done.
- Customer Gains: Be clear about what can provide gains. Validate those gains with the customer.
- Value Sources: List relevant data sources, apps, business processes, and other products & services.
- Gain Creators: List the features of your API product that will create gain.
- Value Proposition Interface: Translate the product features to API features. More precisely, describe the API’s resources and methods.
Step 1 is straightforward whereas Step 2 is not. Contrary to pains, it’s difficult for customers to imagine gains if they haven’t seen it yet. In most of the cases, it’s up to us to think about gains that a customer hasn’t thought of. Nevertheless, they have to think that it’s amazing when they see it. To this goal, it’s important to know the customer and the job he wants to get done. Be creative!
Step 3 is again straightforward, which requires knowledge about the company’s capabilities and functional knowledge.
However, most of the people get stuck in Step 4 because they either mirror customer gains, but miss to explain how they will create gains, or the just mirror pain relievers. That’s why it is key to again start with the customer’s job. So, analogously to the pain relievers, you have to explain how they create gain rather than what gain they create. You can draw a line between the gain creators and the gains to indicate what gain is facilitated by what gain creators. Sometimes, multiple gains are facilitate by a single gain creator or a gain is facilitate by multiple gain creators.
Step 5 is also straightforward and involves API design. Consider the Hierarchy of API Design Principles as guideline for the definition of the API. The gain creators provide the value, and the interface provides the user experience.
Finally, we have some elements (customer jobs, gains, and gain creators) that we can combine to a sentence that describes a value proposition. Now, you can provide a prospect customer something tangible to contemplate and you can validate your value proposition.
10.4 Example of How to Use the Value Proposition Interface Canvas to Design an API Product
We briefly presented the API product ‘Identity’, an API product to verify identities, in Paradigm Shift: From API to VPI (Value Proposition Interface). Let’s us it as our example.
Here’s the situation. A company (our customers) wants to onboard users on their Web platform. These users are the end-customers. To this goal, they put a registration process in place to get users’ personal info, verify their phone number, and verify their home address. This is paramount for them because the company wants to build end-customer relationships and sell products via the Web platform to them.
Now, let’s take a look to the corresponding Value Proposition Interface Canvas.
Solve Customer’s Pains
Let’s start with the pain relievers. To this goal, follow the sequence as described in Section “Pain Reliever Flow: Solve Customer’s Pains”. In short, start with the Customer Profile, particularly customer’s jobs and pains. Continue with the Value Proposition Interface Map, particularly products & services, pain relievers, and interface.
Step 1: Define Customer’s Jobs
The customer wants to:
- onboard the customer
- get end-customer’s personal info
- verify customer’s personal info
- eliminate fake accounts
Step 2: Define Customer’s Pains
The customer has the following pains getting his job done. The pains are:
- Sending a letter by post to the end-customer’s home is expensive to verify his home address. It costs approx. 6$
- End-customers drop out of the onboarding process because verifications interrupt the registration flow. Particularly the verification of the home address interrupts the registration process by days and represents a great medium break.
- The registration process asks to many input info from the end-customer that make him drop out.
Step 3: Value Sources
We have the following value sources that we can reuse.
- Addresses API. It’s based on an internal GEO applications that manages all existing and future addresses. The main applications is managing the telecommunication infrastructure to existing homes as well as to building lots.
- SMS Token Validation API. It sends a token (secret code) via SMS to a specific phone number. The owner of that mobile phone has to enter the token on a Web form where it gets validated.
- Customer Relationship Management system. It contains all info about our customers.
Step 4: Pain Relievers
- Registry of all valid and existing addresses to verify if an address exists and is written correctly. It corresponds to the home address verification.
- SMS Token Validation to verify if the end-customer has access to the phone with the particular phone number. It corresponds to the verification of the mobile phone number.
- Registry of verified identities to verify personal info like first name, last name, and address. It corresponds to the personal info verification and the home address verification.
Step 5: Value Proposition Interface
The value proposition interface consists of the Identity API, which provides a method to verify a set of personal info. To this goal, it uses the customer relationship management system. This is an example of using an application and data for another business case.
The Address API and SMS API complement the Identity API to validate addresses and verify the owner of the mobile phone number. The API product can consolidate these three APIs or just the Identity API, which is also a facade to the Address API and SMS API.
- Identity Verification Resource. It represents the verification result of an identity’s personal info. A new resource can be created (POST) and retrieved (GET with a verification Id)
- Address Resource. It represents an existing address. It includes street, house number, zip code and city. An address resource can be searched for via query parameters
- SMS Token Resource. It’s generated and send as SMS to the a mobile phone number. It can be also used to verify the SMS token. A new resource can be created (POST) and verified (GET with mobile phone number and SMS token)
How to Create the Value Proposition Statement?
Combine the customer’s jobs, the pains, and the pain reliever.
Value proposition: We simplify the registration process by verifying the personal info (e.g., personal info, phone number, address) in real-time without interruptions and saving costs of sending a letter by post to verify an end-users address.
Please note that we don’t have the data of all citizens in our country. But for the ones we have, we can make it way simpler. This would be a great opportunity to collaborate with the competition who have comparable info about other citizens. Think big!
Boost Value with Gains
Let’s continue with the gain creators. To this goal, follow the sequence as described in Section “Gain Creator Flow: Solve Customer’s Pains”. In short, start with the Customer Profile, particularly customer’s jobs and gains. Continue with the Value Proposition Interface Map, particularly products & services, gain creators, and interface.
Step 1: Customer’s Jobs
The customer wants to:
- onboard the customer
- get end-customer’s personal info
- correct address info
- check legal of prospect customers to start customer relationship
Step 2: Customer’s Gains
The customer has the following gains that facilitate getting his job done. The gains are:
- high conversion-rate
- good user experience
- smart comparison of first and last names
- legal age verification
- cost control of using the API
Step 3: Value Sources
- Address Catalog that provides lists of cities, zip codes, streets and house number, and house names for a type-ahead input field.
- Multi-tenant Identity Verification History that allows our customer to access requested identify verifications and the results at a certain point in time.
- Birthdate Verification of a customer to check his legal age.
Step 4: Gain Creators
- Provide type-a-head search for addresses to help customer’s provide correct address
- Fuzzy end-customer name matching. Sometimes, end-customers provide short version of their name (e.g., Alex instead of Alexander), replace special characters with more simpler ones (e.g, é with e, ä *with ae*)
- Identity Verification History that provides the info about what personal info have been verified, how, and when for the purpose of audits and traceability.
- Birthdate Verification that provides an info if the end-customer is over 18 or 21. This is relevant to sell certain type of products and build a contractual relationship.
- Customizable SMS message, which our customer can customize (e.g., message text, sender) to provide the end-customer a consistent user experience.
- Multi-tenant dashboard that shows the customer the current costs for the identity verifications.
Step 5: Value Proposition Interface
- Identity Verification Resource. It represents the verification result of an identity’s personal info. It provides the birthdate and the customer’s language that can be used to personal content. The verification process will do a fuzzy similarity matching of names.
- Cities, Zip Codes, and Streets Resouces. They represent lists of all cities, zip codes, and streets.
- Customer Dashboard. It is a Web GUI to configure customize SMS messages and manage the API usage. This is not an API.
How to Create the Value Proposition Statement?
Combine the customer’s jobs, the gains, and the gain creators.
Value Proposition: We facilitate higher conversion rate, consistent user experience, and cost control by simplifying the registration process, fault tolerant identity verification, and providing a dashboard for cost control.
In this case, many features aren’t provided by the customer. In our case, we decided to build them. For instance, we extended our API management platform with a backend-as-a-service (BaaS) to provide the history of identity verification with multi-tenant capability as well as an elastic search for addresses. Further, we built a Web application to provide our customers a self-service capability to customize their SMS messages and to manage their API usage.
The Value Proposition Interface Canvas helps you to make it explicit how you create value for your customers. It considers the jobs that the customer needs to get done, his pains in getting them done and gains. Based on this, you formulate the features of your API product to relieve specific pains and create gains for your customer.
The completed Value Proposition Interface Canvas builds the foundation of your API design and corresponds to the Value Proposition in the Hierarchy of API Design Principles. Further, it helps to formulate a compelling value proposition that you can present and validate with prospect customers applying the Lean API Product Development method.
Lean Approach of Value Proposition Interface Canvas
The lean approach is applicable to the Value Proposition Interface Canvas. Generally, the Value Proposition Interface Canvas needs some iterations with the customer. Specifically, the gain creators tend to be what the customer doesn’t really want or make your API product not viable by means of pricing.
- Build: Create Value Proposition Interface Canvas
- Measure: Validate your assumption about the customer
- Learn: Learn from customer feedback and adapt the Value Proposition Interface Canvas
III API Product Strategy
11. Product Vision Board
12. Product Lifecycle Management
13. Ambition Matrix
14. Stakeholder Management
15. Business models
16. Goal-Oriented Roadmap
IV API Product Execution
17. Lean 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.
17.1 Foundations of Lean API Product Development
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.
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.
17.2 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.
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.
17.3 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.
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.
17.4 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.
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.
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.
18. Hierarchy of API Design Principle
19. API Product Pitch for Everybody