Apiproductmanagement Sample

API Product Management
Product Strategy and Execution for

the Digital Economy
Andrea Zulian and Amancio Bouza

This book is for sale at
http://leanpub.com/apiproductmanagement
This version was published on 2019-10-31
This is a Leanpub book. Leanpub empowers authors and

publishers with the Lean Publishing process. Lean
Publishing is the act of publishing an in-progress ebook
using lightweight tools and many iterations to get reader
feedback, pivot until you have the right book and build
traction once you do.
© 2017 - 2019 Andrea Zulian and Amancio Bouza

Tweet This Book!
Please help Andrea Zulian and Amancio Bouza by spreading
the word about this book on Twitter!
The suggested tweet for this book is:
Ultimate Guide to API Product Management - Product
Strategy and Execution for the Digital Economy:
http://api-as-a-product.com #API2VPI #API #VPI
#ProductManagement #DigitalEconomy #Digitalization
#DigitalTransformation
The suggested hashtag for this book is #API2VPI.
Find out what other people are saying about the book by
clicking on this link to search for this hashtag on Twitter:
#API2VPI
to our wifes and children
Contents
1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. About the Authors . . . . . . . . . . . . . . . . . . . 4
I Setting the Stage . . . . . . . . . . . 1

4. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
4.1 What is API Product Management? . . . . . 4
4.2 Why are API Products Hard? . . . . . . . . . 5
4.3 What Will You Learn from this Book? . . . 7
4.4 Is this Book for You? . . . . . . . . . . . . . . 10
4.5 How is this Book Organized? . . . . . . . . . 11
5. Why API . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Beginners Guide to API . . . . . . . . . . . . . . . . 16
7. Understanding Digitalization and Digital Trans-

formation . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1 What is Digitization? . . . . . . . . . . . . . . 18
7.2 What is Digitalization? . . . . . . . . . . . . . 19
7.3 What is Digital Transformation? . . . . . . . 21
7.4 Summary . . . . . . . . . . . . . . . . . . . . . 22
CONTENTS
8. Two Breeds of API: API Products and API Solu-

tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1 Two Breeds of API and Paradigm of Change 25
8.2 API Solution is the Breed of Operations . . 27
8.3 What is an API Solution? . . . . . . . . . . . 27
8.4 What is the Business Value of API Solutions? 29
8.5 API Product is the Breed of Tactics . . . . . 30
8.6 What is an API Product? . . . . . . . . . . . 31
8.7 What is the Business Value of an API Prod-
uct? . . . . . . . . . . . . . . . . . . . . . . . . 32
8.8 Summary . . . . . . . . . . . . . . . . . . . . . 32
9. Case Studies . . . . . . . . . . . . . . . . . . . . . . . 34
II API Product Design . . . . . . . 35

10. Human-Centered API Design . . . . . . . . . . . . 36
11. Value Proposition Interface Canvas . . . . . . . . 37

11.1 What is the Difference Between Value Propo-
sition and API . . . . . . . . . . . . . . . . . . 40
11.2 Foundations of Value Proposition Interface
Canvas . . . . . . . . . . . . . . . . . . . . . . 42
11.3 Value Proposition Interface Canvas . . . . . 48
11.4 Case Study: Identity . . . . . . . . . . . . . . 56
11.5 Conclusion . . . . . . . . . . . . . . . . . . . . 63
III API Product Strategy . . . . 64

12. Product Vision Board . . . . . . . . . . . . . . . . . 65
13. Product Lifecycle Management . . . . . . . . . . . 66

CONTENTS
14. Ambition Matrix . . . . . . . . . . . . . . . . . . . . . 67
15. Stakeholder Management . . . . . . . . . . . . . . . 68
16. Business models . . . . . . . . . . . . . . . . . . . . . 69
17. Goal-Oriented Roadmap . . . . . . . . . . . . . . . 70
IV API Product Execution . . . 71

18. Lean API Product Development . . . . . . . . . . . 72
V Closing . . . . . . . . . . . . . . . . . . . . . 73
19. Hierarchy of API Design Principle . . . . . . . . . 74
20. API Product Pitch for Everybody . . . . . . . . . . 75
21. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 76
1. Foreword
After passionately driving API programs for years, accelerat-
ing digital programs in Telco, Finance and Automotive indus-
tries, 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 under-
standing of products, services, design or devel-
opment API-first, contracts, assets, resources, and
methods all take on new meanings. Analytics is yet
Foreword 2
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 manda-
tory pre-read for digital practitioners allowing them all to
benefit from your experience and opinions.
Kay Lummitsch - The Digital Journeyman¹ | Zurich

