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.
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.
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.
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.
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.
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.
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