API Product Management http://api-as-a-product.com Helping API Product Managers Create Value! Mon, 19 Feb 2018 06:20:39 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.4 https://i2.wp.com/api-as-a-product.com/wp-content/uploads/2017/10/vpi_logo_114x114.gif?fit=32%2C32 API Product Management http://api-as-a-product.com 32 32 136365052 Value Proposition Interface Canvas http://api-as-a-product.com/articles/value-proposition-interface-canvas-api/ http://api-as-a-product.com/articles/value-proposition-interface-canvas-api/#comments Mon, 27 Nov 2017 11:31:39 +0000 http://api-as-a-product.com/?p=560 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 interface to exploit [...]

The post Value Proposition Interface Canvas appeared first on API Product Management.

]]>
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 interface to exploit your value proposition or an ordinary API. 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 offer 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 practical 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 practical 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 practical for API products and intended for external and internal API consumers who are not domain experts and 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.

Application-Driven API Design.

Application-driven API design. If your API is designed to expose your application, then don’t expect the API to do anything more than that, e.g., be valuable to a customer.

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 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 reason is that an API product isn’t self-contained because it requires to connect to data, apps, products & services, or business processes. Nevertheless, when we treat an API 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 we present in the following figure.

Mario (Prospect Customer) gets Fire Flower (Product) and becomes Fire Mario (Awesome Customer) who gets the job done

Value proposition and API explained with Super Mario analogy.

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 show 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 show 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 safe

These four KPIs show how much value we 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 give 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 help 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 offer first a value proposition to the customer and second 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.
Empathy Map Canvas

Empathy Map Canvas from the Gamestorming Toolkit by 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 phenomena 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 practical value proposition, which you can facilitate with the Value Proposition Interface Canvas.

The Empathy Map puts much attention on observable phenomena. 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.
Value Proposition Canvas

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. 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 shape the value proposition. The interface represents the Value Proposition Interface (VPI), which is an API. The VPI describes the interface to the value proposition and how the customer can use them.
Value Proposition Interface Canvas

Value Proposition Interface Canvas

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 and not 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 show the order in which you have to complete them.

Flow of a Value Proposition Interface Canvas for Pains and Pain Relievers

Flow of a value proposition interface canvas to solve a customer’s problem.

  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 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 and not 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 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 show the order in which they have to be completed.

Flow of a Value Proposition Interface Canvas for Gains and Gain Creators

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 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 and not what gain they create. You can draw a line between the gain creators and the gains to show what gain is facilitated by what gain creators. Sometimes, multiple gains are facilitated by a single gain creator or a gain is facilitated by multiple gain creators.

Step 5 is also straightforward and involves API design. Consider the Hierarchy of API Design Principles as guideline for specifying 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.

Example of How to Use the Value Proposition Interface Canvas to Design an API Product

We briefly presented the API product ‘Identity’, an API product to verify identities, in Paradigm Shift: From API to VPI (Value Proposition Interface). Let’s us it as our example.

Here’s the situation. A company (our customers) wants to onboard users on their Web platform. These users are the end-customers. To this goal, they put a registration process in place to get users’ personal info, verify their phone number, and verify their home address. This is paramount for them because the company wants to build end-customer relationships and sell products via the Web platform to them.

Now, let’s take a look to the corresponding Value Proposition Interface Canvas.

Solve Customer’s Pains

Let’s start with the pain relievers. To this goal, follow the sequence as described in Section “Pain Reliever Flow: Solve Customer’s Pains”. In short, start with the Customer Profile, particularly customer’s jobs and pains. Continue with the Value Proposition Interface Map, particularly products & services, pain relievers, and interface.

Step 1: Define Customer’s Jobs

The customer wants to:

  • onboard the customer
  • get end-customer’s personal info
  • verify customer’s personal info
  • eliminate fake accounts

Step 2: Define Customer’s Pains

The customer has the following pains getting his job done. The pains are:

  • Sending a letter by post to the end-customer’s home is expensive to verify his home address. It costs approx. 6$
  • End-customers drop out of the onboarding process because the various verification 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 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 has 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, which 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, which 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, which is 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 weigh 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 help 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 get access to requested identify verification 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 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 verification.

Step 5: Value Proposition Interface

  • Identity Verification resource, which 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 resources, which represents 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.

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 is 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 practical 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