- Switzerland, Eastern 2018
¹https://www.linkedin.com/in/lummitsch/
2. Preface
Coming soon.
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 reac-
tions.
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
Andrea Zulian is a product manager, agile coach, digital
transformation consultant, and entrepreneur. He helps com-
panies and organizations to succeed in their digital journey
applying Lean methodologies and intrapreneurship. As team
leader and senior API product manager for a leading telecom-
munications company in Europe, he developed and applied
the API Product Management methodology launching suc-
cessful products and services.
How to get in touch with Andrea
• LinkedIn: Andrea Zulian¹

¹https://www.linkedin.com/in/andreazulian/
About the Authors 5
• Twitter: @winnitude²
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, contin-
uous 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 launch-
ing 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
• LinkedIn: Amancio Bouza³

• Twitter: @AmancioBouza⁴
²https://twitter.com/winnitude
³https://www.linkedin.com/in/amanciobouza/
⁴https://twitter.com/AmancioBouza
I Setting the Stage
4. Introduction
We live in an age of unprecedented opportunity for inno-
vation. 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 econ-
omy refers to the economy based on digital computing tech-
nologies. 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 Chi-
nese 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, or-
ganizations, 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
Introduction 3
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 man-
agement 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.
Introduction 4
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:
1. Desirability: Find API products that customer wants

2. Viability: Define the product strategy to build a prof-
itable API product
3. Feasibility: Develop the API product
Introduction 5
The intersection of desirability, viability, and feasibility determines the most

valuable design.”
4.2 Why are API Products Hard?

First, there is a misconception about the difficulty of devel-
oping 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.
Introduction 6
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.
Introduction 7
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 applica-
tion 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 as-
sets, 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:
Introduction 8
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, digitaliza-
tion, 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 bench-
mark 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
Introduction 9
• 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
Introduction 10
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 trans-
formation and new digital business models, and to di-
rectly impact the future of their organization and oper-
ative 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
Introduction 11
• 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 intersect-

ing area between desirability, viability, and feasibility. The
following figure presents these criteria for the most valuable
design.
Introduction 12
Most valuable design meet the criteria of desirability, viability, and feasibility.
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.
Introduction 13
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 cus-

tomers’ 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. How-
ever, it makes it straightforward to pivot and iterate from plan
A to a plan that works.
Introduction 14
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 develop-
ment. This involves amongst other things,
Part V: Closing
Being successful is simple if you are working in a perfect en-
vironment 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 recommen-
dations and practical tips.
5. Why API
Interested? Get the full book at
https://leanpub.com/apiproductmanagement
or get more info on http://api-as-a-product.com
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.
Understanding Digitalization and Digital Transformation 18
Pyramid of Digitalisation and API. API enables digitization, API solution

enables digitalization to save costs, and API product enables digital trans-
formation to create new business.
7.1 What is Digitization?

