API Product Management http://api-as-a-product.com Product Strategy and Execution for the Digital Economy Sun, 23 Sep 2018 02:38:07 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.8 https://i2.wp.com/api-as-a-product.com/wp-content/uploads/2018/03/api-product-management_favicon_16x16.png?fit=16%2C16 API Product Management http://api-as-a-product.com 32 32 136365052 API Case Study: Human-Centered API Design http://api-as-a-product.com/articles/case-study-human-centered-api-design/ Fri, 27 Jul 2018 05:46:49 +0000 http://api-as-a-product.com/?p=1697 API Case Study with Human-Centered API Design In this case study, we present the API product Identity, which was our first API product when we applied our API product management methodology. Basically, it is a product that allows organizations to verify the identity and personal info of a person. Our customer data is the basis [...]

The post API Case Study: Human-Centered API Design appeared first on API Product Management.

]]>
API Case Study with Human-Centered API Design

In this case study, we present the API product Identity, which was our first API product when we applied our API product management methodology. Basically, it is a product that allows organizations to verify the identity and personal info of a person. Our customer data is the basis for this API product.

In this case study, you’ll see how we applied the human-centered API design method to draft the API product Identity. This real-life example will help you to understand how to do human-centered API design.

In the following, we’ll present a real customer onboarding process for a Web portal. It was a real onboarding process of one of our clients to whom we ultimately sold Identity. Then, we present how we used the API service blueprint to visualize the customer journey, how we identified pain points, and how we used the API product cards to sketch solution and ultimately the API product Identity.

Customer Onboarding Process

Many organizations seek new ways to interact better with customers, provide better customer experiences and journeys, and save costs. Many do offer or plan to provide online self-service capabilities to their customers. To this goal, many provide a Web portal to onboard customers and to provide services.

Providing a simple and fast onboarding process is key to transform visitors into users, which are eventually transformed into customers.

Nevertheless, some organizations need to perform more verifications of users, specifically in the insurance or financial industries. As a result, the onboarding process becomes more complex and time-consuming.

More complex processes have lower conversion rates. One organization we worked with reported a conversion rate of approx. 10%. We define the conversion rate as the ratio between the number of visitors that were onboard and the number of visitors who started the onboarding process.

So, we conducted a workshop with one organization to understand the onboarding process and its pain points. The following table lists the steps, the user intents, and the corresponding user action of the analyzed onboarding process.

  1. Starts the registration process. To this goal, he clicks on the “Registration” button.
  2. Creates a new user account. To this goal, he clicks on the “New User Account” button.
  3. Provides personal info. To this goal, he enters name, birthdate, e-mail address, and mobile phone number.
  4. Verifies E-Mail address. To this goal, he checks his e-mails for the verification e-mail. He activates the verification link.
  5. Verifies mobile phone number. To this goal, he receives an SMS with a code on his mobile phone. He enters the code into a form.
  6. Provides address info. To this goal, he enters address info in the address form.
  7. Sets nickname and password. To this goal, he writes his personal nickname and password into the form.
  8. Verifies postal address. To this goal, he gets a postal letter with a code. He takes enters the code on the Web site.

Next, we used the API service blueprint method to visualize the customer journey of this onboarding process.

Customer Journey

Based on the previous analysis of the onboarding process, we visualized the customer journey. To this goal, we used the API service blueprint method.

Together with the customer, we mapped the end-customer journey on the API service blueprint. The following figure present the API Service Blueprint of the onboarding process.

API Service Blueprint of API product Identity

API Service Blueprint of a real onboarding process on a Web portal. It consists of several Web sites interactions, Web forms, phone number validation by SMS, and address validation by postal letter.

Next, we went on identifying the pain points.

Pain Point Identification

We marked the pain points on the API service blueprint. As described previously, we used red dots for clear pain points, green dots for steps to further discuss, and blue dots for steps that can be improved. The following figure shows the API service blueprint after we have marked the pain points.

API Service Blueprint with Pain Points

API Service Blueprint of a real onboarding process on a Web portal. The participants marked pain points with red, green, or blue dots.

Eventually, we identified the following three pain points:

  1. Verification of postal address via postal letter. This is a clear pain point. The prospect has to wait for a postal letter with a code that he has to enter on the Web site to complete his onboarding. Typically, sending a letter takes few days. Additionally, each letter costs.
  2. Verification of mobile phone number. This has a potential for improvements. Typically, you can verify the owner of a mobile phone number by sending him a code that he has to provide back. However, the organization already used a service. Fair enough.
  3. Verification of address. This has a potential for improvements. When people enter their address, they may make typos, abbreviate street names or cities, or just forget the zip code because they just moved to another city.

Next, we pulled out our existing API product cards and discussed how these may solve some of the identified pain points.

Problem/Solution Fit

In our portfolio of API product cards, we found three API product cards that relieved some pain points: Customers API, Addresses, API, and SMS Token Validation API. The following list presents these three API product cards in more detail.

  • Customers: It consists of the Customers API that provides info about one of our customers. It provides info about customer based on either a phone number or a customer Id. The info may include basic info (e.g., names, address), product subscriptions, billing, etc.
  • Maps: It includes the Addresses API that provides an interface to retrieve all existing addresses in Switzerland. To this goal, it uses a backend service. A telco company needs to have all existing and future addresses and coordinates to manage building the telco infrastructure to existing and planed addresses.
  • Messaging: Messaging is a bundle of APIs, which includes among other things the SMS API. One feature of the SMS API is token validation. With this API, we you can verify the owner of a mobile phone by sending a token via SMS that the owner has to send back via a Web site.

We added the API product cards to the API service blueprint. We connected the API product cards with the pain points they relieve. The following figures shows the API service blueprint, the API product cards, and which pain points they mitigate.

API Service Blueprint with API product cards.

Service Blueprint of a real onboarding process on a Web portal. API product cards mitigate some pain points. The line between an API product card and a step indicates that API product card mitigates the corresponding pain point.

Providing customer data via Customers API to an organization is problematic. Hence, we brainstormed other solutions.

Ideation

We knew that we cannot provide an organization access to data of our customers due to legal and ethical reasons. So, we did an out-of-the-box brainstorming based on the Opposite Day approach. That means, how do we not want organizations to use a Customers API.

We understood that the organization’s need is to verify the identity of people. And we have a database with data about lots of people. Eventually, we sketched a new API product card called Identity that consists of the idea of an Identify Verification API. The brainstorming helped us to know what we must not provide.

  • Identity Verification: It consists of the Identity Verification API that verifies the identity and personal info of a person. To this goal, it receives some personal info about the user (e.g., name, address, phone number). The API uses some backend services to verify if the provided info corresponds to the info we have in our customer data.

The API product Identity Verification verifies the postal address via letter obsolete. As a result, we could remove this step and simplify the onboarding process. Additionally, a visitor can complete the onboarding in one session and doesn’t have to wait for a postal letter anymore. The following figure presents the final onboarding process with the API product card Identity, which replaces Customers.

Service Blueprint of a real onboarding process on a Web portal. The API product card Identity makes the verification of the postal address via letter obsolete. As a result, the onboarding process is simpler.

With this approach, we don’t provide any organizations access to our customer data. They provide us some info and we provide a confidence score back that indicates the corresponding trustworthiness.

API Product Draft of Identity

Ultimately, we identified three API product cards that can help organizations to simplify their onboarding process, which increases the conversion rate. We bundled these API product cards into one API product and named it Identity.

The API Product Identity consists of three APIs:

  • Identity Verification API to verify the identity of a person.
  • Addresses API to verify that an address even exists, to correct typos, and provide simple search functionality for better user experience. Addresses API is part of the API product Maps.
  • SMS Token Validation API to verify the owner of a mobile phone number. The SMS Token Validation API is part of the API product Messaging.

This is how we developed Identity, which was our first API product based on our API product management methodology.

The post API Case Study: Human-Centered API Design appeared first on API Product Management.

]]>
1697
Human-Centered API Design http://api-as-a-product.com/articles/human-centered-api-design/ Tue, 10 Jul 2018 05:40:14 +0000 http://api-as-a-product.com/?p=1622 Human-Centered API Design Digital transformation is the next big thing after the industrial revolution. And APIs is one of the pillars of this transformation. That's why so many organizations are interested in building APIs and expose their assets. However, building and providing APIs is no guarantee for creating business value, digitalize, or transform. Without the [...]

The post Human-Centered API Design appeared first on API Product Management.

]]>
Human-Centered API Design

Digital transformation is the next big thing after the industrial revolution. And APIs is one of the pillars of this transformation. That’s why so many organizations are interested in building APIs and expose their assets.

However, building and providing APIs is no guarantee for creating business value, digitalize, or transform. Without the Who, Why, and What, it’s rather a guarantee for failure, especially in the API economy. Thus, the key is to answer the following questions, which should be done prior to discussing how to build an API:

  • Who is the customer
  • Why does the customer need it?
  • What is the API or rather value proposition interface (VPI)

Organizations are increasingly investing into innovation to differentiate from or stay ahead from competitors. Innovative organizations focus on users and their needs. And this is what human-centered design is all about: focus on users, their needs, and requirements.

