The Cycle

Great APIs are born when skilled people work collaboratively using a great business model.

Jump start implementing APIs by picking up any of the eight phases befitting you

1. Business model. Use API Canvases. Find the right value proposition to your API. Define impact to business model.
2. Lean Architecture. Follow the Minimum Viable API Architecture process.
3. Build API. Prototype, build or scale depending on what architecture phase you are on.
4. Audit your API. Use the checklists to verify your API meets style, API management and security needs.
5. Publish the API.
6. Mind the Developer Experience: Support and build developer community.
7. Measure business and technical KPIs to reach goals.
8. Learn from the results and improve your API and the process.

‍

API business models

API based business models are the core and starting point of of this method, together with value proposition. Business models are important, so the true purpose and customer segments for the API are found early. This not only helps transform business to new data and platform business models, but it helps to focus the development and secure customer buy-in and budget.

‍

Value proposition

The value proposition describes the value that the customer/user of a specific product or service feels they receive as the result of using the product or service. APIs are products and just like in all products, users will need a good reason (=value proposition) to decide to use it (=conversion).

You will use the API Value proposition canvas to work out the possible contents of the value proposition. When writing the value proposition down to the API business model canvas, you need to make sure it answers these questions:

• How API Product in question solves problems or improves the situation for the selected API consumers?
• What specific benefits are there to use this particular API instead of other integration methods for the selected API consumers?

And then when building the API business model, you should also consider

• Why external partners or customers should use our API instead of competitors’? (think about this if you are offering the API to external parties)

‍

API Product manager (or product owner)

Traditional product managers are commercially and analytically oriented persons who rely on tools like market research and user studies, work with sales, marketing, and other stakeholders to create a product that will sell. In Agile development, product owner has typically less commercial responsibilities but is still a customer/stakeholder advocate and prioritizes items in the backlog according to the value they bring to the customers.

The technical nature of APIs as products requires API Product owners to translate the value proposition into technical capabilities and the technical capabilities into business terms.

Customers of API Product owners are software and technology developers, but also business developers of customers and partners. API Product owner needs to understand the specific nature and needs of these user groups. They also need to translate these into capabilities that his own team of backend developers understand and can actually build.

One major task of API Product Manager is to explain and mitigate the risks and values of opening their company’s data and value propositions to the world as a platform and also figure out how to build customer value from networks of other companies and their API using or offering products.

API Product managers require great communication, business and technical skills.

‍

Application service manager

CRM application serves as an (indirect or direct) backend for specific APIs. Any changes to the CRM or any service breaks may affect the APIs depending on it and the API consuming applications. Any needs to add or make changes to the dependent APIs may require changes in the application serving as a backend. If requirements come from other teams or external partners and customers, funding and priority have to be negotiated. Service manager needs to do release plans, change requests and service break down notifications minding the APIs and API consumers. Requirements depend on architecture and dependency of the API layer.

‍

Information architect

Responsible for designing how requirements need to be split into independent APIs, endpoints and attributes and how to negotiate requirements between payload sizes, privacy and confidentiality requirements, local legal requirements and business processes. In charge of making sure the naming standards and values are valid also outside the company data architecture and naming conventions. Ideally creates guidelines for API publishing developers and conducts reviews.

‍

Developer segments

Developers are our API consumers, but also your potential paying customers, sales channel, outsourcing partners or innovation partners. Each segment has its reasons why we are interested in them, and they are interested in us, as well as their own unique needs, behaviours and logic.

Typical developer segments regarding APIs are

• Business developers (selling or developing new business models, products and services that use our APIs)
• Software developers (software applications using APIs)
• Technology developers (devices using APIs)

It may be useful to split the segments even more, to internal developers and external developers or according to the product or platform segment or their interface expectation or their knowledge and skills about our company, our products or using APIs in general.

‍

User groups

Depending on what kind of API management solution or product you use, there may be different names for specific default user groups, and usually, all management products allow creating company-specific user groups. Typically, users related to APIs are divided into these high-level groups

• Guest users or unauthenticated users, who can see available APIs but are not able to make API calls
• API consuming developers
• API publishing developers
• API management platform administrators (users who can administrate network settings, API publishing user accounts, overall security settings, etc.).

In big companies, these user groups need almost always to be separated into smaller user groups, as not all consumers are allowed to use all APIs (private or partner APIs) and not all teams of API providing developers can even see, know or administrate all APIs.

‍

‍