The post Value Proposition Interface Canvas appeared first on API Product Management.

]]>
http://api-as-a-product.com/articles/value-proposition-interface-canvas-api/feed/ 1 560
API Product Pitch for Everybody http://api-as-a-product.com/articles/api-product-pitch/ http://api-as-a-product.com/articles/api-product-pitch/#comments Sun, 15 Oct 2017 08:43:54 +0000 http://api-as-a-product.com/?p=494 Product vision is one thing, another thing is the execution of developing the API product. Specifically, the quality of the API product and the details that make the difference might rely mostly on engineers' decisions. Furthermore, inspiring your smart engineers with a product vision, a reason or rather a Why, motivates them to perform extraordinarily. [...]

The post API Product Pitch for Everybody appeared first on API Product Management.

]]>
Product vision is one thing, another thing is the execution of developing the API product. Specifically, the quality of the API product and the details that make the difference might rely mostly on engineers’ decisions. Furthermore, inspiring your smart engineers with a product vision, a reason or rather a Why, motivates them to perform extraordinarily. Giving a reason might even transform engineers into customer ambassadors because engineers are not brainless code monkeys. People want (and like) to make an impact. Hence, it is paramount that everybody, especially engineers, understand the value proposition of a particular API product. And there is no better way to achieve that than with an API product pitch.

Daily API Product Pitch

We introduced in our team a daily exercise, which we call: The Daily Pitch. Thus, after each daily SCRUM meeting, engineers have to pitch an API product of their choice in front of the team. This is a great and important exercise because it helps engineers to make the right decisions when doing the API interface design, implementation, and testing. Afterwards, the team provides valuable feedback for improvement.

The team of engineers and product manager soon builds a common understanding of the API product when pitching it. Actually, when a team shares their individual ideas and perspectives, it becomes clear what the customer segments or personas are, what the problems are, and what the value of a particular API product is. In our team, we even realized that one API product is in fact two products because we weren’t able to pitch it as a whole.

As a result, after two weeks of practice, everybody was able do a concise elevator pitch to explain what customer problems it solves and what value it provides. We used a camera to record the API product pitches because you cannot imagine how much more stress it generates. When I had to speak in front of the camera, I was paralysed for two minutes, if not more. A mobile phone’s camera is more than sufficient and fulfils greatly the purpose.

Check out this video, which shows the transformation of engineers into API product pitching beasts.

How to Pitch an API Product?

First, you don’t pitch the API! You rather pitch the value proposition that your API brings. For that reason, it is crucial that you understand your API product as an interface to a value proposition. So, to prepare for your pitch, answer first the following three key questions:

  • Who is the customer?
  • What is the job that the customers has to get done?
  • What value do you propose to help the customer?

Please note that the API is the solution to how you deliver the value proposition. Most importantly, the solution, if at all, comes last. When you’ve answered these three questions, then you are ready for working on your API product pitch.

Example of an (API) Product Pitch

Let me show you a pitch I’ve delivered in whichI proposed “notR: notarized smart contracts for the blockchain”. Next, let’s break it down into its component. Unfortunately, it’s in German or rather Swiss German. However, the pictures and slides express the message well enough.

0:00-0:03 (3s) Branding. Show the brand that they have to remember. Furthermore, this is the perfect time in the pitch to tell your mantra. A mantra is a slogan, consists of very few words, and express your motivation. This is especially important if the audience will see many pitches. Then they need something to remember.

0:04-0:38 (34s) Convince the audience that you can do it. Present yourself, your skills, experience, and passion for the topic. For that reason, I talked about my background, experience, skills, and what I’m currently working on. Especially relevant, limit yourself to what is related to the product.

0:38-0:45 (7s) Claim. Present a claim or use your value proposition or rather your vision. Preferably, use pictures to have it remembered better by the audience.  As a side note: the flames on Judge Dredd’s visor were animated to make it more dramatic because emotions are remembered better than information.

0:48-0:58 (10s) As-Is State. Show the world or situation as it is today. For instance, use customer expectations, how a job gets done, or pain points.

0:58-1:23 (25s) Desired State. Show how the world or situation could be. In other words, present a vision or a desired state a customers wants to be in. More precisely, don’t show Super Mario and the Fire Flower. Show Super Mario who can through fire balls that kill enemies from the distance. I hope you understand what I mean.

1:23-1:43 (20s) Strategy. Present the gap and the strategy to get from the “as-is” state to the “desired” state.