In this chapter, you’ll learn how to answer the Who, Why, and What with human-centered API design. To this goal, we’ll explain the methodology developed by Tobias Blum[^^Blum2016], who developed the human-centered API design workshop with us to find good candidates for innovative API products.

[^^Blum2016]: Tobias Blum: “Innovating the API Economy – Towards a validated human-centered workshop design.”, 2016

In the following, we’ll first describe human-centered API design. Then, we’ll present an API maturity model for organizations that helps you to select the appropriate API design workshop. Subsequently, we’ll present the corresponding workshops that help you discover your organization’s assets, understand customer journeys, and find innovative API products.

What is Human-Centered API Design?

Generally, human-centered design is an approach to interactive systems development that aims to make systems usable and useful. To this goal, this design approach is focusing on the users, their needs, and their requirements.

Highly usable systems and products tend to be more successful both technically and commercially. Especially, systems designed using human-centered methods improve quality, e.g., by:

  • increasing the productivity of users
  • being easier to understand and use
  • improving user experience

Our goal is to make API products useful and usable to make them successful. Hence, human-centered design is an appropriate approach. So, let’s use human-centered design in the context of API products.

  • Human-centered API design: Human-centered API design is an approach that explores the needs, wants and wishes of users and other stakeholders to create API products that are fitting their needs.

Human-centered design is different to user-centered design. Typically, human-centered design is more focused on methodologies and techniques for interacting with people to detect desires and needs, either by verbal or non-verbal means.

In contrast, user-centered design focuses largely on the API user. But API users or rather developers have different needs than API customers. That means that user-centered design focuses more on the user. On the other side, human-centered design is more holistic, which best fits the API stakeholder landscape.

That’s why we apply human-centered API design and not user-centered or developer-centered API design.

Three Stages of API Program Maturity

Different organizations are at different stages in their API journey. Some have no experience with APIs. Others have already experience with developing APIs and integration. And yet others have experience with API use cases.

Here, you’ll learn about the three stages of an organization in their API journey and to classify your organization accordingly. This will help you to select the right API workshop to create successful API products.

In the following, we’ll present the three stages in more details.

Stage I: Beginner

An organization without knowledge of APIs and how they work is in Stage I.

For organisations in Stage I, we suggest to start with the API Workshop I to discover new API use-cases. In fact, it’s about building up knowledge about API, how they work, and what you need to take into consideration.

Stage II: Advanced

An organization enters the Stage II when they run an API program. Some have already some experience with API design and development. Others are just starting.

When you expose more assets it doesn’t necessarily mean to be more successful in terms of commercial success or business value. Hence, you need to discover new use-cases, and understand what jobs customers want to get done and their pain points. To be successful, you need to know your organization’s that are at you disposal. Otherwise, you’ll find creative ideas that are not feasible within your organization.

For organisations in Stage II, we suggest to start with the API Workshop II to discover new API use-cases that build on existing assets of the organisation.

Stage III: Expert

An organization enters the Stage III when they have a running API program. Further, it already has some API products based on available data and service assets.

If you stop innovating, stop extending API products, stop create new API products, then you’ll soon outperformed by your competition. Hence, it is crucial to continue innovating and creating new API products or extending existing API products.

For organizations in Stage III, we suggest to go for the API Workshop III to discover new API use-cases. Repeat this workshop to continue innovating.

API Workshop I: API Fundamentals

Please refer to the Chapter “Beginners Guide to API”. It provides an introduction to the domain of API, stakeholders, and mindset.

API is more than just an interface to an application. It is an interface to a value proposition. Having this in mind, you’ll excel at the subsequent API Workshop II and III.

Further, you learn who are main API stakeholders. This helps you to invite the right people into these workshops.

API Workshop II: Asset Discovery and API Product Ideation

You are familiar with APIs. But you never had the opportunity to think about API products because you had to deliver APIs on request. Or, you don’t have a complete overview of interesting data and service assets in your organization yet. Or, you are just starting with APIs but don’t know where to start exactly. Then, this workshop is for you.

In this workshop, you’ll create new idea for API products based on your organization’s data and service assets. That way, you don’t create ideas that are not feasible to implement.

In the following, we’ll briefly outline the agenda of the API Workshop II. Then, we’ll deep dive into the single sessions, applied methods, and how to use them.

Overview of API Workshop II

The API Workshop is a full-day workshop. The goal of this workshop is to find interesting assets (i.e., data, services) that can used to create API products. The following table hows the agenda of the API Workshop II.

API Workshop II

TimeAgendaObjective
09:30Beginning of WorkshopWelcome and wake up their creativity. Provide overview to participants.
09:45Data FindingFind data assets
10:15
Service FindingFind service assets
10:45Data & Service LandscapingGet overview and understanding of data and service landscape
11:15Break-
11:30
Foresight Thinking IUnderstand what makes API successful
12:15
Lunch Break-
13:15
Foresight Thinking IIUnderstand what makes API successful
13:45
PrioritizationSelect most important assets
14:00API Product DefinitionCreate drafts of API products
15:30
Stakeholder MappingIdentify stakeholders to collaborate with
16:30Outlook & FeedbackCheck participants’ expectations and results. Define next steps and follow ups

The workshop starts with an opening to inspire all participants and to wake up their creativity. Then, they will work towards getting an overview of the organization’s assets, namely data and service assets. Afterwards, they will research existing APIs in your industry to understand what makes a successful API, how they evolved, and what might be needed in future. Based on assets and success factors of APIs, they’ll draft first interesting API products. Finally, participants identify stakeholders of this API products and define a follow-up to involve them.

In the following, we’ll present in more detail how to perform each session.

Session 1: Beginning of Workshop

The beginning of the workshop is key. This is the session where you set the starting mood of the participants.

The goal of this session is to inspire the participants and put them into a creative mood to get more creative ideas.

In the 15 minutes, inspire the participants, e.g., with telling an inspiring story or providing an outlook of the participants’ bright future. Then, provide the participants a quick preview of what will happen today and what the agenda is. Either you’ve collected the participants’ expectations in advance or you do it now.

As a result, you get their involvement. Then, they will be even more motivated to give their best.

In the next three sessions, you will analyze the data and service landscape and get an overview. This is the foundation of creating feasible API products.

Session 2: Data Finding

The goal of this session is to know what are the organization’s data assets. To this goal, we use existing offerings to extract data assets from. Focus on data finding to get more results.

In the 30 minutes, take a complete offering that you brought into the workshop. Then, start extracting the data assets out of it. To this goal, write each data assets to a sticky note.

As a result, you get an overview of what data assets the company owns and how this data assets are connected to the offerings. This are, e.g., address data, or data about their products.

In the next session, you’ll perform the same task analogously for services. In Session 4, you’ll cluster data assets together with service assets to get a better understanding of your organization’s valuable assets.

Session 3: Service Finding

The goal of this session is to know what are the organization’s service assets. To this goal, we use existing offerings, analyze them, and extract service assets from. Focus on service finding to get more results.

In the 30 minutes, take a complete offering that you brought into the workshop. Then, extract the service assets out of it. To this goal, you’ll write each service asset to a sticky note.

As a result, you’ll get an overview of what are the organization’s service assets. This are, e.g., encryption or selling a product.

In the next session, you’ll cluster service assets together with data assets to get a final overview.

Session 4: Data & Service Landscaping

The goal of this session is to get an overview of data and service landscape and how they are connected. To this goal, we use the findings from the previous two sessions, particularly data and service assets.

In the 30 minutes, cluster thematically the data and service assets. The following figure shows data and service assets, which are clustered. The red lines between clusters indicate that they are complementary or similar. It is a good practice to give each cluster a name. That will help in the following discussions.

Data Service Landscape

Data & Service Landscape. Data and service assets are clustered thematically. A line between two clusters means that both are similar or complementary.

As a result, you gain an overview of data and service landscape and how they are connected. This understanding and knowledge is the foundation to create feasible API products.

In the next session, you’ll analyze API from an API ecosystem relevant to your industry. This will help you to anticipate and foresight future API products.

Session 5: Foresight Thinking

The goal of this session is to anticipate the evolution of APIs and functionality that are relevant to your industry. To this goal, we use the Progression Curve method, which is an appropriate method to outline APIs on a timeline and anticipate their evolution.

Progression curves help to understand API patterns in the past and how these have led to the current APIs. The progression curve map has one axis: time. Time refers to publishing date of the API. It is on the horizontal axis. The year of 2005 marks an early year of public APIs. The following figure presents the Progression Curve map.

Progression Curves

Progression Curves.

In the 75 minutes, start with researching APIs that are either relevant to your industry or do similar things in other industries. The ProgrammableWeb[^ProgrammableWebURL] is one resource that might be a good starting point to discover APIs. Write relevant APIs on sticky notes.

Then, map the APIs in chronological order into the progression curve. Add as many curves as necessary.

Afterwards, analyze functionality of the APIs. The goal is to understand the pattern of events for APIs and how these events have led to its current state.

Ultimately, each curve represents how a set of similar APIs and their functionality evolved over time. The following figures shows some APIs that are put in chronological order on the progression curve.

Progression Curve Map

Progression Curve map. APIs evolve over time. Find the patterns how they evolve to anticipate future APIs.

Next, extract API evolution patterns and draw some insights about current state of APIs and future development. This is foresight thinking.

