API as a Product - Core decisions
As Lewis Carroll famously said, “If you don’t know where you’re going, any road will get you there.”
This quote resonates in my mind while I am writing this article about selecting strategies and tactics for developing an API based product.
This article (hopefully the first one from a series) is supposed to ask you, product manager, some basic questions related to creating and defining a product.
1.Define why and how…but first start with the right questions.
When you create an API based service it should be cascaded from the organization’s strategy and it should add significant communication interface to it.
The first question you should ask yourself is WHY? — here I truly recommend reading the methodology “jobs to be done” by Clayton Christensen, you might find it very useful — and then the following questions should arise:
- What kind of work do I do for a client — API recipient
An example:
Delivering an appointment reminder at SPA and Wellness Centre a day prior to the planned visit to make sure the booking is valid via a simple and approachable messaging channel for all customers, like text messages.
- In what context is the job done? (i.e. business environment)
An example:
Wellness business is rather unscalable when it comes to labour, which means an average time of service per worker is 1h during which a service provider cannot offer more services. The only method of scaling is adding new employees, that is why keeping the schedule up-to-date seems to be critical for such a type of business, as well as maintaining the lowest costs possible (i.e. automation via API)
- What are our client’s business rule?
An example:
48h prior to the visit a text message is sent. In case of lack of confirmation till 8hrs prior to the visit the booking can be canceled.
It is surely a very simple example of the work that can be done, nevertheless it shows how you can think of it.
When the answers to the questions are ready you can build HOW in a better way, which are specific tactics realizing the defined strategy.
Let’s get on with this!
2. Where is your business nowadays
How important is API for your business as a consolidated offer? There is no one reasonable answer for all companies, the question should be what the role API has in the business
A Company X — TomTom puts a great emphasis on the API interface design, however it is not a key driver of the company’s income but an extension to their offer.
A Company Y — Twillo is an example of the company which main focus is an API design, it is their critical functionality. All company’s services are delivered via API design.
How crucial is API for your company’s offer? What is its role? You have to answer these questions yourself.
Or maybe the API you are creating is the answer to the need of automation of key processes in the company. API positioning can be a right strategic decision.
All of the choices lead to tactical decisions which I am going to write about in the next section and hopefully in the next articles of this series.
3. The principles of a good API offer
Before you delegate writing bite code to your developers, as a product manager you should define the basic use cases and measure ROI of API interface.
The following three heuristics seem to be helpful:
The innovation of a model:
As we found out earlier in the text, API is not a whim but rather an attempt to solve client’s problems in a new and better way. Now is the time to meet stakeholders and prove the sense of the investment.
How to define and prove innovativeness?
In my opinion, a method explaining the concept really well is defining two growth factors and two barriers which we eliminate. These factors can take the form of more effective products, processes, technologies or even a business model.
Let’s use the Twillo example described earlier in the article.
An example:
The growth factor/the elimination of barriers
+ programmable API interface for text messaging (i.e. automation of confirmations, marketing and remarketing campaigns)
- manual costs reduction of mobile marketing by campaigns’ automation and contact centers
+ the access to call/text interface from within the application
- cost reduction of user’s switching between apps
Monetisation, ROI:
Probably during API implementation and processes automation you don’t know all of the ‘unknown unknows’ related to automation, however you can, and you should, be able to estimate the cost/profit for the planned implementation to convince the stakeholders.
Let’s guestimmate before:
Costs:
Implementation cost — hours and cost of work of:
- Developers
- Architects
- Documentation preparation and communication
- Management
The infrastructure cost
Profits:
- elimination of ineffective manual job
- elimination of indirect costs (management)
Measuring after implementation:
Apart from purely economic results of the implementation (cost aspect) it is worth addressing a user experience issue: If the booking confirmation is automated — it is worth measuring the time required to complete the task.
An example:
A given cohort of customers and its time to complete the task of confirming the booking before (manual process) and right after (automated process)
Bezos API mandate:
Last but not least, an interesting memo of the Amazon CEO in the context of products offering (its genesis is the development of AWS services) Bezos in the AWS offering context created a few principles:
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It doesn’t matter what technology you use.
- All service interfaces, without exception, must be designed from the ground up to be externalize-able. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- Anyone who doesn’t do this will be fired. Thank you; have a nice day!
If your product is addressed directly to technical clients, the above-mentioned memo can be helpful in managing the decisions regarding API.
What is important, in his memo Bezos does not define what? but rather a certain outcome, the largest gain resulting from the decisions is the one gained from the products synergy, which makes it possible to make better tactical and strategic decisions in the future.
Product Managers enjoy the path, the development of API products but primarily make good decisions.
Let me know if you like the content & feel free to comment
Find&ping me on Twitter(https://twitter.com/WojtekSmajda) or linkedin(https://www.linkedin.com/in/wsmajda)
