Product Mindset For API Development
5 Things Every Product Manager Should Know When It Comes To Develop A Successful API: Part 3
About this series
In the following 5 articles, you will learn best practices in developing public APIs and how to take the first steps on this path.
Each article goes through one of the main topics in developing these interfaces. These are the topics that you will get access to:
Product mindset in API development → This One
Business model and growth → 25/10
How to write documentation for an API → 01/11
In the past, if we went into the process of creating an API, we would have found a project that connected systems within a single application.
But when we look at today’s scenario, that API must be maintained by a product team focused on making that application easy for developers to use, opening it up to be leveraged in many applications across the market.
The product mindset, in other words, transforms the API from a system integration project to a digital asset that can provide ongoing value. It ceases to be just a technical requirement and becomes one of the products of the company that built it.
Product Mindset For APIs
The product mindset is a key factor in developing a public API. It must be owned by those responsible, since delivering a list of technical requirements may not generate any value for the business.
The person responsible for developing this product must understand the real needs of the stakeholders (customers and developers) to translate them into requirements when building the application.
Extracting maximum value from API products involves not only technical factors but also how it will be operationalized by users.
This product mindset must recognize that the future of the API must come through interaction with developers and users.
An API product provides opportunities or solves existing obstacles, but the full spectrum of API use cases may not be obvious upfront.
These opportunities can be mapped into the product through development cycles by intelligently leveraging APIs.
Lean methodology in APIs
Let’s take the example of a financial company, which can have in its platform several functionalities such as buying and selling of assets, sending and receiving of amounts, and consulting services, among many others.
Trying to externalize all these services at the first moment is not the best approach. You would suffer from dependency issues and not have enough time to test the interface with your users.
In this cycle, you would fall into the waterfall development process and end up developing a big monster that may deliver little or no value to the companies that will consume your application.
Starting with a low-effort approach is the best way to test API products with less risk.
That way, your product team can understand the real needs of the companies that are looking to consume the data and applications you have, and your API grows by delivering more value to them.
Launch endpoints that can deliver value on their own first;
Think about your main services provided on the platform and how they could be delivered through an API;
Look for simpler use cases that can be automated and used through your API;
Understand how the usage of your API will generate value for the company that will use it. Searching for the contexts and problems of these companies always helps in this process.
Delivering APIs for Long-Term Value
One way to design APIs effectively is to bring a product mindset to their development. How an API is created is of critical importance, as it will be consumed by developers who can suggest how it can easily leverage the business in new ways in the future.
Mistakes such as neglecting documentation, design patterns, versioning, and security can prevent future use of the API and adaptability to different use cases.
Let’s take an example to make the case clearer. Building APIs to meet specific project requirements is an approach that can limit the longevity of the application.
This limitation occurs because the implementation details were developed only for that design scenario, which makes updates more complex and can make the API more difficult for new developers to use.
When APIs are not designed for easy development and intuitive consumption, difficulties bring the threat of complications and lost productivity.
Otherwise, APIs built with a product mindset will facilitate consumption and increase the likelihood that the API will provide strategic and economic value to the company developing it.
Some bullet-points:
API development should think about both present and future problems. Codes that only solve the now end up becoming obsolete in future scenarios;
Thinking of the API as a product and not as a technical requirement brings with it the understanding of the value it can generate for the business more broadly;
Making it easy to integrate with your API makes developers build better applications using what you provide. Getting your application complex only drives away those who might need your solution. *Make the developer’s job easier.
Developing the API with all the scenarios your company can offer may not be the smartest approach. Throw in the minimum that developers require (and that generates value) and understand through interactions what next steps need to be taken.
See you in the next chapter.
The Technical PM is a FREE newsletter for those who are looking to develop technically in product management and expand themselves further.
If you enjoyed reading this post, feel free to share it with friends!