What Does “API as a Product” Mean?

Though we tend to think of APIs in a very technical way, they are increasingly combined within the context of business offerings and values. Accordingly, many are recontextualizing things to treat APIs more like products.

An API is essentially a traditional service, delivering capability to the end user without sharing the risks and costs associated with the service. Appropriately, even if the API provider does not function as a business per se, we should treat the API as a business asset rather than an amorphous codebase. When the API provider is in fact a business, there’s only a greater reason to do so.

To help understand why this is valuable, and to leverage the results of such a shift in thinking for better systems and technology, let’s define some business terms within the context of the API industry.

Consumer

When someone says consumer, the first thing that pops into most people’s minds is a person buying a product, exchanging currency or services for that product. In the world of APIs, a consumer is simply anyone who utilizes a service, regardless of whether it is paid or not.

There are two types of consumers — external, and internal. The external consumer is exactly what it sounds like, a third party that exists outside of the business. This can be the end user utilizing the free, public endpoint, or another business utilizing a private, paid endpoint. An internal consumer, however, is someone that exists within the business unit. This might seem strange to non-business people — after all, how can a business purchase their own products?

From a business perspective, there is value behind each transaction, regardless if the transfer of value is simply in generating data, integrating with third party solutions, or driving revenue directly. Thus, by treating the API as a core business value generator integrating with both consumer types, you can leverage the revenue streams that you do have, and improve the consumer experience.

Investment

People tend to think of coding as creating something out of nothing, but the fact is that development is not a zero cost process. For every hour spent working on the codebase, developing new integrations, crafting new endpoints, there is a cost. This cost can be in worker hours, or in the very real cost of spinning up additional virtual or physical servers to support the API functions.

This cost is something that must be managed for better return on value. Running out of money when half the codebase has been created means you have nothing to offer the consumer, but being stuck perpetually creating revenue driving endpoints while ignoring core value to the user can be just as damaging and just as useless.

Investment and funding management processes can better guide development and production to at least ensure a minimum viable product. Iterating and expanding upon this demand ensures that the product can evolve to changing business needs, as long as it’s constructed around user feedback and real-world analytics.

The key here is to ensure return on investment not only for added value to the various stakeholders and owners of the API, but for the very real amount of increased assets and resources that can be poured directly back into development. This in turn can result in development of long-term features that facilitate long-term funding.

Roadmaps and Lifecycles

If we’re going to treat the API as a product, it makes sense then to useroadmaps and product lifecycles. Defining what the minimally viable product is, and then developing roadmaps and implementing other lifecycle management tools (such as the API Model Canvas) to govern iteration upon it has several massive benefits.

First and foremost, this process prevents feature creep. By limiting development to a set course of known functions, values, or additions, creeping scope can be limited, making better use of limited resources and ensuring that the consumers get what they need before anything else. This prevention of creep also typically results in a leaner codebase, which is easier to iterate upon, document, and fix.

Additionally, by limiting development to that which is on the road map, you prevent extra, unused endpoints, features that are never completed, etc. You’re essentially preventing bloat, which in turns prevents feature fatigue and reduces your security threat footprint.

Additionally, implementing a lifecycle management process that mirrors processes such as those found in ITIL or other management guidelines can ensure that long-term value is created and limited resources are optimally managed. This will have a long-term impact on your organization, and can ensure that the API sticks around for a very long time.

Reversing the Developer-Consumer Relationship

The classic relationship between the developer and consumer might look like this — “we built this awesome thing, now how can we get people to want it?” Unfortunately, that’s not always effective when it comes to APIs. An API by its very nature is typically built to do something very specific. By treating the API as a product, you’re essentially reversing this approach. Instead, it becomes “people really want this feature and codebase, how do we build this awesome thing?”

Iteration and development should be based entirely on the foundational concept of doing what the consumer needs. Iterating on feedback and real-world use cases will always deliver better, more highly-adopted codebases, and result in a more well-supported project. The consumer in this approach comes first, and then the tech follows.

This is of course not always the case, such as with speciality APIs or APIs implementing experimental systems, but in those cases, the API isn’t really being framed as a product — in other words, that is a very particular exception to what should be seen as a general, fundamental rule.

Consumer Friendly

Any business will tell you that success goes hand-in-hand with being consumer friendly. Unless you’re the only option for a very specific use case, if your product is less user friendly, it will not be widely adopted against competition. That being said, there are certain factors that must be considered to be truly “user friendly”.

• The API must have a great developer experience: This means the API must be easy to onboard (setting up an account and managing personal data), describe (the API must have a core competency and function that can be explained), and consumed (documentation must be adequate, and understanding systems in place). Failure to ensure the API can be consumed means that you will have an overly complex product that users will eschew in the face of easier alternatives.
• The API must be marketed properly and evangelized within the correct context: A secure banking API that utilizes existing systems and technologies in a better way is not “disruptive”, and marketing it as such would cause many consumers who want a stable, proven system to look elsewhere. The same is true of users who want something new — if your API is branded as “same old same old” and yet marketed towards early adopters, you will see low adoption and low success.
• The API must be unique: The market is vast, and for every implementation, there is an alternate one vying for the top spot. Simply put, to be a viable API product, it must be unique in some part of its implementation. Whether this means the UI is designed for a particular workflow or the solution is truly novel, the API must have a unique element that makes it intrinsically valuable to the internal and external consumers.
• The API must be secure: No user is going to consider a solution friendly if its data is unsecured, exchanged in the clear, and unencrypted. Secure your API, and the value will be readily apparent to the average user.

Define and Adopt Business Roles

While this will likely make some anti-business types groan, perhaps the best way to integrate this concept of “business as an API” is to adopt some common business roles within the product development team. An API that integrates these roles should have a few basic roles to help guide form, function, development, and marketing.

• An API Product Manager can help guide the API Product Manager can help guide the API to adhere to the business guidelines and roadmaps as set forth.
• API Sales Managers can help define the evangelizing and marketing that must be done to support the external user and drive discoverability.
• API Process Managers and Process Owners can help guide the functions of the API itself as well as the resources they govern.

While there are many roles, like evangelist, advocate, etc, these three are a very good start, and adopting them can help reframe an API into a product.

Assume Your API Will Become an Public API

While many API developers develop within their current and given business status, this can be harmful. Assuming that your API will always remain private, or always remain limited to business interactions, only limits the potential for growth and new revenue streams.

By assuming from the start that eventually everyone will be using your API, you can start developing systems in such a way as to support this possibility.

Simply put, assume that at the end of the day, you’re not going to be there to walk the future public user through your API, regardless of whether you intend to ever make it an open API. Develop in such a way that this pivoting can be done easily, with minimal cost, and with efficient application – at the very least, you are enabling success, rather than preventing it.

Final Thoughts

To fully embrace an “API as a product” mentality, assume your API will become public. This will result in better defined endpoints, more efficient routing, better systems of scalability, and interfaces that are well-documented and defined, even if they may never open to the public.

Not every API is going to fit into the traditional idea of what a “business” is – some APIs are just for internal use or for very limited, custom audiences. In many cases, there may not even be a direct revenue source. Nonetheless, every single API has its own consumers, and as such, treating the API as it if were a vital business system can have huge benefits to your users.

Assume regardless of the final product that your API will someday be a public product. At best, you will be thinking far ahead, and at worst, you will simply engage in more efficient, valuable, and impactful development to create a better product.