As a result, you get a feeling for successful APIs. Furthermore, you’ll get an overview of APIs relevant to your industry and how they evolved. More importantly, you understand the functionality of competitive APIs.

In the next session, you’ll apply your insights from foresight thinking to select important data and service assets for your API products.

Session 6: Prioritization

The goal of this session is to prioritize what data and service assets are important and what are less important. To this goal, we use the insights from the previous session and prioritize data and service clusters.

In the 15 minutes, prioritize data and service clusters based on your insights from the previous session.

As a result, you get an organized list of clusters where you see what is interesting and relevant today and probably tomorrow.

In the next session, you’ll use the prioritization list draft of API products.

Session 7: API Product Definition

The goal of this session is to define API products based on the results of previous sessions. To this goal, we use the API Product Card method, which presents the functionality of an API product in a very concise form.

One API product card represents one API product. It consists of:

  • Name: crisp name that gives an idea about the API product
  • Functionality: short description about the functionality of the API product
  • Icon: visual icon that gives an idea about the API product functionality

In the 90 minutes, take the prioritization list and go from top to bottom. Try to identify APIs or API products. Try to define the name, functionality, and an appropriate visual icon. You may use brainstorming to create ideas.

As a result, you get a stack of API product cards that you are going to use and validate in the API workshop III. Furthermore, you understand how you can integrate data and services into API products to create value. The following figure shows the API product cards for both API products Identity and Smart Catalogs.

API Product Cards

API Product Cards of Identity and Smart Catalogs.

In the next session, you’ll identify relevant stakeholders and customers for each API product card. This are the stakeholders you are going to involve for the corresponding API products, especially for the API Workshop III.

Session 8: Stakeholder Mapping

The goal of this session is to identify relevant stakeholders for the API products that you defined in the previous session. To this goal, we use the Stakeholder Map method, which is appropriate to list and classify stakeholders.

The stakeholder map has two dimensions: power and interest. Power refers to the stakeholder’s power to support or stop your ideas. Interest refers to the stakeholder’s motivation and his gains when you succeed.

The stakeholder map provides four quadrants based on low/high power and low/high interest:

Stakeholder Groups

GroupDescriptionInteractionExample
Crowdhave low power and low interest informcolleagues
Context Setters
have high power and low interestconsultyour boss, top management
Subjects
have high interest and low power involveaccount manager
Playershave high interest and high powercollaboratecustomer, product manager

The following figure presents the stakeholder map with the four quadrants.

Stakeholder Map

Stakeholder Map. Each quadrant represents a stakeholder group. Each group needs to be taken care of differently.

In the 60 minutes, list all stakeholders and customers for whom the API product might be interesting. Write them on sticky notes and put them into the right place in the stakeholder map. Create A stakeholder map for the top-five API product cards.

As a result, you get a list of potential customers as well as relevant stakeholders you have to interact with. You’ll use the stakeholder map to invite relevant stakeholders to the API Workshop III. Relevant stakeholders for the next workshop are subjects and players. The following figure shows the stakeholder map with some relevant parties.

Stakeholder Map

Stakeholder Map

In the next session, you’ll close the workshop and discuss how to leverage the defined API products and interact with stakeholders.

Session 9: Outlook & Feedback

The goal of the last session is to discuss about how to continue working on the API products and who and how to involve from the stakeholders. Furthermore, review the participants expectations and results and perform a feedback round.

With the discussion, you get time to think about how to continue with the ideas back in your organization. For instance, you might discuss about internal stakeholders, sponsors, synergies, but also how to proceed with the API ideas and how to make them happen.

API Workshop III: Find API Use Cases

You are familiar with APIs. You know the data and service assets that are at your disposal and you know the stakeholders. But you never had the opportunity to think about new API products because you focused on API delivery. Then, this workshop is for you.

In this workshop, you’ll create new idea for API products, evaluate, prototype, and test them.

In the following, we’ll briefly outline the agenda of the API Workshop III. Then, we’ll deep dive into the single sessions, applied methods, and how to use them.

Overview of API Workshop III

The API workshop is a full-day workshop. The goal of this workshop is to understand customers’ journey and pain points, and to generate, develop, and validate ideas for API products. The following table outlines the agenda of the API Workshop III.

API Workshop III

TimeAgendaObjective
09:30
Beginning of WorkshopWelcome and provide overview to participants. Set ground rules of workshop.
09:40Welcome & Intro from Head of PrincipalGet participants' acceptance for the workshop.
09:45
Intro of Companies & ParticipantsParticipants get to know each other.
10:00
Customer JourneyUnderstand customer's job to get done.
10:45
Break-
11:00
Pain Point IdentificationIdentify biggest pains and gains to tackle.
11:30
Additional Problems & NeedsDiscover radical innovations.
12:00
Lunch-
13:00
Problem/Solution FitIdentify what pain points can be solved with API product ideas.
14:00
IdeationInspire ideas for new API products.
14:30
PrioritizationSelect best ideas.
15:00
Break-
15:15
PrototypingCreate API prototypes that relieve pains or create gains.
16:00
PresentationCreate hype. Enforce quality of prototype.
16:15Wrap Up & Next StepsCheck participants' expectations and results. Define next steps and follow ups.

The workshop starts with an opening to get their commitment and to present participants and invited companies. Then, participants will draw the customer journey of a company and analyze pain points, problems, and needs. Afterwards, they will map their API product cards to relieve pain points and improve the customer journey. Based and untackled pain points and needs, they will brainstorm new innovative API products. Afterwards, they will select an API product card to build a prototype. Then, they will present it to show how it will create value to the customer. Finally, participants will define next steps to continue with their ideas.

In the following, we’ll present in more detail how to perform each session.

Session 1: Beginning of Workshop

The beginning of the workshop is key because it sets the mood and mental state of participants for this workshop. Hence, the goal of this session is to inspire participants and put them into a creative mood to get more creative ideas. To this goal, we use story telling, which is an approach to get people emotionally hooked.

In the ten minutes, tell a resonating and inspiring story and preview the positive future of participants and your organization. Then, provide the participants a quick preview of what will happen today and present the agenda.

Afterwards, set the ground rules for the workshop. To this goal, we use the nine rules for collaboration from Uebernickel[^^Uebernickel2015]. The following table shows the rules to foster successful collaboration.

[^^Uebernickel2015]: Uebernickel, F., Brenner, W., Pukall, B., Naef, T., & Schindlholzer, B. (2015). Design Thinking: Das Handbuch (Erste Auflage). Frankfurt am Main: Frankfurter Allgemeine Buch.

Nine Rules of Collaboration

No.RuleDescription
1.
Be visualDraw instead of write.
2.
Encourage wild ideasEverything sounds impossible until it's done.
3.
One conversation at a timeListen to others, get inspired, and collaborate.
4.Think user-centric Provide value for the user first. The rest will follow.
5.Build on the ideas of othersCombine your ideas with ideas of others.
6.
Stay focusedAlways remind the purpose of this workshop.
7.
Go for quantityDon't be perfect. Exhibit bias-to-action.
8.Defer judgmentDon't kill creativity and wild ideas.
9.Have fun"Creativity is intelligence having fun", Albert Einstein.

Finally, get their involvement by collecting their expectations now. If you did it in advance already, then quickly present them. Then, they will be even more motivated to give their best. Collect the expectations of the participants, e.g., on a flip chart. In the last session, come back to this expectations and review them with the participants and achieved results.

As a result, participants are in an inspired and creative mood.

In the next session, the Head of Principal will eliminate remaining doubts of participants and show the importance of this workshop and journey for the organization.

Session 2: Welcome & Intro from Head of Principal

The goal of this session is to get the participants’ acceptance for the workshop. To this goal, we show the support from a senior or rather Head of Principal.

In the five minutes, the Head of Principal presents what is at stake and why APIs are crucial for the organization’s success and future.

As a result, all participants will accept the workshop, motivated, and open to collaborate.

In the next session, all participants will get to know each other. This will facilitate exchange and collaboration among them.

Session 3: Intro of Companies & Participants

The goal of this session is to get all participants know each other and to facilitate collaboration and exchange. Further, all participants get to know the companies who take part in the workshop as well. To this goal, companies will pitch their company and participants will quickly introduce themselves to the others.

In the 15 minutes, each company representative will pitch the company in two minutes. This may include the company’s vision, approach, products, and customers. Afterwards, every participant introduces himself in one or two sentences.

As a result, all participants know each other. This facilitate exchange and first networking.

In the next session, participants will analyze the journey of the attending companies, which are prospect customers.

Session 4: Customer Journey

The goal of the customer journey is to build customer empathy and understand the journey of a customer. The customer is either the invited company or the company’s customer in the business-to-business case (B2B) or business-to-business-to-customer (B2B2C) case, respectively. To this goal, we use the API Service Blueprint method, which represents a service oriented customer journey.

The API Service Blueprint illustrates a process in which APIs can facilitate or simplify some parts. The API Service Blueprint consists of five layers: physical evidence, user action, front stage, back stage, and API stage. The following table describes this layers and provides some examples.

API Service Blueprint with five layers.

LayerDescriptionExample
Physical Evidence
Elements that influence customers' perception. Product info, ads, graphical design.
User Action
Steps that user takes to get a job done.Registering on a Web site, searching.
Front StageInterfaces the user interacts with.Registration form, Web page, cart.
Back StageServices and process that are used.Product search, check out.
API StageAPIs that can be applied.Payment API

