The API Value Proposition (AVP) Canvas helps your team to discover and scope the APIs and other services you need. It starts from the API consumer’s tasks, expected benefits (gains) and problems. Then it guides you to design your API features as solutions to those expectations.
Start from the right side of the AVP Canvas. It's important your team fills in the API Consumer view first. This will help innovate new ideas, focus on the exact behaviour, features and help needed and avoid building features that are not important.
See instructions below, with corresponding letters. Don’t be afraid of a few iterations with the templates. Use them also for interviewing required people, partners and teams to confirm ideas.
What does the potential API consuming application need to do? Fill in a workflow of tasks when there is no API.
Look at the task list. Analyze what are the benefits of using an API to do the tasks. Think from the API Consuming application team’s perspective. What don't they need to do themselves (assuming they even could do it)?
Why would the team use the API? What problems do they see? Examples of problems:
Match the expected gains with the gain enabling features of the API
Match the expected pains with the pain-relieving features and resources (for example SDK, instructions…)
List the APIs and other services required to fulfill the feature list. Remember no API is an island. Your API will need for example
If you looked already at the API Business Model Canvas –template, you noticed that the areas are numbers. You should fill in all key information in the numbered order. Don’t be afraid to do a few iterations though.
Copy the main API(s) you are now focused on creating/updating to the API name field
Write a short sentence based on the fields D and E telling the "what and why" of your API. Copy the feature fields D and E from the AVP Canvas to the Value proposition (1) field in API Canvas.
You have now looked at the problem from at least one customer segments perspective. Fill in API Consumer segments (2): what was the segment you thought about when doing the AVP Canvas? Who else could also use this API? This is a good place to talk to the people in charge of business development and partner relationships. Don’t forget also marketing and vendor management people.
How do developers find the API? How to ensure API is usable for them, how to understand what it can be used for? How to test drive it? How is their subscription approved? Do they have to sign an agreement? How do they give feedback, see the roadmap, take part in the discussion?
The channels are the ways and places from which the developers find and can find, buy/request access to your API.
What is the API Business model of this API?
Look at the features in the Value proposition field. What do you need to build or create to achieve the features? Don’t forget platforms, testing environments, and other supporting elements. You might need to create also non-API things: agreement templates, marketing materials etc.
Look at the field F in the AVP Canvas. Are there any existing APIs or other services that you can use to create the new API –features? What existing platforms, backend integrations, document templates etc. will you use?
Think about partners in this case as internal and external people outside your team. Look at the Key activities, Key resources, and all the API Consumer related fields. With whom do you need to co-operate to make these API –features alive and usable for the intended API Consumers?
You can either estimate the real costs or set maximum cost based on profit from the revenues. Figuring out real costs can be difficult before the architecture is designed. Remember the fixed monthly costs for running the architecture components. Also budget for continuous small development and maintenance. Include platform costs, licenses, and 3rd party API costs. The variable costs will usually increase to significant amounts per month when your API has over 1 million users.