1:43-2:06 (23s) Problem. Show the problems that have to be solved to make the strategy work.

2:06-2:21 (15s) Gap Opening. Create tension by opening a gap. In this case, I showed a problem on the one side and relevant assets and capabilities of the company on the other side.

2:21-2:38 (17s) Gap Closing. Present your value proposition and how it closes the gap. In this case, I claim to use the relevant assets to solve the problem, i.e., I apply existing capabilities to solve a problem. The solution consists of the glue to make the capabilities work in the new problem context.

2:38-3:42 (1m4s) Solution. Now it’s time to talk about the solution and how you deliver the value proposition. Make it as concrete as necessary. For instance, I presented a mock of a user interface to create a notarized smart contract.

3:42-5:51 (2m9s) Present the business model. Show customers how the product works and for what they have to pay how much. In an enterprise context, for example, show the stakeholders why and how the product will create revenue and benefits.

5:51-6:26: (35s) The Asking. Propose the customers how to proceed with a call-to-action. Tell the stakeholders/investors what you want to achieve and what you need from them, particularly in an enterprise context.

6:26-6:30 (4s) Branding. Repeat your product and value proposition. It’s probably the only thing they’ll remember. So, make it count!

Effective Structures for an API Product Pitch

Pitching becomes easy when you understand your product and also can apply a simple structure to tell it. In the following, we present five basic structures for an API product pitch. You can use them for doing a quick daily pitch. Most noteworthy, this is an exercise to understand the value of the API product. Hence, you gain most out of it if you iterate through various pitch structure to tell the same things differently and gain different perspectives.

Goal-Oriented Structure

  1. Claim
  2. Argumentation
    1. Examples
    2. Story
    3. Pictures
  3. Conclusion
    1. Call-To-Action
    2. Asking

Analytical Structure

  1. Analysis (Question/Problem)
    1. As-Is state
    2. Desired state
  2. Strategy

Gap Structure

  1. Side A
  2. Side B
  3. Gab between side A and side B
  4. Solution
  5. Consequences

Medical Structure

  1. Symptom
  2. Diagnosis
  3. Prognosis/Projection
  4. Medication
  5. Therapy

Chain Structure

  1. Initial position
  2. Problem
  3. Solution approach
  4. Results
  5. Consequences

The post API Product Pitch for Everybody appeared first on API Product Management.

]]>
http://api-as-a-product.com/articles/api-product-pitch/feed/ 3 494
Hierarchy of API Design Principle http://api-as-a-product.com/articles/hierarchy-api-design-principles/ http://api-as-a-product.com/articles/hierarchy-api-design-principles/#comments Fri, 13 Oct 2017 06:11:26 +0000 http://api-as-a-product.com/?p=257 The pure implementation of an API is almost straightforward, if not simple. In contrast, API design is not straightforward. Why? Because API design involves many aspects and constraints such as architectural styles (e.g., REST), API governance, backend capabilities, performance, user experience, value proposition, you name it. In other words, there are many constraints and even [...]

The post Hierarchy of API Design Principle appeared first on API Product Management.

]]>
The pure implementation of an API is almost straightforward, if not simple. In contrast, API design is not straightforward. Why? Because API design involves many aspects and constraints such as architectural styles (e.g., REST), API governance, backend capabilities, performance, user experience, value proposition, you name it. In other words, there are many constraints and even trade-offs to take into consideration.

Consequently, in our daily work we typically end up in unsatisfying, endless discussions about what should be right and what wrong, how to interpret the Web standards, what are other API providers doing, etc.

API design is the creation of the best API solution under the constraints of value proposition, user experience and API interface design.

In all our API design discussions, however, we typically miss two fundamental aspects: create value for the customer and provide a good user experience. We realized that no customer cares about a good RESTful API interface. No customer cares about simple developer onboarding, good API documentation or an API playground or sandbox. But customers care about resolving their problems and getting their job done. Afterwards, they care user experience and finally well designed interfaces.

API design is the process of finding the best solution under the constraints of value proposition, user experience and API interface design. For that reason, we invented the Hierarchy of API Design Principles, analogously to Maslov’s hierarchy of needs, which guides our API design from the very basics to the art of API interface design.

The following figure presents the Hierarchy of API Design Principles. The foundation of a valuable API is provide relevant and viable value to the customer. Your job as an API Product Manager is to find and define a relevant value proposition and validate it with the customer.

 

