API Product Management
Table of Contents
I Setting the Stage
- 4. Introduction
- 5. Why API
- 6. Beginners Guide to API
- 7. Understanding Digitalization and Digital Transformation
- 8. Two Breeds of API: API Products and API Solutions
- 9. Case Studies
- II API Product Design
- 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, and 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 that 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 from our API journey and API product management methodology on 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 is an intrapreneur, product manager, and principal consultant who helps organizations to succeed in their digital journey applying lean methodologies, continuous innovation, and digital technologies. As a hands-on entrepreneur and engineer, he drives new perspectives on API like the Value Proposition Interface (VPI). He developed and applied the API Product Management methodology launching successful products and services. Amancio Bouza enjoys learning new things (e.g., cardistry, surfing, manga), building LEGO imaginations, gaming, cooking, wine, reading, and all kind of sports.
How to get in touch with Amancio
I Setting the Stage
We live in an age of unprecedented opportunity for innovation. Since the Internet and cloud computing, the world became hyper-connected regarding the interconnectedness of people, organizations, and machines (i.e., devices and apps).
As a result, the digital economy emerged. The digital economy refers to the economy based on digital computing technologies. Some of the most famous examples are GAFA and BAT. GAFA refers to the four American tech giants Google, Amazon, Facebook, and Apple. BAT refers to the three Chinese tech giants Baidu, Alibaba, and Tencent.
The API technology is one of the key drivers of the digital economy. APIs allow the interaction between people, organizations, and most notably machines. This enables new digital business models that have the power to disrupt entire industries.
However, many organizations struggle with exploiting their assets and build digital products. The number one reason is that these organizations build APIs to expose internal assets (i.e., applications, services, and data).
“We can not solve our problems with the same level of thinking that created them,” Albert Einstein
There’s nothing wrong with exposing assets via APIs. It might be even beneficial for an internal enterprise architecture concerning integration. It works great if architects command and control the usage of APIs within an enterprise. Outside of the controlled enterprise environment, however, it turns out that this inside-out approach typically doesn’t meet customer needs and therefore failing to meet expectations and business goals.
The ability to learn fast is a new competitive advantage. That’s because the costs and time effort for building products and go-to-market are at an all-time low. It’s about building the right product, not the product right. API is an unprecedented super-facilitator and yet simple.
Customer centricity and outside-in approach are the keys to building successful digital products based on APIs. Let’s start with your customers, the jobs they want getting done, and the problems to do so. That’s what guides you to do the right thing.
“Managing APIs as products increases the chances of digital business success,” Gartner
In this book, you’ll learn how to leverage APIs to exploit your organization’s assets and create innovative digital products that are based on APIs.
In the following, we’ll first present what API product management is all about and why it’s different from common product management. Then, we’ll discuss why it is hard to create the right APIs in contrast to engineering APIs right, which is rather straightforward. Finally, we’ll explain how this book is organized and what you can expect to learn from each part.
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 Startup and lean product management). 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
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, e.g., RESTful.
Building the right API is hard. You cannot construct it. Instead, you have to learn and discover what the right API is. Furthermore, you are often not in control of the assets that power the right API.
Build API Right vs. Build Right API
It is straightforward to build APIs right. You just need to select the application you want to expose. Then, you expose the functionalities one by one. This is known as the inside-out approach. Nowadays, there exists even a bunch of tools specialized in exposing backend systems in very few steps automatically. This is not the challenging part.
In this inside-out scenario, you need to design the interface as generic as possible because you don’t know who and for what it might be used. In other words, you need to maximize for flexibility to allow multiple future applications.
On the other side, it is difficult to build the right API that helps customers getting their job done and is worth solving. And this is what this book is all about: Build the right API and turn it into an API product.
To build the right API, you need to get out of the building, meet early adopters and customers, and use a customer-centric approach to design APIs. To this goal, you should even forget about APIs to focus entirely on the customers’ job-to-get-done or rather the customers’ pains. Customers care about their problems, not about API or technology.
This is what we call the outside-in approach. It’s undoubtedly leaving the comfort zone of your office desk. But it’s the best approach to build the right API. And this is the one purpose of this book and the API Product Management methodology: make the outside-in approach straightforward for you.
You Own the Interface, Not the Application
An organization’s assets (e.g., backend system, service, database) are the foundation for an API product thus posing a conflict situation with some stakeholders.
Typically, an asset has an owner. The owner might be known as the product manager, business owner, product or application owner, or similar. They manage running systems that deliver business value to the organization. Exposing these assets via APIs disturbs these environments. Especially they know the essential phrase: “Never touch a running system!” We, for example, faced many rejections in the beginning for this reason.
You as a product leader want to build on top of these assets, which weren’t intended to be exposed using via APIs, internally or externally. Typically, API poses 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?
The book is organized in multiple sections. Each provides relevant knowledge and methods to create successful API products. In this book, you’ll learn among other things the following:
Part I: Setting the Stage
In this part, you’ll learn about API and how organizations can leverage API to create business value.
- Explain to your organization the digital economy, why API is a must-have, and start a discussion why and how your organization can participate in the digital economy
- Understand the role of customer journeys to create or enter an API ecosystems
- Explain API to your business organization and make them excited about it
- Explain how API work and how an API management platform supports you in the API product life-cycle
- Differentiate between API stakeholders, especially API customer and API user
- Explain the differences between digitization, digitalization, and digital transformation.
- Classify API regarding digitization, digitalization, and digital transformation
- Understand how different breeds of API support and impacts an organization’s business strategy
- Know two different API products to use it as a benchmark for your own API products
Part II: API Product Design
In this part, you’ll learn about discovering and identifying desirable APIs and API products.
- Find desirable API products applying design thinking methods
- Retrieve customers’ needs and build a value proposition that matches customers’ needs with an organization’s assets using the Value Proposition Interface Canvas
Part III: API Product Strategy
In this part, you’ll learn about how to create a product strategy for an API product. This is one of the main tasks of an API product manager.
- Create, describes, and communicate an API product strategy
- Manage the product life-cycle of an API product
- Define the proper ambition of an API product
- Identify, classify, involve, and manage different and relevant stakeholders
- Select the right business models for an API product
- Define a roadmap for an API product that is executable
Part IV: API Product Execution
In this part, you’ll learn how to execute the strategy. In other words, you’ll learn how to validate, build, and verify the business value of an API product.
- Mitigate risks of building the wrong API product
- Develop APIs in an agile and iterative way
- Plan the API development and describe tasks
- Validate fast and cheap the desirability and viability of an API product before it is developed and after it is running in production
Part V: Closing
In this part, you’ll learn some practical tips about several aspects of API product management, organization, teams, and people.
- How to engage your API developers and inspire them
- How to pitch an API product
4.4 Is this Book for You?
We wrote this book having specific people and needs in mind. Hence, API Product Management is particularly relevant for:
- Product managers who want to build API products or build APIs as features of existing products but know little about API and the productization of APIs.
- Chief Digital Officers who want to drive digital transformation and new digital business models, and to directly impact the future of their organization and operative business of today and the future
- API program leaders who are driving an API program in an organization and want to create business value, lead digital, and drive digital transformation of the organization
- Product owners who want to how to plan and develop API products
- Architects and technical leads who wish to identify opportunities to digitalize business processes and design APIs.
- Innovators who want to unleash the power of API for the digital economy
- Engineers who want to understand why they do what they do, expand their horizon, and potentially to become API product managers or entrepreneurs.
- CIOs and CTOs who want to facilitate innovation in an organization
- Business managers, directors, and vice presidents who wish 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: Are there customers who are going to buy the product?
- Viability: Should we build the product or can we make the product profitable?
- Feasibility: Can we build the product with the resources we have?
The key to a successful API product is finding the intersecting area between desirability, viability, and feasibility. The following figure presents these 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. For this reason, we structured the book accordingly.
- API product design addresses the desirability of an API product.
- API product strategy addresses the viability of an API product.
- API product execution addresses the feasibility of an 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 this reason, this part describes why APIs are so relevant for almost all organizations across industries and how you should set the context to make them successful.
Further, you’ll find a brief introduction to APIs, which might be valuable if you 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 low in general. The better way is to start with a relevant problem and build a solution for it.
“Love the problem, not the solution,” Ash Maurya
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 customers need and what jobs they want 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 and relate it to your organization’s strategy.
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
Ideas are worthless if not executed.
“Ideas are a dime a dozen,” Mary Kay Ash
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 your environment. Ultimately, success comes from adapting to environments and maximizing the outcome.
The chapters in this part reflect upon some organizational aspects, draw some conclusions, and offer some recommendations and practical tips.
5. Why API
6. Beginners Guide to API
7. Understanding Digitalization and Digital Transformation
Who is also confused by the terms digitization, digitalization, 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 representation 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 artifact. 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 digitalization presumes digitization as described in the previous section.
For example, a company hires a new employee who will need a mobile phone with a subscription to communicate with customers and his team. As part of his onboarding, the employee has to write an e-mail to the corresponding 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 fulfillment 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 a person, an HR process gets triggered that will automatically order a mobile phone, subscription, and SIM card via the telco company. The order triggers the order fulfillment process automatically. The telco company will send everything at once to the employee’s workplace address. The employee will receive already his working mobile phone from day one.
To this goal, the telco company offered an API to order a mobile phone, subscription, and SIM card. The company integrated the API into it HR onboarding process and triggered it automatically.
What is the Business Value of Digitalization?
The business value of this digitalization example consists of three values:
- The employee is productive and can create value from day one because he can communicate with customers and his team.
- The 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 fulfillment process. The customer agent can focus on value-generating interactions with the customer and invest more time into improving 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 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 personal 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. Other companies will likely use this identity verification product because the company has so many customer info.
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 a 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 representation 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 digitalization consists typically of efficiency regarding 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.
|Digitization||creating a digital representation of physical objects||enabler|
|Digitalization||enabling, improving or transforming business processes||efficiency|
|Digital transformation||transforming business activities, competencies, and business models||new business model, adaption|
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. Human-Centered API Design
11. 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.
11.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.
11.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.
11.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.
11.4 Case Study: Identity
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