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