Hierarchy of API Design Principles

Hierarchy of API Design Principles: Value Proposition, User Experience, and API Interface Design

Based on the value proposition, provide a good user experience to the user or rather developer. Provide users frictionless onboarding, useful API documentation and tutorials, sandbox to test and integrate your APIs. And think how your API can best help the user getting the job done. Extend your API management platform to provide a great user experience.

Finally, design the technical API interface under the constraints of value proposition and user experience. Apply you API governance, design guidelines, and your engineer’s wisdom and experience. This is what we call the API interface philosophy.

We are using the Hierarchy of API Design Principles frequently because it helps us to keep the most important aspect in focus: the creation of value for our customers. Remember that your value proposition and user experience are not negotiable. Adapt your API interface philosophy if needed.

Deliver Value to the Customer

Your primary goal is to provide value to the API consumer, help the customer to get his job done! Hence, the value proposition, as part of the API product, is the single non-negotiable aspect. The value proposition sets the context and constraints to define the user experience and to define the API interface.

Our Value Proposition Interface Canvas is a method to make the value proposition explicit and how your customers can exploit it via an API. The Value Proposition Interface Canvas guides you trough the process of identifying customer’s pains & gains getting his job done, making your value proposition explicit by means of pain relievers and gain creators, and how your API provides an interface to exploit your value proposition.

You can find an example in our article “Paradigm Shift: From API to VPI“. In short, in our referenced example we use the value proposition of verifying identities to guide the design of the user experience and of the API interface. As a result, we ended up with the Identity Verification API and the corresponding resources.

One of the most important challenges is to consistently engage your teams to understand why they do what they do. For that reason, we introduced The Daily Pitch. Everybody, engineers in particular, have to pitch an API product to the rest of the internal team. As a result, they understand why they do what they do, are more motivated and passionate, make better decisions independently, and add insights to improve the product.

Provide Good User Experience to the Customer

Good APIs are like love at first sight. Either you love them immediately or you don’t care much. The user experience is how the value can be captured by the API consumer. Good user experience of APIs involves the following aspects:

  • Simplicity (Flexibility-Usability Trade-off): How simple is it for a customer to get the job done? How complex will API usage patterns be?
  • Self-Explanatory: Does the customer easily understand how to use the API to get his job done?
  • Consistency: Is the user experience and the behaviour of the API consistent and is it consistent with other APIs (i.e., API governance)?
  • Forgiveness: Does the API forgive customer errors or ambiguities?
  • Standards: Do we apply useful standards?

Human-Centered API Design

APIs are used in machine-to-machine communication. But this doesn’t mean that we can create a cryptic and complicated design API interface. Because ultimately, a human developer has to understand it and use it.

In the following, we present two  examples of different SMS APIs to send a short text message to a phone. The first one corresponds to the GSMA standard, the second corresponds to the result of human-centered API design. Which one is easy to understand and is less effort to use?

SMS API according to GSMA standard:

{
  {
    "outboundSMSMessageRequest":
    { 
      "address": ["tel:+41435551212"],
      "clientCorrelator": "10002",
      "outboundSMSTextMessage":
      {
        "message": "Test SMS from 7511"
      },
      "senderAddress": "tel:7511",
      "senderName": "Super Send"
    }
  }
}

SMS API based on Human-Centered Design:

{
  "from": "7511",
  "to": "+41435551212",
  "message": "Test SMS from 7511"
}

Both SMS API examples do send a text message to a phone. As you have noticed, the human-centered SMS API, however, is much simpler if compared to the SMS API from the GSMA standard. This latter API is much more complex but might probably allow for multiple receivers (?).

When we design an API, we have to consider the trade-off between usability and flexibility. Specifically, we have to understand the job that customers want to get done. When we know the problem then we can easier determine the sweet spot between usability and flexibility. For that reason, it’s crucial to interact with customers and not just design APIs on a drawing board somewhere in the basement.

The following aspects are especially relevant to provide a good user experience:

  • Good API documentation with tutorials and how-tos.
  • API Sandbox to test APIs and learn their behaviour
  • Error handling with helpful error messages
  • frictionless on-boarding

API Interface Design & Architecture (aka Philosophy)

There are many good readings and books about good API design and API architecture. Especially noteworthy is the book on RESTful API Design from our close colleague Matt Biehl:

  • Matthias Biehl: “RESTful API Design: Best Practices in API Design with REST”

