Mastering APIs as a Product Manager

Gareth Faull at UXDX Community: Tech Leadership Essentials: From API Mastery to Team Dynamics. Video: https://youtu.be/VjeKPIILpjA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and what an API is

[00:00:01] Right, just firstly, I guess talking about how do you motivate people, I guess you get to know them, so I'll try and let you know a little bit about me. I think we've already been through my name so skip that. I'm originally from New Zealand but I've lived in the UK for a long time, so I now have a British passport. Halt and Catch Fire is my favorite program, because one of the lead people is a product manager, which is not the case in any other film or TV show that I'm aware of. And I have both a design and development background, a bit of skin in the game there. In terms of my work, for the past how many years now, six, seven years or so, I've been focused on APIs as a product manager, most recently at the London Stock Exchange Group. And this is actually the focus of my life at the moment really, and that's my little girl Bella.

[00:01:22] Right, so I have no idea how much people know about APIs, but I thought I'd ground this talk in a little bit of information about what that stands for and how they're used. Application programming interface, that's what API stands for. It's the communication between two systems or two applications. Usually, I think 80% of the APIs out there are REST APIs. You don't need to know what that means, just that they're probably the most simple APIs to understand, the very almost natural language way they're formatted and things. Most of the payloads are usually in something called JSON, which is the native JavaScript formatting. So yeah, especially developers find them very easy. And it means that you don't need to know the language of each application, in terms of the programming language, in order to get the functionality or the data that the other application has and use it in yours.

[00:02:48] In terms of, you'd have an API platform as well, so that means all the common services of an API get shared amongst a number of APIs, so things like authentication. I'm trying to do the arrows on my computer and that doesn't work, I don't think.

[00:03:14] So APIs are very powerful. I may be a little bit biased anyway. I think most people have heard of these companies here: Expedia, OpenAI and Stripe. I've never worked at any of these. OpenAI I guess is sort of the most relevant currently, in terms of the fact that over half their revenue comes directly from APIs. It's really where people get to use their AI. Things like ChatGPT are all accessible via APIs for app developers. Surprisingly, this was 10 years ago, Expedia.com generated 90% of their revenue via APIs.

Two types of API product manager

[00:04:15] So yeah, I would group API product managers into two different types. I did touch on the fact that there's an API platform, which is all the common services and tooling around APIs. And there's also API provider, and that's a person who owns the APIs themselves, so whether that be a functionality or a data category. So for example, at Modulr, that was a B2B payments company, so there'd be different API provider product managers depending on the type of payment that was coming through on the APIs. So direct debit, or SEPA which is the European payments, or Faster Payments in the UK, were different people. And then I was both a platform product manager and an API provider one.

[00:05:24] At LSEG, as we call London Stock Exchange Group, I am purely an API platform product manager and that's all I do, that's my day-to-day job, because we have hundreds of APIs and many, many API provider product managers. Often, if not always, the API provider product manager doesn't just look after APIs. That's just one of their roles, because we're far more data focused, and therefore they're responsible for a content area such as ESG, which is environment, social, governance data, and things like that.

[00:06:22] And I guess so far, you might think of APIs as quite, I don't know, not simple, but I think in terms of actually using the APIs, typically a developer would integrate with an API and then use it. So an app like, I don't know, your banking app is talking to the banking back end, or maybe other third provider back ends, via API. Now that's quite a simple exchange, simple process. It just goes and gets things and brings it back.

[00:07:05] The API life cycle is quite a complicated interaction. You design an API, you have an API strategy, you do the documentation, you develop the back end, you measure usage, you have an API portal on the front end so that developers can consume your APIs, you market your APIs to other product managers, you version your APIs. Yeah, there's lots of stuff going on there. Generally at the moment a lot of the language and stuff around the API life cycle is very developer focused, but I'm trying to bring that into more of a product world, and those green highlighted things are more perhaps something that a product manager would be responsible for.

What the API provider product manager needs to know

[00:08:13] Well, I think I'll go back a little bit and just say that, as I was saying, especially at LSEG, API provider product manager, that's probably a role like, I don't know, product owner might be a role of a product manager, like an agile role, whereas an API provider product manager, API provider is a role that they have. And so some of those things that they might need to be able to do as part of that role, it makes it actually hard, because they may or may not need to know a bit more about APIs than maybe the other channels that they're responsible for.

[00:09:02] So they need to understand the customers, which they need to understand for everything, but they need to understand that from an API perspective, because their customers aren't just the product managers or whatever, they're the developers that are integrating. Knowing about the whole API life cycle and what that means for them, and someone who understands all the documentation and content that they need to produce as part of having an API out there commercially.

