This article is about best practices and anti-patterns in API product ownership and product management.
This article will touch on all the learnings I’ve had, what I’ve seen from my peers learned from my peers, and what you should be thinking about when you’re writing your first endpoint. You might find this insightful if you’re writing that first endpoint and first API. This article will be about the product, process, and business.
Anti-pattern: APIs are an afterthought.
A decade ago, we were operating in a very traditional business model. We did not focus on building specific capabilities, which are usually part of the application development process, so you only thought of APIs as a solution. This approach is very different from companies like Stripe and Twilio, where they’re creating and selling it because that’s their primary source of revenue.
When you are working in a completely different business model, you are looking at solving certain use cases. When we solve these use cases for an existing partner, we look to see if API is a solution. Because you have an existing relationship, you might want to build something there. But think of whether it can be some Partner API, which is like a hybrid between an internal and external API, which can also scale to other partners.
When it comes to internal APIs, maybe another team inside the company might want to have an application where you probably need to expose the data via an API. So, please do not jump into a particular use case to solve it. Look at the bigger picture because when you start solving a use case, you will be looking at APIs at a later stage. You also have to ensure that you want to have an API-enabled strategy when you are starting to rethink the strategy. When you are looking at this digital transformation, then you may want to consider if you want to monetize it.
The key takeaway is always to think that your APIs are first-class citizens. For example, I worked on a massive monolith application, which contained a suite of products. And the core product also had its APIs. With one of the offshore products, we started solving certain use cases by adding more endpoints to the core product API. We had to rethink the entire strategy. The problem was that we were adding to this monolithic mess. We started looking at the decoupling problem by adding extra endpoints. We were not thinking of API as a product; we thought of API as a solution, which is not good. We had to go back, rethink our strategy and break the monolith.
Myth – APIs are technical solutions and not products.
We look at APIs as technical solutions because we are trying to get work done and focus on building strategic partnerships as product people. Sometimes, we might have APIs to solve a particular use case, and will probably be rarely used. It will be shuttered for low adoption. For example, we went into a partnership with a particular firm with a global presence, and we were trying to step into a particular market. To keep this partnership going, we started adding endpoints and creating APIs for one of the markets in which we already had a strong foundation. We found that the partner that we had partnered with for the new market didn’t have a firm footing, and their user base started dropping. These APIs that we built were not useful because the intention was to build these partnerships and keep those partnerships going with a long-term vision of having a global deal. A long-term vision does open up new business channels, but you may also write a technical solution in the interim phase. So you should look at the long term as well as the short term. These may be developer-driven business needs, but you have to think of other partners and customization because it will eventually turn out to be a technical solution.
Myth – API Development cannot be Agile.
Most teams start off with a waterfall development model. They get requirements, then move to the design, development, and testing phase. It doesn’t always have to be so! When you are at the requirements stage, you can always be agile and get your development partner involved in these discussions to build on those requirements and get those contracts defined together, rather than go through every stage and get feedback.
You need to have that API first approach, but also keep in mind that you can always collaboratively do this. Leverage all the different tools you have to create the design, contracts, communication channels, prototyping, etc. Have some quick and cheap ways of communicating when you are starting. Then combine and test. All this can be done in a very iterative way. Because ultimately, innovation demands agility. To ensure a collaborative design, you should have collective ownership and get your developer involved much earlier.
Anti-pattern – AI and APIs are not complementary
Today as AI is becoming a buzzword, it’s something that you should think about. There may be a time when there will be heaps of traffic with many API calls simultaneously. The solution is to monitor performance. Basic tools may not always help. You need to use intelligent tools to find different patterns.
For example, when I worked in the compliance industry, we used to have very stringent rules. We used to profile performance patterns at the very beginning. After some time, we may have noticed a change in pattern. It may be alarming or a genuine change in requirement. So, we started manually profiling the app. We could have automated it using AI. This sort of profiling will help you monitor the usage.
So, look at everything because that will help you on a per API basis. You want to look at the usage pattern for every API. Look at the possibilities of having API. But if you’re relatively young in a company with an API-enabled strategy, it’s not the best time to invest completely, but it should be the introduction.
Anti-pattern – APIs are not user-centric.
How do we ensure that users have the best experience? That doesn’t mean that you’ve got to invest time, resources, and money; you can do it locally. When building, try to have you have your POC, write your client, and test it out. If you’re doing it internally for another team, you want to give them the documentation and perform some usability testing. That’s a good test to do at a low cost within the company. That’s not going to scale once you start opening that up to even various other teams internal to the company. You will start figuring out whether you have sufficient budgets and money to invest.
You can then look at various ways in which you can collaboratively design. You can start having a design and UX team with account holders to manage the collaboration. But as an engineering and product team, you have to ensure that you prototype, test it out and validate it iteratively. That’s when you have to think about API portals and tools.
Myth – APIs are CRUDdy
CRUD is a good way for a basic set of operations. But now, it is beyond that. You are looking at graphs and performance. You are looking at device APIs, like a Fitbit. We don’t know. There may be different use cases, and they will continue to exist, or there might be new ones too. So do not have a fixed mindset; explore various options because each one will have a different use case. There could be different protocols and methods.
Anti-pattern – APIs are black boxes
We do not expose the entire functionality to our partners or vendors. But, when we have to help them, we have to ensure that we have sufficient knowledge and data. While debugging, to make it easier, ensure error codes and response codes convey the correct issues. Your documentation must be perfect for ensuring that the API can be worked on later.
Myth – APIs cannot be hacked
Nowadays, there are many compliance requirements. So, every layer needs to be checked. OAuth and TLS are not secure enough. Look at all possible layers to check for a security breach. If you have access to a security team, use them at the start, do not wait till the end. If you do not have one, please ensure you get one at the earliest.