I am preparing for a busy week of conversation with folks at API World, and with an inbox full of requests to meet and discuss the challenges API providers and service providers face, I want to work on preparing myself by loading up a variety of topics into my old brain. Some of the folks I’m talking with have shared questions with me to prime our conversational pump, so in my way, I figured I’d work through them here on the blog to help put these thoughts on the tip of my tongue.
AN area that API providers are rabid for more information on is how we they increase adoption of their APIs, and turn consumers from just making a few API calls into active users who are putting APIs to work within their applications. I would break these things into two distinct categories: 1) increasing your understanding of how your APIs work (or don’t), and 2) increasing your understanding of the context in which your consumers operate within. While you may be focused on how to get a users adopting a specific API endpoint, you may not be thinking about the lack of flow between each of your API endpoints, and you probably aren’t fully up to speed on your consumers workflow, and how the two do not match up. Which is more about how you define and design your APIs, and get to know your consumers, then it is about actual adoption or consumption.
Reference API Design Versus Workflow API Design
When I talk with API providers about why people aren’t using their APIs I find the most of the time there has been little consideration for how those APIs should be used prior to them being released into production. Most APIs I come across are purely reference-based designs. Meaning they reference the resources being made available, but do not speak to how they will actually be put to use. API providers who are just beginning in their journey have a lot of trouble lifting themselves out of their silos and relating to the outside world of consumers they are targeting. As API providers we know our resources, and we assume this awareness exists amongst our consumers. They should just be able to consume the reference documentation, and be able to connect the dots regarding how to actually put them to use. When in reality, developers need a lot of help in this area, often times if workflows between multiple APIs haven’t been considered as part of the API design process, there are sharp edges that prevent developers from realizing a smooth adoption, or getting to the point of increased consumption of your valuable API resources.
Use Cases, Personas, and Consumer Workflows
Understanding our target consumers is critical to increasing adoption and consumption. Developing an awareness to new users we’d like to attract by developing and evolving personas is essential to learning to speak to the consumers who actually need our APIs—helping them see how APIs provide solutions to their problems. This awareness of consumers continues even once they have on-boarded and making API calls, requiring us to invest time in understanding the context in which our API consumers are putting our APIs to work. We might think since they are using API A, then using API B just makes sense, but without more understanding of the context in which they operate, the leap from A to B might end up being further than we realize. We might not understand all of the friction they encounter with the workflow from A to B, or realize that the leap isn’t worth it without C. It takes a lot of work to build an awareness of fictional API consumers that do not exist yet, and it takes even more investment to get to know the ones who have shown up and are kicking the tires, or using our APIs in some basic ways. However, API adoption and consumption is more about our awareness and the state of our APIs, then it is about our actual consumers, and pushing them to just make the decision to jump.
Leaving Our Silos and Developing Empathy For Consumers
Like almost every other area of API operations there is no silver bullet to increasing API adoption and consumption. It requires getting to know your consumers, which is something that doesn’t always fit with the limited budgets API providers operate under, and the scarce resources we have to profile, target, and understand our communities. It is a practice that will take regular investment and refinement, and having to make hard decisions about where to cut corners, as well as the places you just can’t ignore. There are a lot of unknown unknowns in the world of API operations, and it is something that takes weekly and monthly review of where things are at, what we’ve learned, and what adjustments we are going to make based upon the real world data we’ve gathered about wha works. It is something that will grow and evolve as our awareness of our community grows and evolve. It is something that we will get better at after getting to know what are consumers are facing in their environments—forcing us further out of our silos and demanding that we develop more empathy for our users.
API adoption is equal parts a provider and consumer concept. The design of our APIs, and the makeup of our operations will define our success when it comes to initial usage moving to adoption, and then evolving to sustained consumption. The understanding of our consumers and their needs will be more important than our own understanding of our resources, and our ability to publish reference documentation. Our success will ultimately depend on us being able to move from providing API resources to providing API solutions that can be easily applied to everyday problems our consumers face. Pushing us to evolve from just being good REST API designers, to being good experience and workflow API designers. Often times we just can’t see the leap required for increased adoption and consumption, because we haven’t walked in the shoes of our consumers, and we can’t understand the distance that exists between onboarding with our APIs and putting our APIs to work in applications. This outward facing reality is something that most organizations don’t realize hs to exist before you will realize any API success, because often times we are too insulated within our operations, unable to break through and reach our consumers in a meaningful way, helping us better relate to the challenges they face--making that critical connection that helps get them over the hump and begin putting our APIs to work.
