API Architecture vs. Product Thinking
How can architecture and product thinking work together to build better APIs?
APIs are increasingly becoming products. Or, products are increasingly becoming dependent on APIs. Whatever the case, it's clear to me that product thinking aligns APIs with what consumers need. So, how do you apply product principles to API development?
This article is brought to you with the help of our supporter: Speakeasy.
Speakeasy provides you with the tools to craft truly developer-friendly integration experiences for your APIs: idiomatic, strongly typed, lightweight & customizable SDKs in 8+ languages, Terraform providers & always-in-sync docs. Increase API user adoption with friction-free integrations.
A few recent conversations on the topic of bootstrapping API projects have sparked my curiosity. The topic is incredibly vast and conversations are very opinionated and relate to the experiences of the participants. Which makes the discussion even more engaging from the listener's perspective.
There seem to be two groups of people when it comes to their way of developing APIs. On the one hand, you have the ones who like to see themselves as the architects. They care about how software components communicate with each other. They understand the domain boundaries of each component and see APIs as bridges that link domains together. In other words, they care mostly about the solutions that make APIs viable.
On the other hand, you have those who see themselves as the product people. The first thing they think about is the potential consumers of an API. They seek to understand the problems those people have. They embed themselves into the lives of users and learn as much as they can. They translate the problems into user stories and then into the benefits the API can offer. In other words, they spend more time analyzing the problems that make APIs needed.
Now, I wouldn't say one group is right and the other one is wrong. In fact, I believe architects and product people live in a symbiotic relationship where both groups benefit from each other. They just don't want to admit it.
Architecture thinking ensures the solutions you choose to build your API follow a consistent approach and don't damage the continuity of the business. Product thinking guarantees the API you build fulfills the needs of consumers and transfers value to the business.
Let's see what the most important elements of architecture thinking are to understand how they can align with product thinking:
Business alignment: Every project has to align with the objectives of the business and increment its value to project its continuity.
Technology standardization: The less scattered the technological solutions are the easier they are to maintain. Standardization ensures there's one consistent way to build each type of solution.
Adaptability: However, change happens, and when it does you'd better be prepared. By embracing change and being ready you're making your business resilient.
Product thinking comes from a different starting point and offers a complementary approach:
User-centricity: The needs and problems of users are the starting point of the product thinking process. The goal is to fully understand the perspective of potential customers to recognize what the API should provide.
Continuous feedback: The more ideas are tested the better. Through the use of prototypes and mocks, you can obtain feedback from stakeholders to see how aligned your API design is with their needs.
Value delivery: After having identified the problems and their potential solutions, understanding what value can be generated is critical. Value should flow both into the business and also to customers through their use of the API.
As you can see, architecture and product thinking can and should work together. There's a map you can draw between both sides through the different elements we've been analyzing. If every API starts by identifying the problems users have, it then needs to draw a solution. The solution should then be aligned with the business objectives. Then, making sure you're adaptable is mandatory to run a feedback loop where the proposed solutions can take different shapes. And those solutions should follow what's been standardized and considered consistent. The final piece that links again to business alignment is the delivery of value through the product offering: the API.
In the end, what matters is you're generating value that's aligned with users and also with the business. Everything else exists to feed that ultimate goal of delivering an API that fulfills the needs of users without compromising the continuity of your business.
Going back to what first made me write about this topic, it's good to look at different angles to understand what is important when you're building an API product. It's not architecture against product thinking—or whatever other names you use to label these groups. It's more about finding the opportunities that different thought principles open and the value they bring to the API space.