The API Service Blueprint has two dimensions: technical depth and timeline. Technical depth is vertical and represents the technical depth. The lower a step, the more technical it is. Timeline is horizontal and represents the customer journey. The customer journey starts typically at the top left and ends at the top right. The following figure shows the API Service Blueprint.

API Service Blueprint

API Service Blueprint.

In the next 45 minutes, collaborate with the company representative to create a customer journey. To this goal, think about a specific customer journey.

Then, collect all steps and map them on a timeline. Finally, classify each step to one of the five layers (e.g., user action). The following figure shows the API Service Blueprint with the steps of a specific the customer journey.

API Service Blueprint

API Service Blueprint. The yellow sticky notes indicate steps of the customer journey.

As a result, you have outlined a customer journey from the customer’s perspective and mapped all relevant interactions and backend processes.

In the next session, you’ll identify the pain points in the customer journey. Identifying and addressing pain points is essential to create a desirable solution.

Session 5: Pain Point Identification

The goal of this session is to identify pain points of the customer journey from the previous session. To this goal, we vote individually for the biggest pains.

In the 30 minutes, put your votes on the steps. You can use coloured markers or coloured sticky dots. The code of the colors are as follows:

  • Red dot: Marks a step as clear paint point
  • Green dot: Marks a step as up to discussion
  • Blue dot: Marks a step as optional opportunity, i.e., it can be improved or provides a gain.

With the placed votes or rather coloured dots, you can quickly see where the most pain points are and of what type. Let’s use them as the innovation triggers to improve them.

Understanding the customer’s pain points is key to create a desirable API product. The following figure shows the API Service Blueprint after you voted for the biggest pain points.

API Service Blueprint with Pain Points

API Service Blueprint. People voted with colored sticky dots what steps are the biggest pain points. Red dots indicate clear pain points, green dots indicate up to discussion, and blue dots indicate potential gains.

As a result, you have identified what steps of the customer journey are the biggest pain points. This steps might be replaced or improved with an API.

In the next session, you’ll discuss additional problems and needs that are not reflected in the customer journey. These problems and needs can lead to radical innovations.

Session 6: Additional Problems & Needs

The goal of this session is to find really new API products based on identified needs from the pain points. To this goal, we list pain paints and associate each with a real need.

The following table shows a simple template to list pain points and needs. It contains three examples of pains and associated need. You may use a flip chart.

Problems and Needs

No.Problem / Pain PointNeed
1.
Short sessions because of limited battery lifeStay in touch over longer period.
2.
Missing product reviewsMake a good purchase decision.
3.Huge product catalogFind the right product.

In the 30 minutes, list all pain points from the customer journey. Then, clarify the needs that are associated with each pain point and put them on the list. Finally, extend the list with other pain points and needs that are not visible on the customer journey.

Replacing one part of a customer journey with a better one is good. But finding a total different and better solution for a problem is just better. Replacing one part with a better one is what we refer to as incremental innovation. Finding totally different and better solutions for a customer journey is what we refer to as radical innovation.

The list of needs can inspire you to find totally different and better solutions for a problem.

As a result, you get a list of pain points that are associated to needs. In the best case, you identified new API products for which you can sketch additional API product cards.

In the next session, you’ll use your API product cards to improve the customer journey.

Session 7: Problem/Solution Fit

The goal of this session is to find problems that can be solved with APIs. To this goal, we use the API product cards that you previously developed before this workshop.

An API product card consists of a short and descriptive name, a visual icon that represents the functionality or value proposition, and a short description of the functionality.

In the 60 minutes, go through your stack of API product cards and try to find what pain points on the customer journey it can solve. Put the API product cards in the API stage layer below the steps that it improves or replaces.

The API product card should at least partially solve a pain point. The following figure shows the customer journey, steps (yellow sticky notes), and some parts replaced with API products (blue cards).

API Service Blueprint with API Product Cards

API products cards that improve some parts of the customer journey are placed on the Service Blueprint.

As a result, you get an improved customer journey with less pain points (incremental innovation). Possibly, you might even found a complete different solutions that completely changes the customer journey (radical innovation).

Now, you’ve got a lead! You showed a prospect customer (i.e., company representative) how you can relieve his pains points. The worst case is that you learned who is not your customer. Please remind the following:

“The only real mistake is the one from which we learn nothing.”, Henry Ford

In the next session, you use the untackled needs and problems to ideate new API products and new uses cases. In case that the company representative is not yet convinced to buy your API products, this is your second chance to make him an early adopter or validate new ideas.

Session 8: Ideation

The goal of this session is to develop new API ideas. To this goal, we use Out-of-the-Box Brainstorming method, which is an approach to brainstorm complete new ideas.

Out-of-the-box brainstorming puts you outside of your usual context and thinking patterns. We made good experiences with three approaches: Scrabble Bag It, Pocket Dictionary, and Opposite Day.

  • Scrabble Bag It: Mostly everyone has an old Scrabble game that probably isn’t used since ages. Let’s repurpose those little letter tiles for brainstorming. To this goal, every participant grabs a handful of letter tiles. Each tile stands for the first letter of a word that might represent your new industry-defining idea. Be creative! The participants share and discuss them.
  • Pocket Dictionary: Often, we are just blocked in our thinking. One solution to this is to associate our problem with something completely different to get a different perspective on it. So, pick a random word from a pocket dictionary. And stick to this word! Associate your problem with the word and start the brainstorming.
  • Opposite Day: Sometimes, the best way to find the right answer to a problem is to think about how not to solve a problem. You want to get your customer to use a new product. So, think about all the ways the customer shouldn’t use the product. When you take another perspective, it opens up a new realm of thinking about a product.

“If you can’t solve a problem, then you need to change the perspective.”, Vinh Giang

As a result, you collect many ideas about new and relevant API products. The ideas are relevant because they are associated with the needs you retrieved from a real customer journey.

In the next session, you’ll evaluate and select the best API ideas to ultimately build a first prototype.

Session 9: Prioritization

The goal of this session is to evaluate the APIs of the previous session and to select the one that you want to work on in the course of the workshop. To this goal, we use the API Valuation Matrix method to create an overview of the best ideas.

The API valuation matrix has two axes: potential and viability. Potential refers to the value that the API brings to the team, organization, or customers. It is mapped on the horizontal axis. Viability refers to how realistic it is to build an API or provide a solution to an industry based on the available resources, experience, and reputation. It is mapped on the vertical axis. The following figure presents the API valuation matrix.

API Valuation Matrix

API Valuation Matrix. It consists of two axes: potential and viability.

In the first 25 minutes, place the API product cards from previous workshops and the ones creates in the Ideation session on the matrix. The position of the card reflects its potential and viability. The higher you place an idea the more viable it is. Analogously, the more right you place an idea the more potential it has in the market.

The best ideas are at the top right. Go for it! These ideas are viable and have potential.

The least interesting ideas are at the bottom left. Leave them. These ideas aren’t viable nor have potential.

The ideas at the top left are viable. Nevertheless, they don’t provide value or have a great potential. Hence, these ideas are just a waste of time at this moment. There might be a potential in the future. So, don’t forget about them entirely and reconsider their potential from time to time.

The ideas at the bottom right have great potential because they provide a high value. However, you are not yet in the position to develop them. In this case, try to identify why not and change the situation in the future. Then, this ideas may become your next innovation.

The following figure shows the API valuation matrix with evaluated API product cards.

API Valuation Matrix

API Valuation Matrix. Mapped ideas according to their potential and viability. API product cards at the top right are the best ones.

In the last five minutes, vote on the most interesting ideas you want to work on in the course of this workshop. Typically, people select ideas at the top-right or bottom-right.

In the next session, you’ll take the idea with the most votes and develop a first prototype. Afterwards, you’ll present it.

Session 10: Rapid Prototyping

The goal of this session is to prototype the selected idea from the previous session and test it. To this goal, we use the Rapid Prototyping method.

In the 45 minutes, take the solution from the previous session and build a prototype. You can build the prototype out of anything (e.g, paper, pipe cleaner). Ultimately, the prototype should reflect how the interaction with the customer changes when using the prototyped idea.

As a result, you’ll get a testable prototype, a clear vision about the API’s task, and a story that explains the APIs impact.

In the next session, you’ll present the prototype to get an early validation of your idea and feedback to further improve it.

Session 11: Presentation

The goal of this session is to present all prototypes and tell their story. To this goal, we use Story Telling and Elevator Pitch. Sharing with others might improve the result. Further, you’ll get a first validation and feedback how to improve it.

In the 15 minutes, pitch the idea to the others. You can show how the customer journey was and what changes with your idea. Get feedback from the others.

As a result, you’ve got a first validation and feedback to improve the ideas. Furthermore, the presentation is like a closing point that crisply summarizes the result and success of this workshop.

In the next session, you’ll wrap up the workshop and define next step to continue with the API ideas.

Session 12: Wrap up & Next Steps

The goal of the last session is to discuss about how to continue working on the ideas. Furthermore, review the participants expectations and results and perform a feedback round to learn.

