Products

The idea of treating APIs as products rather than projects is one of the most important business concepts in the API world, and also one I’ve grown increasingly skeptical of in its popular form. The product framing says: an API isn’t a one-off technical deliverable, it’s an ongoing product with users, a roadmap, an owner, a lifecycle, and a business model — and it should be managed with the same discipline as any product. This is genuinely valuable as a corrective to the project mentality, where an API gets built, shipped, and abandoned. But I’ve also come to see “API product” as a concept that’s been oversold and that often founders on the reality that business leadership frequently doesn’t care about APIs the way the product framing assumes. My view of API products holds both truths: the product discipline is real and valuable, and the API product as commonly marketed is often more aspiration than reality.

The foundational insight, which goes back to the very start of my work, is that the API is a business concern and not just a technical one. I launched API Evangelist in 2010 substantially around the business of your API — the recognition that APIs needed to be understood and managed as business assets, not just engineering artifacts. The product framing is the maturation of that insight: if the API is a business asset, then it should be managed with product discipline — understanding its users, defining its value, planning its evolution, owning its lifecycle. An API is research and development for your business model, as I wrote in 2013, which is itself a product-thinking insight: the API teaches you what your business could be, the way a good product reveals what your customers actually want.

The “reflect a business objective, not a backend system” principle is the heart of good API product thinking, and I’ve insisted on it repeatedly. I wrote in 2017 that your API should reflect a business objective, not a backend system — because the most common failure of API design is exposing the internal database structure rather than designing around what consumers actually need to accomplish. Product thinking inverts this: you start from the user’s need and the business objective, and you design the API to serve that, rather than starting from your backend and exposing whatever it happens to contain. This is the difference between an API as a product (designed around value for users) and an API as a technical artifact (designed around internal implementation). The business-first API design and development I wrote about in 2021 is the methodology: begin with the business objective, design the product around it, and build the implementation to serve the product.

The exemplars of API-as-product thinking show what it looks like done well, and Zalando’s principles are the clearest. I wrote in 2018 about API-as-a-product principles at Zalando — a serious, enterprise-scale articulation of what it means to treat APIs as products within a platform strategy. The companies that genuinely do API product management — with real product managers, real roadmaps, real user research, real lifecycle management — produce noticeably better APIs, because the product discipline forces attention to the user, the value, and the evolution over time. What is an API product, which I tried to define in 2025, is more than just an API with a price: it’s an API with a clear value proposition, a sustainable business model, an active feedback loop, and genuine ongoing management. The full product treatment is demanding, and the APIs that receive it are the ones that thrive.

The governance dimension is where product thinking gets genuinely important, and it’s a distinction I sharpened in 2024. I wrote about governing API products versus governing APIs — because there’s a real difference between governing the technical API (the contract, the design, the operation) and governing the API product (the business decisions, the pricing, the roadmap, the lifecycle). Governing the product means bringing the business decisions into the governance frame, not just the technical ones. This matters because so much of what determines an API’s success or failure is the product-level decisions — the pricing, the deprecation choices, the roadmap priorities — that pure technical governance doesn’t touch. Product governance extends governance into the business layer where these decisions live, which is exactly where they need governance most.

The skeptical counterpoint is essential to my honest view, and I expressed it pointedly in 2025. I wrote that API products are a fantasy — a deliberately provocative critique of how the API product concept has been oversold. The fantasy is the assumption that business leadership cares about APIs the way the product framing requires, that organizations will staff API product managers and invest in API product management the way they would for a customer-facing product. The reality, in most organizations, is that business leadership doesn’t care about APIs, that the API product manager role is under-resourced or nonexistent, and that the elaborate API-product apparatus the industry markets often doesn’t match the organizational reality. This skepticism doesn’t negate the value of product thinking — it’s a caution against the gap between the aspirational API product discourse and the actual organizational indifference that most API efforts face. The honest position holds both: product discipline genuinely improves APIs, and the API product as commonly sold oversells what most organizations will actually do. The valuable core of API product thinking — designing around business objectives and user value, managing the lifecycle, owning the roadmap, bringing business decisions into governance — is real and worth pursuing. But pursuing it requires acknowledging the organizational reality that business leadership often doesn’t care, that the product apparatus is frequently aspirational, and that the gap between the API product dream and the API product reality is where a lot of API efforts quietly fail. Treat your API as a product, yes — but do it with clear eyes about whether your organization will actually support the product discipline the framing demands.

Discovery

Learnings

Guidance

Toolbox

Alignment

API Evangelist LLC

Products

References

Guidance Details

Explore more

Discover APIs