The post Hierarchy of API Design Principle appeared first on API Product Management.

]]>
http://api-as-a-product.com/articles/hierarchy-api-design-principles/feed/ 1 257
Lean API Product Development http://api-as-a-product.com/articles/lean-api-product-development/ http://api-as-a-product.com/articles/lean-api-product-development/#comments Mon, 02 Oct 2017 05:10:44 +0000 http://api-as-a-product.com/?p=178 We derived the Lean API Product Development method from the innovative Lean Startup methodology, which became increasingly popular. The Lean Startup methodology is a revolutionary method that's transforming how companies build new and innovative products or services. Its core principle is the so-called "build-measure-learn" cycle. It is a scientifically proven approach for creating new products [...]

The post Lean API Product Development appeared first on API Product Management.

]]>
We derived the Lean API Product Development method from the innovative Lean Startup methodology, which became increasingly popular. The Lean Startup methodology is a revolutionary method that’s transforming how companies build new and innovative products or services. Its core principle is the so-called “build-measure-learn” cycle. It is a scientifically proven approach for creating new products or services under conditions of uncertainty.

What is the Lean Startup methodology?

The Lean Startup methodology is an iterative process of how to build products, refine or even pivot them depending on the market demand. It consists of three activities: build, measure, learn – and three artefacts: ideas, code, data. The build-measure-learn cycle is presented in the following figure.

Lean Startup Cycle

Lean Startup is based on the build-measure-learn cycle

Everything starts with an idea. We implement or rather build up the idea, which results in a piece of program code or an app. We then make the app productive and accessible to users. Afterwards, we measure the relevant data from the users and how they use the app. Based on the acquired data, we learn and gather insights. This leads to new ideas on how to improve the product. And the cycle of build-measure-learn starts again.

The Lean Startup Methodology is suitable for Application Programming Interfaces (APIs) because of the very nature of the APIs: fast to develop and measurable. However, APIs are technical, contractual interfaces. Let’s imagine that you develop quickly an API and a consumer is using it in an app. You change it frequently breaking interface contracts. As a consequence, the consumer has to frequently adapt his app to the new API. This leads to the consumer spending massive amounts of effort just to maintain the current functionality of his/hers app, which in turn, results in a very bad consumer experience.

The Lean Startup methodology is an iterative, lean process and hence it is ideal to test ideas and to learn from the data. This is particularly interesting when we are uncertain about the customers’ problems and how we can provide value to them.

Overview of the Lean API Product Development

The build-measure-learn cycle promises speed, low costs, and low risk. However, APIs are ultimately technical interfaces or rather contractual agreements. As engineers, we know the rule: Don’t break the interface contract! Imagine that you build an API, customers integrate it, and you change it, frequently! Your customers wouldn’t appreciate it much, to say the least.

But what if we will apply the build-measure-learn cycle a little differently?

The Lean API Product Development method consists of two consecutive build-measure-learn cycles instead of a single one. With such bi-cycle approach, we can first quickly validate our ideas (problem/solution fit) with minimum efforts and without breaking the API’s interface contract. After the validation, we can safely build it and verify how well the validated idea works out (product/market fit).

The first build-measure-learn cycle is to validate the idea until we reach the problem-solution fit. This means we have understood the problem and found a viable solution. For the first cycle, we apply the prototype-first approach.

The second build-measure-learn cycle is to verify the solution until we reach the product-market fit. This means that we built a complete product that is profitable. For this second cycle, we apply analytics.

The following figure presents the Lean API Product Development methodology.

Lean API Product Development

Lean API Product Development

The first cycle is the Prototyping cycle. The second cycle is the Realization cycle. The blue arrow indicates that both cycles are part of a sequential process from initial idea to the final product.

The meta-process of Lean API Product Development is validate-develop-verify.

Prototype-First in the Lean API Product Development

In the Lean API Product Development method, we make use of the prototype-first approach. We already know our customers and early adopters. Nevertheless, we still have just an idea of customers’ real problems and what jobs they have to get done. Thus, in this first cycle, our primary focus is to understand better the problem and find the right solution in terms of an API product. This is also known as the problem-solution fit. To this goal, we apply the core principle of Lean Startup that is “build-measure-learn”.

In the following, we explain the process of finding the problem-solution fit.

Build the API Prototype