With the discussion, you get time to think about how to continue with the ideas back in your organization. For instance, you might discuss internal stakeholders you need to talk to, sponsors, synergies, but also how to proceed with the API idea and how to make it happen.

Define together next steps and when you are going to review them and proceed.

Summary

Organizations are increasingly investing into innovation to differentiate from competitors. Innovative organizations focus on users and their needs. And this is what human-centered design is all about: focus on users, their needs, and requirements.

Our goal is to make API products useful and usable to make them successful. Hence, human-centered API design is an appropriate approach. We define human-centered API design as follows:

Human-centered API design: Human-centered API design is an approach that explores the needs, wants and wishes of users and other stakeholders to create API products that are fitting their needs.

API Program Maturity

We describe the maturity of an organization with respect to APIs with three stages: beginner, advanced, and expert. The following table describes the three stages in more details.

Three stages of an organization's API product maturity.

StageDescription
I (Beginner)
An organization without knowledge of APIs and how they work is in Stage I.
II (Advanced)
An organization enters the Stage II when they run an API program. Some have already quite some experience with API design and development. Others are just starting.
III (Expert)An organization enters the Stage III when they have a running API program. Further, it already created API products based on available data and service assets.

API Workshops

For each maturity level of an organization, there is an API Workshop with appropriate goals. This helps to progress in the maturity and reach the next stage. The following table shows the API workshop, its goal, and for what stage it is.

Overview of API workshops for every maturity level.

WorkshopStageObjective
API Workshop I
BeginnerGain API knowledge.
API Workshop II
AdvancedDiscover assets, API product ideas, and stakeholders.
API Workshop IIIExpertProblem/Solution Fit and validation of API product ideas

API Workshop I

The goal of this workshop is to get the basic knowledge about API to define viable API products with high potential.

Please refer to the chapter “Beginners Guide to API”.

As a result, you understand APIs. Now, you’re ready to ideate API products.

API Workshop II

The goal of this workshop is to get an overview of the organization’s data and service asset and understand what makes a successful API. You’ll ideate API products based on this assets.

The workshop starts with an opening to inspire all participants and to wake up their creativity.

Then, they will work towards getting an overview of the organization’s assets, namely data and service assets. Afterwards, they will research existing APIs in your industry to understand what makes a successful API, how they evolved, and what might be needed in future. Based on assets and success factors of APIs, they’ll draft first interesting API products.

Finally, participants identify stakeholders of this API products and define a follow-up to involve them.

As a result from this workshop, participants learn what makes a successful API. Further, they drafted first API products

API Workshop III

The goal of this workshop is to understand a customer’s journey as well as to ideate and validate API product ideas.

The workshop starts with an opening to get their commitment and to present participants and invited companies.

Then, participants will draw the customer journey of a company and analyze pain points, problems, and needs. Afterwards, they will map their API product cards to relieve pain points and improve the customer journey. Based on untackled pain points and needs, they will brainstorm new innovative API products.

Afterwards, they will select an API product card to build a prototype. Then, they’ll present it to show how it will create value to the customer.

Finally, participants will define next steps to continue with their ideas.

As a result, you validated and ideated API products based on a real customer journey.

The post Human-Centered API Design appeared first on API Product Management.

]]>
1622
Beginners Guide to API http://api-as-a-product.com/articles/beginner-guide-api/ Tue, 29 May 2018 19:26:38 +0000 http://api-as-a-product.com/?p=1544 Beginners Guide to API The term API and its concepts are nothing new. There are many categories of APIs: APIs from software libraries and frameworks, APIs from operating systems, remote APIs, and Web APIs. When we talk about APIs, we talk about the latter, i.e., Web APIs. Exposing an organization's assets and digital products became [...]

The post Beginners Guide to API appeared first on API Product Management.

]]>
Beginners Guide to API

The term API and its concepts are nothing new. There are many categories of APIs: APIs from software libraries and frameworks, APIs from operating systems, remote APIs, and Web APIs. When we talk about APIs, we talk about the latter, i.e., Web APIs.

Exposing an organization’s assets and digital products became straightforward with the advent of API management platforms. And this was the trigger for many organization to start exposing their assets via APIs. In many cases, however, this inside-out approach didn’t met people’s expectation. Between you and me: this was exactly how we started.

The terminology of API spans a range of technical, organisational, and economical topics. And often, people mix terms, used them interchangeably, and abbreviate when ever possible.

In this chapter, we explain all terms relevant to understand the world of APIs.

In the following, we’ll clarify what APIs are and what perspective on APIs leads to successful APIs in terms of business value and success. Furthermore, we’ll explain what an API management platform is and how to use it. Finally, we’ll discuss the main stakeholders.

What is an API?

Typically, we all use software applications via a user interface. Just imagine all the apps on your smart phone and how you click on the display to interact with these apps.

Similarly, software applications can interact and use other software applications. In contrast to a user interface, they do it via a machine interface, which we call API. In other words, an API is a set of functions that allows creating applications that access the features or data of another application or service.

API is the acronym for Application Programming Interface, which is a software intermediary that allows two applications to talk to each other. For instance, each time you use an app like Facebook, send an instant message, or check the weather on your smart phone, you’re using an API.

APIs are the user interface for applications to interact with and use other applications.

Just as a graphical user interface on a smart phone makes it easier for people to interact with apps, so APIs make it easier for developers to use technologies, applications, or backend systems. Generally, an API simplifies programming by abstracting the underlying implementation.

An app that combines multiple APIs is known as mashup.

The following figure represents the interaction between various entities. In the following, we explain the entities that are relevant in the context of API.

API Proxy

The API client send a request to the API proxy, which processes it and sends it to the backend system. The API proxy waits for the backend system’s response, processes it and returns a response back to the API client.

API Client

The API client is the application of the API customer that uses the API. It sends requests to the API and receives responses back.

Generally, the API client serves an end-users. The usage of the API clients creates business value for the API customer. For example, an end-user wants to register on a Web site (API client) and enters among other things his e-mail address. The Web site uses an API to verify the end-users e-mail address. To this goal, a verification e-mail is sent to the end-user.

The API consumer controls the API client. That means the API consumer controls when and how to use the API. The API provider, however, may provide a software development kit (SDK) to facilitate the API client’s interaction with the API and get more control about how the API client uses the API.

Backend System

The backend system represents the asset of the organization. It can be a database, a software application, or a service.

API Proxy

The API proxy implements the API. More specifically, it is the piece of software running on an API runtime platform that receives requests from an API client, interacts with backend systems, and sends responses back to the API client.

The API proxy decouples the API from the backend systems. Hence, it can be updated or replaced with another API proxy without API clients noticing it. Typically, the API proxy adds security to protect the backend system and data owners. To this goal, it authenticates API client and checks if it is authorized. Further, it may limit interactions with the backend systems to protect them from overloading.

The API proxy is a software artefact. It can be deployed on an API runtime platform. Typically, multiple API proxies together implement one API.

The API provider builds, deploys, and operates API proxy.

API Feature

The API feature describes one possible interaction with the API. Generally, multiple API features constitute an API.

The documentation of an API contains primarily the documentation of its containing API features.

An API proxy implements one or more API features.

Typically, an API product manager defines the API feature. To this goal, the API product managers may collaborate with an API specialist who can translate the API feature into a sound API design.

API

The API consists of multiple API features, typically from one domain. Typically, an organization’s asset or rather backend system (e.g., customers) defines the domain.

The API defines how an API client can interact with it and what the API client can expect from it in terms of responses and changes in the backend systems (e.g., creating and persisting objects). Ultimately, the API is a technical contract how API clients can interact with backend system. However, the term API is often used instead of API product or API proxy.

The API has a marketing name. Typically, the solution (e.g., Identity API), value proposition (Identity Verification API), data (e.g., Customer API) or the backend system (e.g., Customer Relationship Management API) provides the name.

The API provider defines and specifies the API. Nevertheless, the API consumer might be taken into consideration to evolve the API. This refers to the API evolution pattern of consumer-driven contracts.

Anatomy of an API

After having developed more than 100 APIs, we thought it’s time to analyze our APIs for some common patterns to formulate an API benchmark. This can be used for effort estimation, quality control, and API governance.

I> coming soon!

What is a Digital Product?

An API product is more than just a technical API. The following figure shows that an API product consists of APIs and API features. The left side shows the business perspective of APIs. A digital product refers to an API product. Business feature, are feature that describe how a business value is created. They refer to API features.

API terminology: API product, API, API feature, API proxy, digital product, business feature.

The API perspective shows the API terminology. An API product consists of APIs and API features. An API consists of API features. An API proxy implements some API features.
The business perspective shows the business terminology.

In the following, we explain the terminology of the API and business perspective and how they relate to each other.

API Product

Technically, an API product is a bundle of multiple API features and APIs and a revenue model.

The API product provides the required set of APIs and API feature to solve a common problem. API customers buy for the usage of an API product. Hence, the API product has a price plan attached.

The API product manager defines the API product and the revenue model.

Business Feature

Customers have jobs they need to get done. Customer problems are the pains customer have to get their jobs done. The business feature is a pain reliever that relieves one or more customer pains. For example, a business feature can

The set of business features that help a customer to get his job done is the value proposition.

Digital Product

A digital product consists of multiple business features and has a value proposition.

