The New Year brings with it a multitude of good intentions, with many of us determined to improve our lives one way or another and to set aspirational goals so we can better our current self. With the idea of New Year resolutions, this post is about some New Year’s resolutions that all API Product Managers should consider adopting to better their API product offering.
The API strategy for your organization has been a success. But do you know what will be the next evolution for your current APIs? Are you suffering from API bloat where you’ve no issues with the quantity of APIs you have but you’re concerned about the quality of the APIs? Do you know which APIs or methods should be depreciated and on the pathway to retirement? If you were the consumer of your APIs would you be able to smell the heritage of the APIs you’re exposing? Can the consumer tell if your APIs were built by different teams? Do you have objects in your APIs that are semantically the same but have different schemas? For example, an entity that represents the “end-user” could be represented in different APIs as “customer,” “client,” or “consumer” and each of these objects with different field names but with the same value. It may be time to consider trimming your APIs.
Control your budget
Post-holiday season personal budgets are always a little tighter. For any API program, there is a financial cost for serving any API request within your published SLA. Do you know what this cost is? Is it with an acceptable operating margin for your business? Is your API program really taking advantage of cloud efficiency for costs? Are you scaling down appropriately? Is the cost of serving an API request-response a key metric you’re tracking? Is it a consideration in the adoption of any new cloud service? For example, the following article notes that a move away from EC2 to AWS API Gateway + Lambda drove up the costs by a factor of 8.
Does the API interface that you’re exposing to your consumers give clues to areas where your organization needs to improve? When you’re rolling out an API update do your consumers experience downtime? Are your APIs versioned and are your team(s) following the API versioning strategy? How often have you introduced breaking changes to your API consumers? Is your testing strategy effective in helping your API program? An effective API strategy requires maturity across many disciplines inside engineering, any one of these not functioning will be seen by your API consumers.
Start being more responsible
As you’re treating your API as a product then you must ensure that you have the correct support mechanisms in place. Having a developer portal is not enough. Remember that your API consumers are consuming a product exposed as a service. They will have issues and they will have feature requests.
The added complexity is that these consumers are developers themselves and have higher expectations and needs. As you treat your API like a product, you have to have all the regular product support channels available 24×7 and staffed to support the API (community forums, FAQs, support lines, on-call resources, issue tracking, roadmaps, documented samples, SDKs etc.).
Does the potential security threat of API keep you awake at night? The OWASP API Security Top 10 Release Candidate is available. Do you operate your API program with the assumption that you are vulnerable to all of these? When was the last time that you carried out a security review/assessment of your APIs? Do you understand how the data that your API is exposing is being used? Do you want a Cambridge Analytica scandal on your hands? Do you know how you are both consuming and possibly exposing personal data? Make sure you have a plan for security and compliance for 2020.
Talk to someone
Reach out to your API consumers. Are you engaged with your API ecosystem? Does your ecosystem have access to the road map for your API? In API Design—Beauty Is in the Eye of the Beholder I highlight that “API creation is the art of telling another human what one wants the system to do.” If you’re not engaged with the consumers, then you’ll never really know if you’d get a positive NPS (Net Promoter Score) for your API. Remember with a well-designed API, solid supporting documentation, and good support for developers’ existing tools, you will delight the technical consumers of your API every time.
The API landscape is continually changing and evolving. As we’re post-holidays, most people will have been exposed to Charles Dickens’ story A Christmas Carol, where the Ghost of Christmas Yet to Come (also referred to as the: Ghost of Christmas Future) visits to show the future to Ebenezer Scrooge. Would your API strategy survive a visit from the Ghost of Christmas Future intact? Are you prepared for event-based APIs? Are you still REST-ing? Check out “API Is Dead—Long Live the APIs” for more insights.
Earn more money
Ask yourself if your API is helping address business goals or are you exposing an API for technical kicks. Do you track more than technical metrics (transactions per second, latency, etc.)? What about business metrics? Consumer churn/attrition? Incremental revenue achieved by new API consumer onboarding? How often is an API reused by a different type of consumer or consumed in a different use case? Market share? The value of an API is way beyond technical and it should be tracked.
If you follow and achieve some of these 2020 API New Year’s resolutions you’ll be on the way to a successful API program.
Happy New Year!