APIs are products, but most companies don’t treat them as such
I lead the strategy and delivery of products and systems that solve real problems, support commercial goals and scale across teams and markets. My work spans platform foundations, user-facing experiences, commercial tools and developer products, and I adapt my approach to the needs of each domain. I focus on maturing complex systems, improving the experience for both users and developers and strengthening the foundations that make products reliable, scalable and easy to build on. I care about clarity, good judgement and creating the processes and environments that help teams deliver consistent, long-term impact. My experience covers early-stage, scale-up and enterprise product environments, combining hands-on delivery with team leadership and award-winning work recognised across several innovation competitions.
Everyone says APIs are products.
Almost no one treats them that way.
APIs are often built as technical artefacts rather than customer-facing products. They exist to unblock delivery, support integrations, or enable reuse, but they’re not managed with the same discipline as user-facing products.
When APIs aren’t treated as products, a few patterns show up quickly:
Ownership is unclear or fragmented
Success is measured by availability rather than usefulness
Consumers are expected to adapt, rather than being supported
An example, multiple product teams depended on the same internal API to fetch core entity data. On paper, the API was stable and “highly available”.
In practice, each team used it slightly differently:
Fields were interpreted inconsistently
Edge cases were handled downstream
Changes required coordination across multiple backlogs
No one owned the experience end to end. The API technically worked, but it slowed everyone down.
Once the API was treated explicitly as a product:
A single owner was accountable for consumer experience
Contracts were clarified and versioned intentionally
Success was measured by adoption quality, not just uptime
The result: integration time dropped from days to hours. Teams stopped building workarounds. Changes that previously required cross-team coordination could be deployed with confidence.
Treating an API as a product didn’t add ceremony.
It added clarity.
APIs have users, even if they’re internal. They have journeys, pain points, and expectations, even if those users are engineers rather than end customers.
In my experience, the difference between an enabling API and a painful one rarely comes down to technology.
It comes down to whether it’s being treated as a product, or just infrastructure.
APIs fail quietly when no one owns the experience