[00:09:37] I guess that's the other thing I haven't put forward much yet, that I'm really focused on commercial APIs, but there's loads of internal, LSEG to LSEG or whatever company, APIs out there. And they are, I guess, much more developer focused, in terms of developers only need to know about them and they're not marketed or anything like that. So yeah, so I guess what I'm talking about is mostly around the commercial side of things.

The API platform product manager

[00:10:23] API platform product manager, I think this is something that's fairly new. Usually maybe an architect would lead the platform team for an API. So I guess the expectation is that you'd be a whole lot more technical than the average product manager. Going back to the provider product manager, I don't think you have to be that technical to be one, you just need to know enough about developers. But the platform product manager really needs to, almost, it probably needs to have been a developer at some point.

[00:11:08] They also need to understand what a platform is, and how being a product manager around a platform, how that works, so that you have two sides. It's about like having a marketplace. You have the customers on the API provider side, the internal customers, and you have external customers, which are developers and actually product managers and whoever wants to buy the APIs or use them.

[00:11:44] What they need to know about is the standards and guidelines around what a good API looks like, and patterns around APIs. Not as much as a developer might, but enough that you can own your own company's guidelines. For REST APIs anyway, there isn't any universal standard, unfortunately I guess, but it kind of means that every company needs to decide on their own guidelines, and really the platform product manager needs to be the person owning that. And I own the API standards at LSEG.

[00:12:30] And I guess the other thing is, you need to be able to work with designers and other people around user experience. It seems more obvious to people around the API portal side of things, that needs to be a well-designed experience, especially for developers, but as I said for other people too. But then there's also the internal one, which even people in the API world haven't really been focusing on much, and that's the API provider experience, and them being able to manage the API life cycle as a product person.

[00:13:16] I won't get too much into API gateways because that gets a bit technical, but it's something that, certainly prior to my current role, I didn't really know much about, API gateways. But it is very central to being an API platform product manager, and even as a provider you need to know that. Especially commercial APIs really need to be going through an API gateway, and they basically form your platform. So they'll themselves integrate with other services such as authentication, in order to make it so that every API that gets onboarded doesn't have to worry about that, doesn't have to worry about things like rate limiting, which is a kind of security mechanism that means that people can only request the API so many times in a certain period of time. And I think the other thing is, well, the reason you need to know about this as a product person is that you're the one that ends up making the decision about which API gateway or API management tool that you'll end up using. Well, hopefully you get to choose.

The developer experience and the portal

[00:14:48] So as I was touching on there, there is a bit of a user experience part to the API product role. You have the external developer experience, so that's the API portal. But beyond that, as part of that you need to factor in more business oriented people who are going to make the decision whether to buy the APIs or not that you provide. And therefore part of that is being able to find the relevant APIs, so you need to think about that, and that would probably form one of your main decision areas around the portal.

[00:15:40] You probably would want something like a forum, and that often doesn't come out of the box. Sandbox: how's that going to work? In terms of, for us at LSEG most of our APIs are data, as I've said, data focused. Therefore sandbox is usually, what data do you want people to be able to use without signing up to APIs? Or for Modulr it was more functional, so how do you mock the functionality of APIs, and then how do you get people to be able to register for that experience, what do you think they need to provide to you? And then there's the whole experience, as I said, for the API providers, and we'll talk more about that.

[00:16:39] I think one of the things I've found is that there's lots of basic API portal solutions out there, especially if you have some sort of API management solution. Microsoft just confuse people by calling their API management solution APIM, which is what the acronym for API management solution is. Anyway, so whether it be Microsoft or Google or Amazon or Kong, or all these different flavors of solutions for APIs, most of them only come with a very basic portal, and you'll either have to get a third party in to provide you with a better one, or you'll need to build something yourself. You'll at least need to brand it.

[00:17:48] So for one thing for me, I guess going back to the LSEG thing, how does the portal handle the data focused APIs? And then, how do you automate the process to deploy an API, if you're deploying an API to the gateway, which is how the developers integrate with your APIs? You really want the documentation to come up into your API portal automatically as part of their deployment process, so you need to design all that.

Onboarding an API

[00:18:24] Now here's the more interesting bit, for me at least. The API provider UI is something that doesn't exist, you have to build it. And I think the next slide is more, yes, this is something I can talk through for quite some time if you let me. It's, I guess, the onboarding process for an API, and something people don't tend to think about too much. Ideally you'd want the API providers to tell you about the fact that they're going to onboard their API, so hence register. Then you'd want really them and their team to be designing the API first before they build anything. Doesn't seem to happen much. And part of that is writing the technical documentation for the APIs.

[00:19:25] And really what you want to do is make sure that that's all good and is good in terms of comparing to what you've put in your guidelines and standards, before they deploy it anywhere. The way we do it, we have a pre-production environment that they deploy to at that point, and then they do other gates. Now this shouldn't be seen as something that's like one after the other, waterfall. This is all, except for the design and deploying it to PPE, everything, actually you could start the other ones even before that, because there's gate owners who need to know about these things.