Digitization refers to creating a digital representation of phys-
ical 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 rep-
resentation 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 com-
pany (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 ad-
dress. 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 in-
tegrated 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:
1. The employee is productive and can create value from

day one because he can communicate with customers
and his team.
2. 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.
3. The telco company reduces costs for the order fulfill-
ment 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 man-

ual effort completely.
This is an example of two companies who leverage digital
technologies like API to improve or transform business pro-
cesses.
7.3 What is Digital

Transformation?
Digital transformation is the profound transformation of busi-
ness 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 ver-
ification 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.
7.4 Summary
Digitization refers to creating a digital representation of phys-
ical objects. Digitization itself has no business value. How-
ever, 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 con-
sists typically of efficiency regarding cost reduction, speed,
and simpler business processes.
Digital transformation is the profound transformation of busi-
ness activities, competencies, and business models to fully
leverage the opportunities of digital technologies. The busi-
ness value of digital transformation lies in transforming busi-
ness activities, competencies, and business models to adapt to
changes.
Table: Digital explained.
Term Description Business Value

Digitization creating a digital enabler
representation of
physical objects
Digitalization enabling, efficiency
improving or
transforming
business processes
Table: Digital explained.
Term Description Business Value

Digital transforming new business
transformation business activities, model, adaption
competencies, and
business models
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
Two Breeds of API: API Products and API Solutions 25
and how both relate to business strategy, tactics, and opera-

tions. 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 Breeds 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 com-
ponents:
• 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 or-
ganisation 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.
¹https://de.wikipedia.org/wiki/Peter_Drucker
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.
The Paradigm of Change model in the digital area. API products are the breed
of tactics and driver for digital transformation. API solution are the breed of
operations and driver for digitalisation.
In the following, we’ll use this model to present the two breeds
of APIs, where the prosper and why, and how the provide
business value.
8.2 API Solution is the Breed 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 measur-
ing, 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 Think-
ing.²
Hence, critical thinking is appropriate to solve business pro-

cesses 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
²https://en.wikipedia.org/wiki/Critical_thinking
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 gen-
eral 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:
1. 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.
2. 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 signifi-
cantly manual efforts and thus making processes cheaper and
faster. Automation requires standardisation, which fosters
higher quality.
8.5 API Product is the Breed 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 exe-

cution 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 organ-
isation 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
³https://www.linkedin.com/in/lummitsch/
⁴https://en.wikipedia.org/wiki/Design_thinking
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 prod-
uct 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 prod-
uct. 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.
8.8 Summary
Essentially, there are two different breeds of APIs: API solu-
tions 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 busi-

ness 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.
⁵http://api-as-a-product.com/articles/api-vpi-value-proposition-interface/
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 every-
where. 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,
¹http://api-as-a-product.com/articles/api-vpi-value-proposition-interface/
Value Proposition Interface Canvas 38
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 pro-
viding 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 partic-
ular, 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 enter-
prise integration. It’s the traditional approach when APIs are
driven by the IT department, which is generally a cost cen-
ter. 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 iden-
tifying 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.
Application-driven API design. If your API is designed to expose your applica-

tion, then don’t expect the API to do anything more than that, e.g., be valuable
to a customer.
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.
Value proposition and API explained with Super Mario analogy: Mario
(Prospect Customer) gets Fire Flower (Product) and becomes Fire Mario
(Awesome Customer) who gets the job done
Super Mario, the famous game character, represents an or-

dinary 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 assump-
tions. 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 Empa-
thy Map to get a deep understanding of the customer and Os-
terwalder’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: con-
text, 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 ob-
servable phenomena, we can deduce what a person
thinks and feels. From this, we can conclude his pains
and gains.
²http://api-as-a-product.com/articles/hierarchy-api-design-principles/
³http://gamestorming.com/empathy-mapping/
Empathy Map Canvas (Source: XPLANE)
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, de-
scribe 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 propo-
sition, which you can facilitate with the Value Proposition
Interface Canvas.
The Empathy Map puts much attention on observable phe-
nomenas. However, that is irrelevant to define a value propo-
sition. 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 cus-
tomer’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.
Value Proposition Canvas
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. Sec-
ondly, 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. Analo-
gously, 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 con-
solidates 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 Propo-
sition 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. Gen-
erally, 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.
Value Proposition Interface Canvas
The Value Proposition Interface Canvas is rather about the

flow that connects the Customer Profile with the Value Propo-
sition 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.
Flow of a Value Proposition Interface Canvas for Pains and Pain Relievers
1. Customer Jobs: Describe the jobs the customer needs to

get done.
2. Customer Pains: Be clear about why those jobs are
painful. Validate those pains with the customer.
3. Value Sources: List relevant data sources, apps, business
processes, and other products & services.
4. Pain Relievers: List the features of your API product
that will relieve their pain.
5. Value Proposition Interface: Translate the product fea-
tures to API features. More precisely, describe the API’s
resources and methods.
Step 1 and 2 are straightforward. Likewise, Step 3 is straight-

forward, 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 prod-
uct. 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 differ-
ently 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. Con-
sider 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 de-
scribes 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 pri-
marily 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
⁴http://api-as-a-product.com/articles/hierarchy-api-design-principles/
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.
Flow of a Value Proposition Interface Canvas for Gains and Gain Creators
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.
1. Customer Jobs: Describe the jobs the customer needs to

get done.
2. Customer Gains: Be clear about what can provide gains.
Validate those gains with the customer.
3. Value Sources: List relevant data sources, apps, business
processes, and other products & services.
4. Gain Creators: List the features of your API product
that will create gain.
5. Value Proposition Interface: Translate the product fea-
tures 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. Con-
sider 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 de-
scribes 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.
⁵http://api-as-a-product.com/articles/hierarchy-api-design-principles/
⁶http://api-as-a-product.com/articles/api-vpi-value-proposition-interface/
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 be-
cause verifications interrupt the registration flow. Par-
ticularly 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 applica-

tions 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 con-
tains 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 ver-

ification 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 ad-
dress 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., per-
sonal 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 cus-

tomer’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 veri-

fication 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 repre-
sent 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 conver-

sion rate, consistent user experience, and cost con-
trol by simplifying the registration process, fault
tolerant identity verification, and providing a dash-
board 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.
11.5 Conclusion
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.
1. Build: Create Value Proposition Interface Canvas

2. Measure: Validate your assumption about the customer
3. Learn: Learn from customer feedback and adapt the
Value Proposition Interface Canvas
⁷http://api-as-a-product.com/articles/hierarchy-api-design-principles/
⁸http://api-as-a-product.com/articles/lean-api-product-development/
III API Product
Strategy
12. Product Vision
Board
13. Product Lifecycle
Management
14. Ambition Matrix
15. Stakeholder
Management
16. Business models
17. Goal-Oriented
Roadmap
IV API Product
Execution
18. Lean API Product
Development
V Closing
19. Hierarchy of API
Design Principle
20. API Product Pitch
for Everybody
21. Conclusion

Apiproductmanagement Sample

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apiproductmanagement Sample

Uploaded by

Copyright:

Available Formats

API Product Management

Product Strategy and Execution for

Andrea Zulian and Amancio Bouza

This version was published on 2019-10-31

This is a Leanpub book. Leanpub empowers authors and

© 2017 - 2019 Andrea Zulian and Amancio Bouza

3. About the Authors . . . . . . . . . . . . . . . . . . . 4

I Setting the Stage . . . . . . . . . . . 1

6. Beginners Guide to API . . . . . . . . . . . . . . . . 16

7. Understanding Digitalization and Digital Trans-

8. Two Breeds of API: API Products and API Solu-

II API Product Design . . . . . . . 35

11. Value Proposition Interface Canvas . . . . . . . . 37

III API Product Strategy . . . . 64

13. Product Lifecycle Management . . . . . . . . . . . 66

14. Ambition Matrix . . . . . . . . . . . . . . . . . . . . . 67

15. Stakeholder Management . . . . . . . . . . . . . . . 68

16. Business models . . . . . . . . . . . . . . . . . . . . . 69

17. Goal-Oriented Roadmap . . . . . . . . . . . . . . . 70

IV API Product Execution . . . 71

20. API Product Pitch for Everybody . . . . . . . . . . 75

Your organization is currently trying to leverage

Your organization is trying to do it right but getting it wrong

Management keeps API design within the silos,

another fancy-feature promoted by your gateway

Kay Lummitsch - The Digital Journeyman¹ | Zurich

How to get in touch with Andrea

• LinkedIn: Andrea Zulian¹

Amancio Bouza, PhD

How to get in touch with Amancio

• LinkedIn: Amancio Bouza³

There’s nothing wrong with exposing assets via APIs. It might

and control the usage of APIs within an enterprise. Outside of

“Managing APIs as products increases the chances

In this book, you’ll learn how to leverage APIs to exploit your

4.1 What is API Product

1. Desirability: Find API products that customer wants

The intersection of desirability, viability, and feasibility determines the most

4.2 Why are API Products Hard?

Build API Right vs. Build Right API

You Own the Interface, Not the

4.3 What Will You Learn from this

Part I: Setting the Stage

• Explain to your organization the digital economy, why

Part II: API Product Design

• Find desirable API products applying design thinking

• Retrieve customers’ needs and build a value proposition

Part III: API Product Strategy

• Create, describes, and communicate an API product

Part IV: API Product Execution

• Mitigate risks of building the wrong API product

• How to engage your API developers and inspire them

4.4 Is this Book for You?

• Product managers who want to build API products or

• Engineers who want to understand why they do what

4.5 How is this Book Organized?

• Desirability: Are there customers who are going to buy

The key to a successful API product is finding the intersect-

Our job as product leader is to design the API product such

• API product design addresses the desirability of an API

Part I: Setting the Stage

Part II: API Product Design

“Love the problem, not the solution,” Ash Maurya