Great APIs help developers do extraordinary and necessary things, often with limited effort. They solve problems that matter to both business leaders and developers.
Achieving API adoption requires that we take ownership of our APIs by looking beyond just the technical details and thinking about how they will be used.
Solve problems that matter to developers
Many teams focus on the wrong problem, resulting in delivering an API product that fails to resonate with the target audience. If you don’t validate your assumptions as you go along, then you’ll end up building the wrong thing for the wrong audience.
To avoid this mistake, it helps to map out the API and how it fits into the common usage scenarios. This mapping exercise should capture the expected workflow and how your API solves for some, or all, of the workflow steps.
The diagram below shows an example of how an ecommerce API helps to drive visitors through the typical site workflow: shop, checkout, login, and/or enroll in a frequent buyer program. Each step maps to one or more steps within the workflow:
Define clear boundaries
Make sure your API is clear in the problem it is trying to solve, as well as what is isn’t trying to solve. An API that does one thing and does it well through clarity of focus far outweighs an API loaded down with lots of disconnected features that don’t solve a single problem.
Become hyper-focused on understanding the problem and then solving for that specific problem first, before you expand your API’s scope. Boundaries can create clarity for you as the API owner, but more importantly, for your API customers.
Common API boundaries include:
- Consumption Boundaries: Who is interacting and what outcomes they expect.
- Technical Boundaries: Specific technologies to mitigate risk or address specific skills required.
- Functional Boundaries: How the process and communication is meant to flow
- Regulatory Boundaries: How rules and regulations drive product considerations.
Focus on outcomes over endpoints
As API product owners, we must be able to separate what we are helping our target audience achieve (the capabilities) vs. the features that help get them there (the API endpoints).
If you are too focused on the API design before you know what your audience is trying to achieve, your API product will fall short. This is often the case for APIs built on top of a database, as the API simply focuses on data delivery rather than the desired outcomes of what the API can do for the consumer.
Look beyond the first release
Once your API is delivered into production, your job as API product owner is just getting started. APIs are like any other product – they must operate on a product lifecycle that matures the product over time.
Most product owners find that there is a whole other world of opportunity that lies beyond the first version of a product. To get to this stage and really engage with this development mindset, you must always be focused on the next release.
Define your API product roadmap, deliver continuously, and seek input from your stakeholders. Continuous feedback from stakeholders beyond the first release is critical for gaining traction and maturity.
Product ownership is essential to API adoption
Achieving API adoption requires that we take ownership of our APIs by looking beyond just the technical details and thinking about how they will be used.
Applying the essentials of product ownership to your API helps increase API adoption, as it moves teams beyond thinking about technology to solving problems for developers and business leaders. When combined with a focus on developer’s needs rather than database tables and an outcome-based focus that delivers capabilities over features, your API will be ready to solve a wide variety of problems.
