This article is part of APIFutures, a distributed, creator-led effort to identify the most significant opportunities, and/or the greatest challenges, facing the API community in 2024. You can check out other articles and viewpoints on the APIFutures landing page.
I was destined to be a marketer, it seems. Raised by a self-taught developer, I embraced CoralDraw, throwing aside a gift of ‘An Introduction to C++’ in favour of DIY HTML (and that was just so I could make my LiveJournal look nice). Sorry, Dad.
But one piece of advice he gave me really stuck: if you want to go far in business, work on something which may seem boring to most, but which they actually depend on. In a way it was my introduction to Total Addressable Market (TAM).
And he had a point. After all, in our industry it’s all too easy to be taken in by the big shiny things (Blockchain, Crypto, VR), and overlook the unsung heroes: the modern software equivalent of washers or cable ties.
The value of being an unsung hero
My father’s advice rang loudly in my ears when I was first approached by James Hirst about joining Tyk. I knew nothing about API Management. I barely knew anything about APIs, truth be told. But I did know that software was ‘eating the world’, that APIs were the backbone of modern software applications, and that if all businesses are tech businesses, then all businesses must depend on APIs. Ergo, anything responsible for more businesses running them quicker, more securely and more stably, must be a pretty good bet.
Making this decision back in 2017 turned out to be a pivotal moment in my career. Since then Tyk has gone from a scrappy startup to a Gartner Leader. The value of the API economy will soon tip into the trillions, and after an initial wave of consolidation, the category has expanded and diversified as new players pile in to specialise in different aspects of the discipline.
Yet seven years in, despite the continuing momentum in our space, there’s still something that really bothers me.
Why the blank faces?
If APIs are everywhere, and supporting everyone in their role as the ‘critical building blocks for today’s digital applications’, why is it when I go to a dinner party and say that I work in API Management, I can see people’s eyes immediately start to glaze over?
It never fails to exasperate me, given that APIs are the lifeblood of every organisation, touching almost every team’s objectives. From DevOps teams to platform engineers, product managers to marketers like me, more and more teams are relying on APIs to power mission-critical infrastructure, shorten release cycles, and get new revenue streams to market quicker.
But worryingly for those of us working on API Management as a discipline, when you ask a room full of product managers what it is, you still tend to get blank faces in return, just like the ones at my dinner party. It’s the same with marketers. And even many CXOs and investors. But it’s not for want of trying. The biggest companies in the category have collectively spent millions trying to educate audiences about what API Management is and why it matters. So why is API Management still not a ‘tech household name’ like Blockchain, or Crypto?
From a marketer’s perspective, I believe it’s because we focus far too much on what the answer is, and not enough on the question that’s being asked: ‘what do you help me achieve, and why does it matter?’ As a result, we’re working hard on pitching the benefits of API Management, with a message that only a small part of the organisation understands.
The truth is, API Management is relevant to the success of everyone in the business, both as teams and individuals. They just don’t know it yet, because we’re not including them in the conversation, nor using the kind of language that resonates with them.
If API Management is the answer, what is the question?
Last year I launched the API Product Management newsletter, curating those resources that specifically talk to the Product Managers’ side of the organisation – topics like API analytics, monetisation, versioning, product sprint planning and growth tactics.
Seventeen editions in, the newsletter has been a huge success, and it’s demonstrated three things very quickly:
- There’s a huge appetite out there for tools and resources that help ‘less-technical’ team members get to grips with APIs (what Marsh Gardiner calls ‘sociotechnical problems’).
- There’s nowhere near enough content out there to meet this increasing demand. We need more resources to build a bridge between the technical and non-technical sides of the organisation. The wave of API Product Managers is only going to get bigger, looking at Matthew Reinbold’s recent research and James Higginbotham’s 2024 predictions.
- Bridging the gap between the platform, product, and commercial parts of the organisation starts with widening the language we use around API Management, so we can increase relevancy to those teams who remain baffled by the category’s terminology and toolkit.
None of this means that ‘API Management’ doesn’t matter. Quite the opposite. We know there are plenty of API management capabilities that will unlock efficiency and revenue for the product side of the organisation. Just look at the increase in API Dev Portal providers over the last two years, all serving the need for product managers to design, expose, and monetise their APIs.
The challenge is that the majority of these teams and other ‘API beginners’ are not using the language of API Management when thinking about their problems, exploring solutions, or collaborating with their users. That’s not to say they won’t get there: product managers have had to get increasingly more technical as the nature of their products has changed. But we’re not making it easy for them, which has implications for the impact of our own discipline.
In using API Management language at the exclusion of all else we risk restricting ourselves to a technical audience who understand this language. It sometimes feels like we’re happy to keep things that way: it’s comfortable and gives us a sense of superiority to be invisible and incomprehensible to most, but essential for everyone. There’s power in it. But there’s a whole other chunk of the organisation who actively wants to work with APIs and we’re excluding them, to everyone’s detriment.
Could ‘API Experience’ be the missing vocabulary we need?
What would happen if we shifted the language we use to separate the product we sell from the outcomes it enables?
What if we elevated the conversation about API Management in a way that made it visible across the full spectrum of technical understanding, that’s inclusive to all who are interested in APIs?
APIs are the thread connecting any organisation, technically, and between all of the experiences that an organisation prioritises: product experience, brand experience, customer experience, and more. So let’s shift the focus to API Experience, and elevate APIs to their rightful place as the critical component of a modern business, so that organisations can orient themselves around it.
An organisation orientated on API Experience might prioritise:
- Identifying and operationalising network effects
- Customer and user-centricity (yes, DX, but much more besides)
- Cross-functional collaboration
- Incorporating regular feedback loops into their APIs, from internal and external sources
- Greater inclusivity, accessibility and transparency for all audiences
- Data-driven decision making and product management
API Management won’t disappear as a term or discipline: it will be a core Job To Be Done for more and more teams. But it should no longer be used interchangeably as the outcome we promise to stakeholders. For that we need a concept that’s visionary, aspirational, something to come into work every day feeling pumped up about. That’s the power that language should have. It shouldn’t be a limitation that we’re forced to work around when trying to educate and empower new teams every day.
Thinking about the whole API Experience also forces us to think about how to include everyone on the journey, whatever their level of technical expertise. Using this term encourages us to start thinking about how teams collaborate with each other, and helps us intentionally align API Experience with all of the other experiences we prioritise internally.
If we want to think about what an organisation orientated around API Experience would look like, we can start with Amazon. Jeff Bezos drew a line in the sand early with the Bezos Mandate. From the start, he had his eye on the network effects that you gain when everything you build internally could be shared, collaborated around, and become a product. Amazon has prioritised API experience both internally and externally, across the developer community but also far beyond it.
Stripe does something very similar. Every developer, business, or person integrating or interacting with its payment solutions is experiencing the benefits of their intentional consideration about their entire API experience, from internal developers through to external partners, and onto end consumers.
‘API Management’ isn’t a hill worth dying on.
I know a lot of work has been done on this topic already, to the point that Gartner has already removed ‘Full Lifecycle’ from the category name. The focus on developer experience, low-and-no-code solutions, and a move towards composability and open standards is also doing a lot of heavy lifting – and maybe that’s enough.
But I think we’ll get more value from those efforts, if we evolve our language too. ‘API Experience’ connects what we do to outcomes that everyone can get excited about, and inspires ownership across the organisation. As a discipline we owe that to ourselves, as much as our users.
To paraphrase that great API Experience guru, Regina George, we should ‘stop trying to make API Management happen’, and admit that if we don’t come up with something better, we’re stuck with being supremely useful, but ignored.
I think API Experience could be it. What about you?
Emma Kriskinans is VP Marketing at Tyk and creator of the API Product Management Newsletter.
