API value proposition canvas

OVERVIEW

You design good APIs around API features. API features emerge as you map customer activity (‘touchpoints’) to customer journeys.

The API value proposition canvas helps with this mapping. You get to switch your perspective. Think about what developers need to support the customer journey!

The API value proposition canvas reveals the “product-market fit” of your API. It exposes the features that will deliver value to API consumers. It shows what APIs are already available and what new APIs need building or buying.

The API Value Proposition Canvas 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 behavior, 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.

‍

‍

SECTION A: TASKS

What does the potential API consuming application need to do? Fill in a workflow of tasks when there is no API.

Good APIs rely on good API design. Good design starts with the right context, namely a customer journey.

A customer journey is like a business process from a customer’s point of view. It shows how and where they interact with your business, your people, your systems. In public sector, citizen journey may be more appropriate.

Even internal API designs should start with a customer or employee journey.

‍

SECTION B: GAINS - BENEFITS FOR USING 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)?

‍

SECTION C: PAINS- PROBLEMS USING API

Why would the API consumer team not use the API? What problems do they see? Examples of problems:

• identifying end-users,
• data formats,
• privacy,
• security,
• response times,
• agreements,
• costs or
• feature compatibility.

‍

SECTION D: GAIN ENABLING FEATURES OF THE API

Match the expected gains with the gain enabling features of the API

‍

SECTION E: PAIN RELIEVING FEATURES OF THE API

Match the expected pains with the pain-relieving features and resources (for example SDK, instructions…)

‍

SECTION F: APIS AND SERVICES OFFERING THE GAIN ENABLING AND PAIN-RELIEVING FEATURES

List the APIs and other services required to fulfill the feature list. Remember no API is an island. Your API will need for example

• identity and authentication services,
• other APIs,
• back-end integrations,
• algorithm development,
• storage,
• API management,
• developer portal etc.