In a cyclic and iterative development method, the learning phase varies depending on the maturity of the API product and the persons involved.
In Prototyping phase, the API Consumers are different when the API is in production. Learning can be achieved by gathering feedback or by interviewing API consumers and studying the analytics reports. In building just enough phase you'll learn what works, really. And in scaling phase you learn to remove bottleneck
If you are already a pro with the method, continue to improve and start the next 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
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.
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:
And then when building the API business model, you should also consider
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.
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.
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.
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
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.
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
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.