In fact, an API product is a digital product. The digital product is solution technology agnostic, however. Today, it’s APIs. Tomorrow, it might be something another technology. For that reason, we refer to API products often as digital products.

Minimum Viable API Product

A minimum viable product (MVP) is a product with just enough features to satisfy early customers. In fact, An MVP is a minimum desirable, feasible, and viable product. An MVP is very useful to get early customers and test it on the market. The following figure explains how to build an MVP.

Minimum Viable Product

A minimum viable product (MVP) provides enough features that it provides a value to an early customer.

The concept of MVP applies to APIs too. As depicted in the following figure, an MVP consists at least of an API product, an API, an API feature, and an API proxy.

MVP of API product

An API-based minimal viable product (MVP) needs to consists of at least an API proxy, an API feature, an API, and an API product.

Paradigm Shift: From API to VPI

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.

From Inside-Out to Outside-In

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

Birth of an API product

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  data set. One API, however, is a great success because it has a value proposition built-in.

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

What is an API Management Platform?

Typically, an API management platform consists of three platform components: API development platform, API runtime platform, API engagement platform.

API Development Platform

The API development platform enables API providers to develop APIs quickly and with high quality. To this goal, it offers a toolbox with common API building blocks (e.g., data transformation, authentication, logging, value extraction) that are proven, reusable, and configurable.

API Runtime Platform

The API runtime platform enables the execution of the APIs. It enables the API to receive requests from apps or Web sites and send responses back. Most commonly, the API platform is an HTTP server, which allows exposing services via HTTP. HTTP is the common protocol for REST APIs.

The user experience depends on the availability, throughput, stability, and security of APIs and the API runtime. For this reason, the API runtime platform provides capabilities for caching, load balancing, and connection pooling. Further, it provides capabilities for monitoring, logging, and analytics that helps operators to measure and ensure this non-functional properties.

Further, the API runtime platform provides API providers capabilities to smoothly deploy new APIs or maintenance of existing ones.

API Engagement Platform

The API engagement platform enables the interaction between API provider and API customer and consumer. The API engagement platform provides capabilities for customer and consumer onboarding, API product catalog and corresponding API documentation and instructions.

Interactions Between the Platforms

The three components of an API management platform (i.e., API developer platform, API runtime platform, and API engagement platform) are used together.

API consumer develop an API on the API development platform. Then, they deploy and run it on the API runtime platform. Then, they publish the API and the documentation in the API engagement platform.

API consumer develop an API on the API development platform. Then, they deploy and run it on the API runtime platform. Then, they publish the API and the documentation in the API engagement platform.

API consumer develop an API on the API development platform. To this goal, they use the provided building blocks to build APIs.  Then, they deploy and run it on the API runtime platform. Typically, organizations will have multiple environments for developing, testing, integrating, and releasing in production. Lastly, the API is added to the API catalog and the API documentation is published on the API engagement platform.

Who are the API Stakeholders?

There are four main groups of stakeholders: API providers, API customers, API consumers, and end-users. API providers build, expose, and operate APIs. API customers decide what API to buy or rather the usage of the API. API consumers develop apps that use APIs. End-users don’t use directly APIs. Instead, they use APIs indirectly via the app that is developed by the API consumer and provided by the API customer.

The following figure shows the four main groups and how they interact.

Stakeholders of APIs: API provider, API customer, API consumer, end-user

Stakeholders of APIs: API provider, API customer, API consumer, end-user

In the following, we describe each group, their competencies, as well as heir interests.

API Provider

API providers build, expose, and operate APIs. In other words, API providers are the ones that provide APIs to others.

API providers need to know how to design, build, and operate APIs.

Typically, API providers use an API management platform to build, expose, and operate APIs. Further, they provide a developer portal to engage with API customers and API consumers.

API Customer

API customers are the ones who decide what APIs to use, especially commercial APIs.

Generally, API customers have a problem or rather job they want getting done. More precisely, API customers look for solutions to their problems. Since they don’t have the resources, the time, or the right data, they choose APIs from API providers. Using APIs can boost time-to-market enormously.

To find the right APIs, API customers are looking for the API with the right value proposition. For that reasons, it is paramount for the API provider to present their APIs as interface to a value proposition and present their unique value proposition (USP).

API Consumer

API consumers develop software applications or Web sites that use APIs. Typically, they are the developers who integrate APIs in their apps or Web sites. In other words, API consumers are the users of APIs. Often, they are mistaken as the customers. They aren’t.

API consumers are probably the most important stakeholders for API providers because they interact the most with the APIs and the developer portal.

API consumers look for simple APIs, good documentation, and instructions how to use the APIs. They are the main users of the developer portal. On the developer portal, they look API credentials to use the API, API documentation, SDKs, and an API sandbox.

End-Users

End-users don’t use APIs directly. Instead, they use apps or Web sites that use APIs in the background.

Nevertheless, the availability, performance, and security of your APIs have a direct impact on the user experience of end-users. A bad end-user experience leads to unsatisfied API customers and API consumers. As a result, they might look for alternatives to your API.

Summary

The API management platform consists of three platforms:

  • API development platform: enables API providers to develop APIs quickly and with high quality
  • API runtime platform: enables the execution of the APIs. It enables the API to receive requests from apps or Web sites and send responses back.
  • API engagement platform: enables the interaction between API provider and API customer and consumer. It provides a catalog of APIs with documentation and instructions.

The stakeholders consists of four main groups:

  • API providers: build, expose, and operate APIs
  • API customers: decide what API to use and pay the usage of the API
  • API consumers: develop apps that use APIs
  • End-users: don’t use APIs directly. Instead, they use apps that make use of APIs.

The post Beginners Guide to API appeared first on API Product Management.

]]>
1544
Introduction http://api-as-a-product.com/articles/introduction/ http://api-as-a-product.com/articles/introduction/#respond Sat, 19 May 2018 07:39:41 +0000 http://api-as-a-product.com/?p=1459 Introduction We live in an age of an unprecedented opportunity for innovation. Since the Internet and cloud computing, the world became hyper-connected in terms of the interconnectedness of people, organizations, and machines (i.e., devices and apps). Furthermore, the costs and time effort for building products and go-to-market are at an all-time-low. As a result, the [...]

The post Introduction appeared first on API Product Management.

]]>
Introduction

We live in an age of an unprecedented opportunity for innovation. Since the Internet and cloud computing, the world became hyper-connected in terms of the interconnectedness of people, organizations, and machines (i.e., devices and apps). Furthermore, the costs and time effort for building products and go-to-market are at an all-time-low.

As a result, the digital economy emerged. The digital economy refers to the economy based on digital computing technologies.

The API technology is one of the key driver of the digital economy. APIs allow the interaction between people, organizations, and most notably machines. This enables new digital business models that have the power to disrupt complete industries.

However, many organizations struggle with exploiting their assets and build digital products. The number one reason is that these organizations build APIs to expose internal assets (i.e., applications, services, and data).

There’s nothing wrong with exposing your assets via APIs. It might be even beneficial for your internal enterprise architecture for integration purposes. In the external market, however, it turns out that this inside-out approach typically doesn’t meet any customer needs and therefore failing in terms of business success.

Customer centricity and outside-in approach are the keys to building successful digital products based on APIs. Start with your customers, the jobs they want getting done, and the problems to do so.

“Managing APIs as products increases the chances of digital business success”, Gartner

In this book, you’ll learn how to leverage APIs to exploit your organization’s assets and create innovative digital products that are based on APIs.

In the following, we’ll first present what API product management is all about and why it’s different to ordinary product management. Then, we’ll discuss why it is hard to create the right APIs in contrast to engineering APIs right, which is rather straightforward. Afterwards, we’ll explain how this book is organized and what you can expect to learn from each part.

What is API Product Management?

API product management deals with identifying, planning, forecasting, production, and marketing of API products at all stages of the API product life-cycle. In this book, we present our API Product Management methodology, which we developed, applied, and tested over the recent years.

The API Product Management methodology is a systematic process based and inspired by popular methods (e.g., lean product management, Lean Startup). The methodology consists of three pillars:

  1. Desirability: Find API products that customer wants
  2. Viability: Define the product strategy to build a profitable API product
  3. Feasibility: Develop the API product (feasibility)
Most valuable design

The intersection of desirability, viability, and feasibility determine the most valuable design.

Why are API Products Hard?

First, there is a misconception about the difficulty of developing APIs. Technically, it is quite simple to build the APIs right. Of course, there are some best-practices about good API design and various philosophies and perspectives on what is right and what is more right, e.g., RESTful.

Build API Right vs Build Right API

It is simple to build APIs right. You just need to select the application you want to expose. Then, you expose the functionalities one by one.This is known as the inside-out approach.

In this scenario, we need to design the interface as generic as possible because we don’t know for what it might be used. In other words, we maximize for flexibility to allow multiple future applications.

However, it is difficult to build the right API that help customers getting their job done and is worth solving. And this is what this book is all about: Build the right API.

To build the right API, we need to get out of the building and use a customer-centric approach to design APIs. To this goal, we should even forget about APIs to focus on the customer’s job-to-get-done or rather customer’s pains.

This is what we call the outside-in approach. It’s certainly leaving the comfort-zone of your office desk. But it’s the best approach to build the right API. And this is the one purpose of this book and the API Product Management methodology: make the outside-in approach straightforward to you.