As a first step, we need to define the product feature that forms our value proposition. We often refer to the product feature also as the business feature. From this product feature, we will then derive the technical features of the API. As the last step, we design the interface of the API. Having the functional knowledge of the backend applications is crucial for a good API interface design. But don’t try to map the interface to the backend interface yet. Remember that we need to first validate that the API is solving the customer’s problem. Since you are not actually accessing the backend, make sure that the API prototype mocks some realistic data.

The key success factors in API prototyping are speed and low costs. To achieve this, we use a tool to generate a working API prototype from an API specification (e.g., Swagger). With this tool, we don’t have to invest time and effort in building an API prototype, instead we save time and effort.

As a result, you’ll have an API specification, an API prototype for demonstration, and an incipient API documentation to share.

Measure with Customer Feedback Collection

We collect feedback from the customers or rather early adopters for the following two reasons:

  • Problem validation: Do we understand the real customer problem?
  • Solution validation: Did we provide the right solution to solve the problem?

From our experience, it is crucial that we do the customer feedback collection face-to-face with the customer. In the past, this helped us to establish a good and honest relationship with early adopters since face-to-face meetings create a much more open space for communication.

When you meet the customer, make sure that the most relevant people participate in the customer feedback collection. We don’t want to waste our time and theirs with a useless meeting. So, ask the customer to bring to discussions always the same people with following roles and background.

  • Business Owner: He’s crucial to understand the business problem. He can decide upon financial aspects and evaluate the relevancy of certain aspects.
  • Architect: He understands the current solution, the technical dependencies, and the impacts.
  • Engineer: He’ll use the API to integrate it in the app. He’s helpful to check the simplicity of the concepts and API design.

Feedback Collection Process

The feedback collection process is lean as well. It consists of the following steps, per scenario or use case:

  1. Present the scenario or use case.
  2. Demonstrate with the API prototype how to use the API to get the job done.
  3. Ask early adopters to provide structured feedback, via a feedback form.

Structured Feedback Form

Our goal with the structured feedback is to validate: if we understand the problem, if we know the jobs that the customer has to get done, and if our solution actually delivers on these needs. From this goal, we defined the following questions to get the relevant feedback for each scenario:

  • How relevant is this scenario for you?
  • How well has the API solved the problem?
  • Explain why you rated the above question the way you did?
  • Free comments

The following picture presents an example of such a customer feedback form.

Feedback Collection Form

Feedback Collection Form

With the first two questions, we can validate how relevant the specific scenario is and how suitable our proposed solution is. The third question will provide us insight on the customer feedback. Typically, customers want to discuss the scenario rather than to write down the explanation. This is totally fine. Please make sure that you take notes because it’s crucial. Ask a lot of “Why?” questions; they help you understand the motivations and goals of the customers. Otherwise, you’ll implement the infamous ‘Faster Horses’.

“If I had asked people what they wanted, they would have said faster horses. — Henry Ford”

Learn from the Customer Feedback

It’s time to get insights and learn from the feedback from multiple early adopters. It is key to understand that the customer feedback is not the set of requirements. The purpose of the feedback is to help us solve the right problem and to shape the right product.

The customer feedback can help you to prioritize the feature according to their value and effort.

Analytics-First in the Lean API Product Development

In the Lean API Product Development method, we involve the analytics-first approach. The primary goal of this Lean Start-up cycle is now to verify, quantitatively, if and how well the value proposition of the product is delivered to the customer.

Build

We all already know how to implement APIs with the technology or with the API management platform of your choice. Make sure to record or log relevant key metrics when building the API. If you don’t log the right things, you can’t measure them.

Measure with Analytics

This is not about measuring number of requests, rate of successful requests, number of customers. This is about measuring the value that you provide with each call.

We need to derive relevant metrics from the value proposition. The primary goal is to check how well we deliver our proposed value. E.g., let’s refer to the Identity Verification API presented in here. This API proposes to verify the identity to ultimately increase the conversion rate of users. From that, we can derive to key metrics that showcase how well this API product serves the our customer:

  • Rate of successful vs. unsuccessful identity verification requests.
  • Rate of identity verification requests for individuals we don’t know.
  • Estimated conversion rate. Let’s assume that a successful verification request leads to a successful onboarding of a customer.

Often, you need to make assumptions to get quantitative insights. Even though it’s based on assumptions, the metrics give you insights about how well your product works out to provide value. Make comprehensible assumptions and don’t forget that the resulting numbers are to get insights and see relative improvements. They aren’t facts.

