API Product Ownership is Key for API Adoption

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.

For the last decade, I have helped teams at numerous different companies transform the way they think about APIs to a more product-centric view. Now, I’d like to share with you some of these insights on how product-based thinking can significantly improve your API products.

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:

It is also important to keep in mind the developer journey throughout the API discovery process, from the time that the developer first identifies the need for your API, to when they start to explore, and eventually integrate with your API. Does your API documentation address the kinds of questions encountered at each step of the journey, from the capabilities offered by your API to how to integrate it into their solution.

The diagram below shows the journey that an API consumer will take as they discover your API and determine if it solves your problem.

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, helping you to understand:

• 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

Capabilities enable someone to achieve something they previously were not able. Features are the individual steps and/or mechanisms that allow them to achieve those outcomes. 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. For example, imagine our ecommerce example above offered APIs that mapped directly to the internal database tables: products, product_inventory, and orders. Rather than shopping and then checking out, we would have to do our own check for available inventory prior to creating an order. Instead, the ecommerce API only lists available products in stock, and can add additional inventory checks upon order creation.

Product Ownership is Critical

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.

Accelerate Your API Delivery

The longer your API takes to get into the hands of developers, the longer your feedback loop. However, a rushed API often requires changes that will force consumers to adapt or die. This was the case many years ago with some popular social media website APIs. Application owners would wake up to failing apps, often on a weekly basis, as the API was changed. How do API product teams balance the need for speed and great design?

I recommend a design-first approach that identifies the capabilities to be delivered, then designing the API to meet those capabilities. Once designed, the API is then delivered quickly across multiple releases.

To accelerate the delivery process and create a tightly-focused feedback loop, consider the following:

1. Build an API delivery team using cross-functional resources — developers, QA, technical writers, and other roles necessary to deliver the API end-to-end.
2. Utilize API definition formats, such as the OpenAPI Specification, to communicate the API design to everyone involved.
3. Take advantage of mocking tools that allow for early experimentation with your OpenAPI definition before coding starts. A point in time when the cost of API design change is much lower.
4. Keep stakeholders involved early and often through shared design documentation and mockups to verify understanding and intent.
5. Deliver the API continuously, rather than all-at-once, using stakeholder feedback to prioritize the delivery schedule based on their needs.

Remember: Once released, it is difficult to change an API design. Use this accelerated delivery process to expedite your learning and stakeholder feedback early on, to avoid needing to make drastic design changes after your API is released.

Conclusion

Product ownership is essential to increased 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.

Related:

• Choosing Between Web APIs and Message Streaming
• 5 Principles for Designing Evolvable Event Streams
• Event-Streaming: An Additional Architectural Style to Supplement API Design

k

DISCLOSURE STATEMENT:These opinions are those of the speaker. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2018 Capital One.