You Own the Interface, Not the Application

A company’s asset (e.g., software application, service) is the foundation for an API product thus posing a conflict situation with stakeholders. Typically, an asset has an owner. The owner might be known as product manager, business owner, product or application owner, or similar.

We as product leaders want to build on top of these assets, which weren’t intended to be exposed use via APIs, internally or externally. Typically, API pose additional load on backend applications and further security requirements. This is one of the aspects why stakeholder management is essential, especially for API product managers.

What will You Learn from this Book?

In this book, you’ll learn the following:

Part I: Setting the Stage

  • How to think about API with regards to interfaces to a value proposition
  • Explain the differences between digitization, digitalization, and digital transformation and how they relate to API
  • Understand the difference between API solution and API products and their role in the company’s daily business, tactics, and strategy.

Part II: API Product Design

  • How to find desirable API products
  • How to match your company’s assets to customer’s needs and define proper API value proposition

Part III: API Product Strategy

  • How to describe and communicate the product strategy for an API product
  • How to manage the product life-cycle of an API product
  • How to define the ambition of an API product
  • How to find, manage, and involve relevant stakeholders
  • How to select the right business models for an API product
  • How to define the roadmap for an API product

Part IV: API Product Execution

  • How to mitigate risks
  • How do develop APIs in an agile and iterative way
  • How to validate quickly and cheap with customers with respect to desirability and viability

Part V: Closing

  • How to engage your API developers with API products
  • How to pitch an API product

Is this Book for You?

API Product Management is for:

  • Product managers who build API products or build APIs as features of existing products
  • API program leaders who drive an API program in a company and want to create business value and drive digital transformation
  • Product owners who are responsible for planning and development of API products
  • Architects and technical leads who identify opportunities to digitalize business process and design APIs.
  • Innovators who want to unleash the power of API for the digital economy
  • Developers who are interested in becoming successful product managers or entrepreneurs
  • CDOs who want to drive digital transformation and new digital business model to establish the company in the digital economy and API ecosystem
  • CIOs and CTOs who want to facilitate innovation in the organzation
  • Business managers, directors, and vice presidents who want to understand the value of APIs

Please note that this book is not about API interface design, API architecture, micro-services, technology or tools.

How is this Book Organized?

Generally, successful products meet three essential criteria:

  • Desirability: Are there customers who are going to buy the product?
  • Viability: Should we build the products in terms of can we make the product profitable?
  • Feasibility: Can we build the product with the resources we have?

The key to a successful API product is finding the intersecting area between desirability, viability, and feasibility. The following figure presents this criteria for the most valuable design.

Most valuable design meet the criteria of desirability, viability, and feasibility.

Most valuable design meet the criteria of desirability, viability, and feasibility.

Our job as product leader is to design the API product such that it meets all three criteria.

We built the API Product Management methodology around this three criteria. For this reason, we structured the book accordingly.

  • API product design addresses desirability of an API product
  • API product strategy addresses the viability of an API product
  • API product execution addresses the feasibility of an API product

 Part I: Setting the Stage

We need to know why we do what we do to make the right decisions and do the right things. Without this, we lose focus and get lost in irrelevant, technical details.

For this reason, this part describes why APIs are so relevant for almost all organizations across industries and how you should set the context to make them successful.

Further, you’ll find a brief introduction to APIs, which might be valuable if your aren’t yet familiar with APIs.

Part II: API Product Design

When we try to find a problem for a solution, the chances for success are low in general. The better way is to start with a relevant problem and build a solution for it.

“Love the problem, not the solution”, Ash Maurya (inventor of Lean Canvas)

The chapters in this part will present how to explore customers’ jobs-to-get-done, problems, and pains to find and define desirable API products.

To this goal, this part presents the methods to explore and retrieve what customers need and jobs customers want getting done. This involves amongst other things design thinking, jobs-to-get-done, and value proposition interface.

Part III: API Product Strategy

Every strategy needs a plan. Most plan As don’t work. However, it makes it straightforward to pivot and iterate from plan A to a plan that works.

The chapters in this part explore the viability of API products.

To this goal, this part presents the method to explore and define the strategy to make a profitable product. This involves amongst other things API product canvas, business model, stakeholder management, and roadmap.

Part IV: API Product Execution

Ideas are worthless if not executed.

“Ideas are a dime a dozen”, Mary Kay Ash

The chapters in this part describe how to execute the product strategy, i.e., building API products.

To this goal, this part presents the methods to apply lean startup and agile methodologies to the API product development. This involves amongst other things,

Part V: Closing

Being successful is simple if you are working in a perfect environment that perfectly supports you. However, the world is not perfect and neither our environment. Ultimately, success comes from adapting to environments and maximize the outcome.

The chapters in this part reflect upon some organisational aspects, draw some conclusions, and offer some recommendations.

The post Introduction appeared first on API Product Management.

]]>
http://api-as-a-product.com/articles/introduction/feed/ 0 1459
Two Breeds of API: API Products and API Solutions http://api-as-a-product.com/articles/digital-transformation-api-product/ http://api-as-a-product.com/articles/digital-transformation-api-product/#comments Wed, 21 Feb 2018 21:25:21 +0000 http://api-as-a-product.com/?p=640 Everybody is talking about APIs, API products in particular, and its key role in digitalisation and digital transformation. Generally, we associate APIs with agility, rapid innovation, business transformation and digitalisation. No wonder that everybody wants to adopt APIs. So far, so good. Well, when we start our API journey and build APIs, we quickly realise [...]

The post Two Breeds of API: API Products and API Solutions appeared first on API Product Management.

]]>
Everybody is talking about APIs, API products in particular, and its key role in digitalisation and digital transformation. Generally, we associate APIs with agility, rapid innovation, business transformation and digitalisation. No wonder that everybody wants to adopt APIs. So far, so good.

Well, when we start our API journey and build APIs, we quickly realise that reality doesn’t meet our expectations. For example, we may build APIs on top of Web services and end up with yet another layer of abstraction. Or we build an API to integrate two specific computer systems and replace one integration pattern (e.g., Service-Oriented Architecture a.k.a. SOA) with another one. Both adoptions of API are typically far away from what we want, namely agility, rapid innovation, and digitalisation. But why does it go wrong?

There are two breeds of APIs, namely API solutions and API products. Both are different in nature how they provide value to an organisation, how they impact business strategy, how they relate to digitalisation and digital transformation, and what approach we need to get it.

In this chapter, we provide you a model to understand where in an organisation API solutions and API products prosper and how both relate to business strategy, tactics, and operations. Further, we’ll show the business value of API solutions and API products with respect to digitalisation and digital transformation.

In the following, we’ll first clarify the terminology of digitization, digitalisation, and digital transformation and how APIs related to them. Then, we present the two breeds of APIs, where in an organisation each prospers and the reasons why. This forms the model for understanding both breeds of APIs. It will help you either to setup API journey/program or to make the right adaption to your current journey to meet your goals.

What is the Difference Between Digitization, Digitalization, and Digital Transformation

Who is also confused by the terms digitization, digitalisation, and digital transformation? Hands up! Well, at least I was. That’s for sure because people use those terms as synonyms or mixing them.

Nevertheless, it’s important to differentiate between the three to grasp how they relate to both breeds of APIs, namely API solutions and API products.

In the following, we explain the three terms and how they relate to digital technologies such as API.

Pyramid of Digitalisation and API

API enables digitization, API solution enables digitalisation to save costs, and API product enables digital transformation to create new business.

What is Digitization?

Digitization refers to creating a digital representations of physical objects. For instance, we scan a paper document save it as a digital document (e.g., PDF). In other words, digitization is about converting something non-digital into a digital representation or artefact. Computer systems can then use it for various use cases.

An API doesn’t digitize. However, an API can play the role of integrating two computer systems to reduce media breaks.

For example: a user enters personal info into a mobile app. The mobile app sends this info to an API that will push the info into a backend system or database. The data is then accessible for other computer systems and use cases.

What is the Business Value of Digitization?

Digitization itself has no business value. However, it lays the foundation for business cases that leverage the data. In other words, it’s the enabler to create business value, which needs data.

What is Digitalization?

Digitalization refers to enabling, improving or transforming business process by leveraging digital technologies (e.g., APIs) and digitized data. That means that digitalisation presumes digitization as described in the previous section.

For example: a company hires a new employee who will need a mobile phone with subscription to communicate with customers and his team. As part of his onboarding, the employee has to write an e-mail to the according fleet manager who manages both. The fleet manager will send a fax with the employee’s info to the telecommunication company (telco company) to order both. At the telco company, a customer agent will enter the info from the fax into the system and start the order fulfilment process. After some days the fleet manager receives the phone, a subscription, but without SIM card. The fleet manager waits until the SIM card arrives and sends everything to the employee. After two weeks, the employee is ready to communicate with his team and customers.

What if we digitalize the onboarding of a new employee? When HR employes an person, an HR process gets triggered that will automatically order a mobile phone, subscription, and SIM card via the telco company. The order triggers automatically the order fulfilment process. The telco company will send everything at once to the employees workplace address. The employee will already his working mobile phone from day one.