[00:20:13] And eventually, this is really talking about commercial APIs again, so I'm very focused on commercial APIs and getting them out there. The big thing about APIs is that once they're out there, your customers need to integrate with them, and so they need developers to do that work. And what you don't really want to do is have to get them to have a breaking integration and be versioning APIs all the time. So what you really want to make sure is that you've got something out there that's going to stay out there for a while, usually a couple of years or so. So a lot less iterations than would be normal in an application world. So hence an API needs to be a little bit more waterfall, a little bit less agile, in terms of a commercial API. And part of that is your teams being ready to support that API, and for all the documentation for the customers to be ready as well.

The future of API product management

[00:21:38] So for me, the future of API product management basically is that more people will become API product managers, and more people are aware of APIs as a thing, as a product, as something that they can own as a product manager.

[00:22:00] And I think I've got a little bit of time. So, API integration is becoming automated. Now this would be a huge change to the whole API world. I don't quite understand why it hasn't really happened yet at all. Essentially if you take the whole manual integration piece out of it, then you can have more agile iterations of APIs, not need to worry about that whole change management process so much. But then you've got to focus more on, how does the automation, so the bot or whatever it is that's actually doing the integration, what happens before that in terms of deciding on the API and then buying the API? And how does somebody buy an API if they're not doing it manually, if that's all automated? So there's a whole lot of stuff to think about there.

[00:23:14] Yeah, I think that's about it. Yes, so thank you very much. I thought I was going to go over time but it looks like I'm a little bit under, which is always good. So, I've only got my email address here, but I'm also on LinkedIn if anybody wants to connect up there. I'm very happy to talk about APIs at any point.

Q&A

[00:23:46] Gareth: You're on mute I believe, Katherine. There we go.

[00:23:54] Katherine: You'd think I'd be used to it by now. So there are a few questions, if that's okay. How do you gather and incorporate feedback from developers during that planning phase?

[00:24:13] Gareth: Developers and stakeholders during that planning of the API, in terms of designing an API?

[00:24:22] Katherine: Yeah, yeah.

[00:24:26] Gareth: So I guess what we get people to do, well, for a start off, they kind of explain what they're trying to do with an API, what their API is about. And then we give them some documentation around the guidelines and things, and then they go away. There's something called OpenAPI, which is a standard way of formatting APIs, and they come back with a first iteration of what they think their API is going to look like, and then we give feedback on that. Yeah, so I have an API Center of Excellence team, and so I used to do all that myself but now I actually have a team who does that on my behalf.

[00:25:23] Katherine: Yeah, could you maybe talk through your team structure? That would be very interesting.

[00:25:25] Gareth: Oh yeah, sure. So I have a development team. It works purely on, well, mostly on the actual gateway itself and the things around that. So there's a few, they're mostly backend developers. We use Kong, so mostly Go developers and things like that for plugins. And actually they're very DevOps heavy as well, so they need to work with infrastructure quite a bit. So we don't have a separate DevOps team or anything. I also work with a designer, and a BA helps out as well. It's kind of a PO really, she kind of has that role. And then there's the Center of Excellence team, so there's a couple of architects who specialize in API design.

[00:26:27] Katherine: And is there an architect across the whole thing in terms of API strategy?

[00:26:34] Gareth: Yeah, so that's, think about it. Oh, and I guess we have a technical program manager to help me make sure that I'm staying on schedule.

[00:26:47] Katherine: And how do you manage and incorporate that feedback into feature requests?

[00:26:56] Gareth: So I guess what we're talking about then is more the external developer. Well, actually no, it's not. Most of our feedback comes from more product manager level, in terms of functionality of the gateway and what they want to see or how they want to be able to, especially things like rate limiting and specific things that they need around that. So there's all sorts of things. We also have things like private link and all that kind of stuff, so that was when we were at AWS. So yeah, it really comes in from those product managers who are close to their customers, and their customers have maybe said something, or they've noticed that there's certain usage patterns or something or some issues, and they'll feed that back to us. And what we used to do is they used to pay for the enhancements, but I think we're doing most of it these days.

[00:28:08] Katherine: Nice. And last question, what emerging trends do you see in API development and management?

[00:28:18] Gareth: AI is the big thing I guess. In terms of especially finding APIs and things like that, what we're going to have on our new API portal, which we're putting together at the moment with a third party, is a search based on ChatGPT. So it'll be a lot easier for people to find the APIs, and not only that, but they'll automatically generate all the instructions of how to integrate with that particular API.

[00:28:58] Katherine: Yeah, no, fantastic. Thank you, thank you very much for that and for the talk, really really appreciate it. Your session will be available on the website as of next week for everybody to tune in again. So thank you very much, guys.