What productising an API actually involves
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.
Saying an API is a product is easy.
Actually productising one is harder, it forces clarity in places most organisations avoid
The biggest shift isn’t technical. It’s intentionality.
Productising an API starts with answering questions that infrastructure teams often don’t have to:
Who is this API for?
What problem is it solving for them?
What does success look like from the consumer’s point of view?
What should consumers not try to do with this API?
Without clear answers, APIs tend to grow by accretion. Endpoints get added to support one-off use cases, and complexity increases without anyone owning the experience.
Another key change is ownership.
A productised API has a clear owner who is accountable for:
Consumer experience, not just uptime
Backward compatibility and change management
Trade-offs between flexibility and simplicity
Saying no to use cases that don’t fit the product’s direction
This ownership makes decisions explicit instead of implicit.
Documentation also changes in nature.
Instead of describing what exists, good API docs explain:
How the API is intended to be used
Which patterns are supported (and which aren’t)
How consumers should think about evolution over time
Equally important is feedback.
Productised APIs create feedback loops:
Usage patterns are instrumented and analyzed, not assumed
Pain points are surfaced early
Changes are informed by real consumer behaviour
Finally, success metrics shift.
Availability is necessary, but insufficient. Product APIs are measured by:
Adoption quality
Ease of integration
Reduction in workarounds downstream
Productising an API doesn't add ceremony, it removes friction. Done well, it's what allows many teams to move faster, consistently, without reinventing the same solutions."
Productising an API is about reducing cognitive load.