To this goal, the telco company offered an API to order mobile phone, subscription, and SIM card. The company integrated the API into it HR onboarding process and triggers it automatically.

What is the Business Value of Digitalization?

The business value of this digitalisation example consists of three values:

  1. Employee is productive and can create value from day one because he can communicate with customers and his team.
  2. Fleet manager gets automatically updated about the new employee, the mobile phone, and subscription. He can focus on supporting his employees rather than translating and e-mail into a fax and collecting goods.
  3. The telco company reduces costs for the order fulfilment process. The customer agent can focus on value generating interactions with customer and invest more time into a better customer experience.

Ultimately, part of the onboarding process (getting a mobile phone and subscription) is improved and even transformed. More specifically, the process is automated and reduces manual effort completely.

This is an example of two companies who leverage digital technologies like API to improve or rather transform business processes.

What is Digital Transformation?

Digital transformation is the profound transformation of business activities, competencies, and business models to fully leverage the opportunities of digital technologies.

For example: a company has personal information about many customers. Other companies have to verify person info to do business (e.g., insurance companies). Based on the customer info, the company provides an identity verification product for other companies who want to verify a person’s information. And since the company has so many customer info, other companies likely use this identity verification product.

What is the Business Value of Digital Transformation?

Please note that identity verification wasn’t a competency of the company until now. However, the company identified an additional business model based on customer info that might complement or even supplement its current business and market. This is digital transformation.

This is an example in which a company fully leverages digital technologies to transform business activities, competencies, and business models.

Two Breeds of API and Paradigm of Change

Peter Drucker was a master in the field of business thinking. I stumbled upon his Paradigm of Change Model, which I found very useful to understand both breeds of APIs.

Peter Ducker’s Paradigm of Change model suggest that an organisation can be described with the following three components:

  • Strategy (What-Should-Be): strategy describes what an organisation wants to accomplish. In other words, where the company should be. Strategy is transformational.
  • Tactics (What-Will-Be): tactics describes how the organisation is accomplishing the goal. In other words, what the company will do. Tactics is transitional.
  • Operations (What-Is): operations describes what an organisation is doing. In other words, what the company is right now. Operations is traditional.

Strategy, tactics, and operations are the components that describe the constant fluctuations of an organisation.

The three components are depicted as Venn diagram in the following figure. As you see, they overlap. The intersection of strategy/tactics, strategy/operations, and tactics/operations is where the real power of APIs are.

Paradigm of Change model to understand API products for Digtal Transformation and API solutions for Digitalisation

The Paradigm of Change model in the digital area. API products are the breed of tactics and driver for digital transformation. API solution are the breed of operations and driver for digitalisation.

In the following, we’ll use this model to present the two breeds of APIs, where the prosper and why, and how the provide business value.

API Solution is the Breed of Operations

Every organisation has to ensure that their operative business runs as smoothly as possible. It’s the foundation of a healthy organisation and sustainable success.

Hence, it’s important standardise processes to optimise them with respect to time, cost, and quality. When you standardise processes, you can define meaningful metrics, start measuring, and monitor KPIs.

Naturally, every organisation runs into business problems, which needs to be solved. To this goal, organisations typically apply critical thinking to solve business problems.

“Critical thinking is the objective analysis of facts to form a judgement”, Wikipedia, Critical Thinking.

Hence, critical thinking is appropriate to solve business processes because you can analyse them and evaluate KPIs to make fact-based decision about what to improve or change.

Generally, API solutions are built to reduce costs and improve quality of processes through standardisation.

What is an API Solution?

An API solution consists of one or several APIs that solve an integration problem. More specifically, an API solution is an integration solution between computer systems to enable inter-communication.

In the beginning of an API journey, API solutions are the most popular breeds. If designed well, they may provide a simple layer of abstraction that can be used by engineers without profound domain knowledge. E.g., an organisation may have various systems with customer info. An API solution may provide one single endpoint that consolidates this info.

How can you spot an API solution? Typically, IT architects and business analyst work on API solutions. The computer systems are known during the API design phase. The reuse of an API solution is often limited due to its design dedicated to the involved computer systems.

Architects and engineers strive for generic solutions in general to enable reuse. This is no different for API solutions. In theory that works perfectly in practice. However, in practice theory doesn’t work.

We tried to create API products from API solutions. We had two motivations to try it:

  1. API solutions are funded by projects. So, let’s be smart and use it as seed money to build an MVP or enhance an API product.
  2. We may satisfy the project with an API solution and leverage the work for our own agenda. Let’s exploit synergies.

However, projects have many stakeholders (e.g., business project manager, architects, product owners) and goals (e.g., budget, schedules, staffing). Generally, time, budget, and staffing constraints are quite tight and don’t provide you enough space to create new products. Nevertheless, projects may be useful to enhance your existing product. But be careful not to add specialisations to your API products, which will render it less reusable. A clear product vision will be is key.

In the end, we were usually left with a highly specific API solution and many dependencies.

API solutions prospers within operations or the What-Is. The reasons are that the problems to solve are precise and the outcome measurable. Typical problems are integration of two computer systems or automation of business process X to improve speed and reduce costs.

What is the Business Value of API Solutions?

API solutions enable faster and cheaper business processes. Right, but how? Organisations leverage digital technologies such as APIs to enable, improve, or even transform business processes. This is digitalisation and API solutions are one approach to digitalisation.

An API solution enables the automation of the interaction between computer systems. Automation may reduce significantly manual efforts and thus making processes cheaper and faster. Automation requires standardisation, which fosters higher quality.

API Product is the Breed of Tactics

A sustainable organisation needs the ability to adapt or it will die. The proper adaption of new technologies is one element for sustainable business success.

As our friend once stated and became the slogan of one major API conference:

“Adapt or Die”, Kay Lummitsch

The right business strategy is essential. However, good execution of a strategy is often challenging without the proper tactics. The goal is clear but the problems to solve not. This is when design thinking shines. What is design thinking?

“Design thinking in business uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”, Wikipedia, Design Thinking.

Thus, design thinking is a feasible method to find optimal solutions that satisfies the strategy, limitations of an organisation and customer needs. Limitations of an organisation can be staff resources, skills, time, money, etc.

Generally, API products help customers getting the job done. To this goal, API products address customer pains and offer gains. API products have a business model and thus creating value for both the organisation and its customers.

API products prospers within tactics or the What-Will-Be. The reasons are that the problems to solve are precise and the outcome measurable. Typical goal is to explore and find new business models thus, impacting the strategy it self. This is digital transformation in its core.

What is an API Product?

An API product consists of one or several APIs that provide an interface to a value proposition. In other words, an API product consists of value proposition interfaces or rather VPIs. In contrast, API solutions consists of API, which don’t provide an interface to a value proposition. The value proposition of API solutions is creating the communication link between computer systems.

From my experience, every organisation has at least one obvious opportunity for an API product. For telcos, it’s SMS, an API to send SMS to people’s mobile phones. We call it the “Hello World” product, which demonstrates the simplest form of an API product: a monetized API that provides one simple interface to a digital product.

How can you spot an API product? Typically, an API product is owned by a dedicated API product manager. Nevertheless, APIs can also be used as an extra feature of an existing product. But that’s a feature and not an API product. Please note that there is a great potential for conflicts and opportunities between API product managers and product managers.

Since an API product has a business model, it targets a market out side of the organisation. But that shouldn’t restrict its usage only to the external market. You might apply a different business model within the organisation or rather internal market.

What is the Business Value of an API Product?

API products are the key to new or enhanced business models. You can target existing or new markets with an improved or new digital products powered by APIs.

It becomes interesting when an API product doesn’t support the current business strategy. Your management will either trash it or it will transition the strategy into a new one. This is digital transformation, leveraging the full capability of digital technologies that transforms the business of your organisation.

Summary

Essentially, there are two different breeds of APIs: API solutions and API products.

API solutions are APIs to solve an integration problem. For example, API solutions can integrate some computer systems or automate a business process. API solutions is an approach to adopt the capability of API as digital technology to current integration tasks and business processes.

API solutions enable the digitalisation of business processes, which become often automated. The business value of API solutions are typically faster, cheaper, and standardised business processes.

API products are APIs that provide an interface to a value proposition, i.e., VPI. A business model is fundamental part of API products. Products powered by APIs are an approach to fully leverage the capabilities of APIs as digital technology and thus, enabling digital transformation. API products are a tool of tactics to meet the goals of a business strategy.

API products enable digital transformation of your business models and strategy. The business value are complementary or supplementary business model. This helps an organisation to adapt to changing customer needs and market situation. This is crucial for sustainable success.

Be aware about the three components of this model that are operations, tactics, and strategy. Define your ambition and goals and how you want to contribute to the strategy. Do you want to drive digitalisation or digital transformation. Both have a different motivation and scope.

The API Product Management book focus on methods to create API products. Nevertheless, you can apply the methods to create API solutions as well.

Are you interested in our methodology for API product management? We are writing a book about it. Become an early adopter. Get early drafts of the book chapters to apply it. We appreciate your feedback.

The post Two Breeds of API: API Products and API Solutions appeared first on API Product Management.

]]>
http://api-as-a-product.com/articles/digital-transformation-api-product/feed/ 4 640
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/ 3 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.

Pitching a product

Product Pitch at a Hackathon

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/ 2 59