Learn

In order to learn, you need to understand the data as well as the metrics you are analyzing. Visualization methods have proven useful to understand data and deliver insights. From our experience, it is straight-forward to visualize the log data, specifically the content.

Make it a habit to publicly (within the organization) publish these metrics and be proud of it. In our case, we built a visual dashboard and displayed it on a screen at the entrance to our office.

Personally, I used the insights from the dashboard to from time to time a small quiz with engineering to engage with the results of their efforts. In this quiz, I ask them for instance how many successful identity verifications we do per week, etc. The team loves it and are more engaged. Furthermore, they can greatly use it for the Daily API pitch.

The post Lean API Product Development appeared first on API Product Management.

]]>
http://api-as-a-product.com/articles/lean-api-product-development/feed/ 2 178
Paradigm Shift: From API to VPI (Value Proposition Interface) http://api-as-a-product.com/articles/api-vpi-value-proposition-interface/ http://api-as-a-product.com/articles/api-vpi-value-proposition-interface/#comments Fri, 29 Sep 2017 05:50:16 +0000 http://api-as-a-product.com/?p=59 How to not make APIs successful? By limiting APIs to expose interfaces to applications. Yes, you heard it right. Let’s forget for one moment what the acronym of API stands for. It’s not about a programming interface of an application, no it’s not. In fact, an API is an interface to a value proposition! Period. If I learned one [...]

The post Paradigm Shift: From API to VPI (Value Proposition Interface) appeared first on API Product Management.

]]>
How to not make APIs successful? By limiting APIs to expose interfaces to applications. Yes, you heard it right. Let’s forget for one moment what the acronym of API stands for. It’s not about a programming interface of an application, no it’s not. In fact, an API is an interface to a value proposition! Period.

If I learned one lesson as technical lead of the API program of Swisscom, the biggest Swiss telco provider, and as lean startup practitioner then it’s this: The API is dead, long live the VPI! VPI stands for Value Proposition Interface.

Ultimately, the API is only about the interface to the value proposition, not to the application.

Let me share a real story. Some of my colleagues developed a technically sound Customers API. You guess right: the Customers API provides information about customers of the Swiss telco provider. It provides full names, addresses, and subscription info. But honestly, how many companies might be interested to know who are the customers of a Swiss telco and why should they care about their mobile subscriptions? To summarize, the Customers API has not much value for other companies.

My team followed a different approach. We didn’t expose the telco’s customer relationship management (CRM) application via API. We applied the lean startup methodology and looked for relevant problems. And we found one: Digital Customer Onboarding. We found that many companies struggle with converting Online visitors to customers.

We discovered one common theme. The registration process for the digital customer’s onboarding included either the verification of IDs, phone numbers, or postal addresses. To this goal, companies asked Online visitors to scan their IDs and upload them. These IDs would then be manually verified, somehow. Or, they sent sent letters containing a secret code, by post, to the people at home. Afterwards, people were asked to enter this secret code again on a Web site to verify their address and complete their registration, days later.

Guess what. Such a registration process is too cumbersome and makes the Online visitor drop out from the registration process before completing it. As a result, Online visitors don’t convert to customers, i.e, the conversion rate is poor.

Instead of a Customers API, we developed an API that simply verifies the customer info taken from the Web registration form by matching it with the customer info we’ve got in the telco databases. In short:

  • Problem: low conversion rate of digital customer on-boarding because of complex and cumbersome registration process.
  • Value proposition: Simple and fast verification of an identity or rather of the personal info.
  • Solution: an API to verify the identity of a person aka Identity Verification API.

Now, think about how much value such an Identity Verification API provides if compared to a Customers API, which provides just info about a telco’s customer base? Please note that both APIs rely on the exact same data set. One API, however, is a great success because it has a value proposition built in.

I realised one thing. Successful APIs in terms of commercial success and reusability have to meet the criteria of a VPI (Value Proposition Interface).

A VPI is an interface to exploit a value proposition.

Having this mindset, you’ll be able to create relevant APIs that are commercially successful, are reused, and provide value.

LinkedIn: API is dead, long live the VPI

The post Paradigm Shift: From API to VPI (Value Proposition Interface) appeared first on API Product Management.

]]>
http://api-as-a-product.com/articles/api-vpi-value-proposition-interface/feed/ 1 59