APIs Over IPAs 19: API Product Management with Emmanuel Paraskakis, Level 250
In this episode, Emmanuel Paraskakis, CEO Level 250 breaks down the core responsibilities of an API product manager. Speaking from his experience in product management for over fifteen years, Emmanuel distinguishes an API product manager’s focus from conventional product roles, underscoring their critical importance in building scalable digital platforms.
An API product manager requires a unique blend of technical awareness and customer-centric strategy. Emmanuel illuminates the nuanced challenges API product managers face, including the imperative to understand and cater to two distinct user tiers: the developers who directly interact with the APIs and their end-users. He covers the crucial aspects of balancing internal and external stakeholder needs and pinpoints the common pitfalls that impedes aspiring API PM leaders. The discussion also uncovers essential metrics for gauging API product success and offers a forward-looking perspective on the transformative impact of generative AI on API development and consumption.
You can watch the podcast on our YouTube channel.
Table of Contents
- Introduction and Background
- Defining API Product Management
- Essential Skills and Common Misconceptions
- The Dual Customer Persona in API Products
- Balancing Internal and External Stakeholder Needs
- Common Pitfalls for Aspiring API PM Leaders
- Resources for Staying Updated in the API Ecosystem
- Key Metrics for API Product Success
- Aligning API Metrics with Business Outcomes and Leadership
- Exploring API Business Models and Monetization Strategies
- GenAI: Impact and Essential Strategies for API Product Managers
- Final Takeaways
Introduction and Background
Derric: Hi, folks! Welcome to another episode of APIs Over IPAs. Joining us today is Emmanuel Paraskakis from Level 250. We’d love to hear a little bit about yourself first, Emmanuel.
Emmanuel: Yeah. Hi, everyone. My name is Emmanuel, and I’m an API product manager. I have been one for more than 15 years, either building APIs for various companies or building API tools, API design tools, documentation tools, testing tools, and so on. And these days I consult around API product management, and I also teach API product managers on Maven.
Defining API Product Management
Derric: Awesome, super happy to have you here today! Just to kick things off, what is an API product manager, and how is it different than traditional product management?
Emmanuel: Yeah, I guess API product management is not that different. I think the difference is in having an actual product manager for APIs. That didn’t used to be the case a while ago, because we thought of APIs as more technical types of artifacts that were byproducts of our engineering process. And as we found success with APIs as an industry, we discovered that we need to be more intentional about building our APIs, and sometimes we were able to productize APIs and monetize them and sell them with great success, as we’ve seen in many examples that are out there.
Essential Skills and Common Misconceptions
Derric: And what are some misconceptions you see different companies have as they’re bringing on product managers? And are there any specific skills that are required that are different from typical product management?
Emmanuel: Yeah I would say the API product manager has to be necessarily more technical than other product managers, because the subject matter is more technical, and their users are going to be technical people. They’re going to be developers, they’re going to be engineers, DevOps, and so on. So API product managers, and as the platform product managers, have to be able to speak their language, and they have to be able to address their needs. So there is some element of technical capability that’s there. And that’s why a lot of the really good API product managers are former engineers, though not all of them.
The Dual Customer Persona in API Products
Derric: And you speak sometimes on this idea of two product managers at the same time, or two customer personas at the same time. What does that mean?
Emmanuel: Yeah, this became apparent to me a while ago, where traditional product management looks at the use cases of their direct users. You can go look at your product analytics and figure out what people are doing with your product, or you can go talk to them, talk to the users, talk to the customers, and find out exactly what they’re doing. But with APIs, as with most developer-facing products, we build our products for others to also build experiences with them. So as an API or platform product manager, I have to be aware of both levels. I have to be aware of how my direct users are going to employ my product, what problems they’re going to solve, but also what their users are going to solve and what use cases are interesting to them. And I think that opens up a whole world for API product managers where they essentially have to be twice the product manager, if you will, and anticipate a little bit the use cases of their users’ users, because if they don’t, they will only create a limited set of options of APIs.
Balancing Internal and External Stakeholder Needs
Derric: That’s a really interesting point. And you know, sometimes we see APIs are used both externally but also used internally as well, even as products. And so, you know, as an API product manager, how do you balance the needs and requirements of these different stakeholders—external, internal—and making sure, you know, all of them are met?
Emmanuel: Yeah, I would say, first off, try to treat internal platform and API products pretty much the same as external ones, because, especially in larger organizations, well, your users deserve good experiences internally as well, not just the external users. So if you want adoption, if you want success of your product, even treat internal products the same. Do customer discovery, measure the outcomes, make your products intentionally, do good design, and so on. So in that sense, there’s not that much difference. Of course, with internal audiences, we’re liable to know them a little bit better, be able to reach them a little bit more easily. So that’s a little bit of a difference there, but the techniques and the goals should not change.
Common Pitfalls for Aspiring API PM Leaders
Derric: Makes sense. And you know, as someone who is now looking to become a better API product manager, maybe they already have a role and they’re aspiring to be in a leadership position, what are some of the common pitfalls that you see for these folks who are trying to go for those positions?
Emmanuel: Yeah. A lot of times, we talked about API product managers being former engineers, and a lot of former engineers, when they transition into the product role, they kind of tend to regress back to engineering, if I may put it that way, in the sense that they will try to specify solutions rather than speaking about the why and about the problem, and speaking about what their customers want. So that’s one really big pitfall. We kind of tend to go back and say, “Oh, well, you know, here’s the architecture that you should use,” because as a former engineer, I know exactly what I’m talking about, and that really shouldn’t be the case. The other case, kind of on the other side of the spectrum, is not being technical enough and not keeping up with the latest technology. And so that’s something that you should do. You should get educated about what’s happening with APIs, what’s happening with techniques around APIs, new processes, new tooling, and so on. So definitely keep that up.
Resources for Staying Updated in the API Ecosystem
Derric: That’s a really interesting point, that as engineers or former engineers, we get tunnel vision and, you know, forget about the different use cases or even technologies out there. And what are some resources that you go to to keep, you know, up to date on the API ecosystem and, you know, latest developments in product management?
Emmanuel: Yeah, I try to, first of all, follow—I have about a dozen people that I follow and read religiously. They have amazing newsletters, and most of them are people that you know and have brought on to your podcast, so they won’t be new to your listeners. You had Mike Amundsen last time. Mike’s a great resource. So there are folks that I read almost religiously, I should say. Also, pretty much the same cohort of folks have written books around APIs, and those are a great resource. And definitely keep going to events—sometimes conferences, sometimes even your local meetups. And I have to say that here in San Francisco, we’re very lucky to have amazing events that happen pretty much daily, and if you’re in a major city, try to go to those technical events. That’s probably the number one source of new know-how for me.
Key Metrics for API Product Success
Derric: Definitely, and glad to have Mike on. We just talked about customer observability, so he’s very timely as we’re, you know, talking about API product management. But what are some metrics and, you know, ways to track these metrics, you know, for a product manager?
Emmanuel: Yeah, I mean, look, all the usual technical metrics apply because the technical metrics translate into experience for users. So if you’re thinking about uptime or if you’re thinking about latency, keep measuring those and keep tracking those, because that will translate—improving those metrics will translate to a better experience for your users. But I think there’s also a couple of other categories of metrics, and one very important one is how you instrument your, let’s call it, a funnel, a marketing funnel, but for developers, for developer experience. When people reach our developer portals, they usually don’t know what to expect. They are trying to find out what capabilities we have with our products, if those products are suitable for them, and if they can use them easily. So, don’t expect everybody that comes to your developer portal to immediately adopt your APIs. There’s going to be people that are not interested or that don’t understand your product. And then there’s going to be a percentage of people that sign up to explore your product. And out of those people, there’s going to be the people that are successful with your product. They make, you know, that one first API call that we talk about. And then they might make, you know, more API calls because they are now imagining what they can do with your products. They are now exploring use cases, and they might, you know, find success. And you could measure that by tracking the number of API calls they do. And out of those people, some will actually sign up as a paid or as a higher tier user. So all of those stages are stages that you should instrument and track and understand. And of course, to find success with your product, you have to improve those metrics, all those conversions from one gate to another. And that’s really, really important. And I do believe that sometimes, just because it’s a developer product or a technical product, we don’t do a good job of tracking those metrics.
Derric: Definitely getting to that first API call and helping a developer, you know, to really get to production, or at least build something of interest, is, you know, of course, that’s what we’re all after. You know, outside of just getting to that first API call, what are some more, you know, both quantitative and also qualitative metrics, you know, that you think of when we talk about like developer experience and adoption?
Emmanuel: Yeah, and especially for product managers, there are things that will be interesting, like the adoption of a particular feature. Let’s say you release a new API, and you want to see if people use it. You should be instrumenting and tracking that. And kind of the reverse of that is, hey, we just put out a new version of an API because we decided we want to do away with all the old stuff—that happens over time. When is it safe to take away the older APIs? Is anybody still using them? Is anybody transitioning to the new version? So those are things we need to keep track of as product managers. And then, of course, you have all of the, let’s call them, sales or marketing metrics that have to do with either adoption, or maybe I want to find out, you know, who my top users are, who are the top users that are exceeding, let’s say, their rate limits, which means that we might be able to offer them a better plan.
Derric: And so I guess, as you’re digging into this data, how do you balance, you know, between, okay, for the developer needs and customer needs versus sales, right? Because we also don’t want to force them into, you know, upgrading too quickly or into a sales cycle. Is there anything that a product manager can do to balance different stakeholder needs?
Emmanuel: Yeah, and you know, it depends on whether your organization is taking a PLG approach, or if you’re a small organization or a larger organization, we can dig into those. But typically, what happens is you may want to instrument for marketing and sales data more in your, let’s say, sandbox environment—the environment that people or developers play in before purchasing or before becoming paid users. So those are things that are very tactical, and your sales and marketing should be looking at—who, you know, who signed up but is not making API calls, or who signed up and is making a lot of API calls; they must be very interested, let’s go talk to them. And especially if you’re doing product-led growth, those are things that you should be monitoring throughout that cycle. Now, in your production environment for your customers, that’s data that’s more for either, let’s say, product managers, where they want to know how the product is being used. Are people being successful? Are they finding difficulty with the product? Or perhaps, if you’re a larger organization, you might have customer success, and they care about the renewal or the adoption of a particular customer, and there you should offer them more of the metrics in the production environment. Not that sales are not that interested in what people are doing in production, but typically, especially in larger organizations, that moves off towards the customer success function.
Aligning API Metrics with Business Outcomes and Leadership
Derric: That’s an interesting point in that, you know, nowadays people are looking at APIs way before and doing their investigation before they even talk to sales, right? And so there’s a lot of steps that now need to be tracked. But at the same time, we also hear this idea of outcomes, and making sure that we’re aligned to outcomes from a business standpoint. Am I just trying to, you know, get the highest request per second, or is there something else that I should be measuring when I think about the success of an API or success?
Emmanuel: I’m glad you bring up outcomes because that kind of ties very closely with the value of our product, and the value of our product is not just the technical aspect of it. Oh, I was able to make an API call. Oh, I was able to, you know, move this much data from one place to another. That’s not particularly interesting per se. But the value is what we get out of it. And if you think about products that are truly API as a product, let’s say, for example—I mean, the classical example is Stripe—the outcome there, and the value is very clear. If you’re successful, you’re selling more, then Stripe is also successful because they’re taking a cut of the revenue. So the outcome there is very, very clear. And I think that’s part of the reason why Stripe has been very successful with APIs. They’ve been able to clarify that, and they’ve been able to find that use case where the outcome is so aligned with that of their users that the value is super clear to everybody. And I think those two are related.
Derric: And so if I’m just getting started, you know, trying to start tracking some of these outcomes and metrics, what should I, as a senior API PM, do to help, you know, convince my leadership team and stakeholders?
Emmanuel: Well, I mean, the first thing is to think about exactly what you’re going to measure, because even with the best measuring tools, you’re not going to get everything out of the box. You have to actually instrument it where you’re going to be measuring, and also what outcomes you’re going to be measuring. If the outcome is going to be that a sale was made, it has to be clear somewhere in the code—there is something that tags that and then that’s measured in your analytics. So be clear about that. The second thing would be being able to persuade or convince people to adopt your tools and your APIs internally; and to basically invest in your projects as an API product manager would be to make sure that the proposals that you have, the products that you are going to launch, align with the company strategy. And very often that’s not the case, because we kind of have this myopia where we say, “Well, of course, it should be obvious that by doing, you know, API governance, or by having better API design, or by exposing everything that we have as APIs out there for people to do who knows what? Of course, that should be a good idea. Good things will come from that.” But it does cost money to do that, and businesses are constrained about the resources that they have. And I found that if you don’t align with—not just any priority or any business metric that exists, but really the top three priorities of an organization—not much is going to happen. Pretty much anything that’s not top three is just going to fall by the wayside, because we all have a lot to deal with. And usually those initiatives have to do with just a few, a handful of things. It could be, of course, more revenue, it could be more efficiency, it could be compliance with legislation, compliance with new things that are happening, or it could even be a better customer experience. So traditionally, businesses think about these four things, and if you’re not aligning with these four things, and if you’re not aligning with the business’s strategy, you’re not going to get that much done. So you have to find a way to align and improve on those.
Exploring API Business Models and Monetization Strategies
Derric: That’s a really interesting point to take your own metrics and make sure it does roll up into one of those, I guess, four points, or what matters at the business overall. You know, as we’re looking at these APIs, and you know, new folks are trying to productize and expose these APIs, does that mean I should be generating revenue, or what are the different business models that come around these new API programs?
Emmanuel: You know, that’s really interesting. Because even in the case where we don’t directly monetize APIs, like the case of Stripe, or let’s say if I’m Google Maps and I’m selling these billions of API calls at a particular price point—there it’s very easy to attribute that revenue to, you know, here: that many API calls means this much revenue. But in most cases, in a lot of cases—and you know, what could be more of an example than Salesforce—you are creating a better or a more sticky or a more persistent experience for users. You are delivering value that comes from automating things and integrating things that you couldn’t do otherwise, and that has a lot of value. You have to be able to express this value; and I do believe that Salesforce, for example, publishes a number—I’m not too sure exactly what it was—but it’s in the billions of value that they attribute just to their APIs. So don’t think about only directly monetizing APIs. It doesn’t make sense in all cases. If you have data that nobody else has, if you’re able to do something really, really well—let’s say you’re Twilio and you’re able to do phone calls and text messages really, really well—great, then you can, you know, monetize that directly. But if what you’re doing is going to give your customer that much more capability, if they can automate and integrate, then, you know, keep on doing that because that’s going to deliver value.
Derric: That definitely makes sense on attributing value regardless of its dollars and cents or not. You know, if I’m trying to figure out, does it make sense to charge, you know, for this API, or some type of model there, what is the process that a product manager should go through as you’re, you know, trying to figure out that right strategy?
Emmanuel: Yeah, I think it would be trying to categorize a little bit where your API falls. We talked about if I have data or resources that nobody else has, then I am able to put those behind monetization and say, “Here you go, pay me for the outcome that happens.” If I’m able to do things more easily or more efficiently. If I’m SendGrid, for example, and I can send an email really, really well and deliver it actually versus you doing it by yourself and actually not having the email delivered, I can charge for that increase in value. So I would say, try to categorize what the benefit is that you bring to the table. And if your data is generic, well, then you’re not bringing that much benefit. And sometimes we—it turns out we don’t charge for that data, like for example, there’s an API for the U.S. Government to distribute weather. Well, they don’t—obviously they have some data that nobody else has, but I don’t think they’re going to charge for that, because it’s not only a public good, but it gives the ability for others to build on top of that. So that’s another way where it might be a good idea to charge for the data, but you might explicitly decide not to—not to do that. But I would say, categorize what the value is that you bring, and see if you’re able to express it in a way that you can monetize.
GenAI: Impact and Essential Strategies for API Product Managers
Derric: That’s a really interesting point around categorizing the value, and also, is it more of an ecosystem play? Is it direct for revenue play? And there’s a lot of different businesses that can be created through APIs. Revenue is not the only one. Just on the last topic here, you know, everyone keeps talking about Gen AI, and how it’s impacting everyone. So not surprised, I’m gonna bring it up as well. But how is Gen AI impacting API product management, either from tooling or leveraging Gen AI?
Emmanuel: I think there are two different angles to this, and one angle is as product managers, we have to think about the consumption of our APIs by entities or agents that are not going to actually read that documentation, and that we can talk to, and they can ask us questions if they get confused. I think our ability to make APIs usable for agents is going to help us, especially if we’re doing an API as a product. If I’m a data provider, if I’m Google Maps, I want to make sure that all my APIs are suitable to be consumed by agents, because if they’re not, an agent is going to go elsewhere and get the data where it’s easiest, or it’s going to go scrape some website, or it’s just not going to find the data. So I think we’re going to have a proliferation of agents; it appears that way. And those agents are going to need API data, and it’s on us to make that data easier to consume for agents. So there’s a whole conversation happening there. How do we do that? What does it mean to prepare for agent consumption? That’s one thing—so the agent as a new persona, if you will, that’s both a buyer and a consumer of our data and our services. And then, of course, like any other job or any other category, product managers in general are either afraid of or benefiting from AI, depending on who you ask. And the API product managers more so. Why API product managers more so? Well, it turns out API product managers, like everyone in APIs, deals a lot with structured data. And one of these structured data artifacts is an API description such as OpenAPI. Well, it also turns out that LLMs and AI are very helpful at producing these structured artifacts, such as OpenAPI. And where it was very difficult for us to sit there and write an extensive, very descriptive document that does everything accurately, it’s much more easier today to produce it automatically or to produce it through an LLM—I shouldn’t say automatically. And then, of course, we can reuse it everywhere, and we can even reuse it to codes using AI from the OpenAPI or from the API description. We can use it to scaffold API management. We can even use it to create and write our stories and our PRDs and create diagrams for people that are going to implement our API. So there’s a lot we can do. And the benefit is that it takes away the toil and the drudgery of what used to be really boring, templated kind of work. So I think we’re seeing a lot of improvement there.
Derric: That’s a really interesting point about thinking you’re almost like SEO optimization, but for APIs, you gotta optimize for the agent, as it were.
Emmanuel: Call it agent experience—a new term, AX.
Derric: We have developer experience, and now soon we’ll have agent experience, I guess, right? So what should then a product manager be doing today to be prepared for, I guess, this Gen AI world that we’re coming into?
Emmanuel: Yeah, I mean, if you take it from the agent consumption perspective, I think first of all, a lot of the good recommendations and techniques that people advocate for still apply. So you should have a machine-readable version of your API, like an API description document like OpenAPI, that an agent can come and read. You should be able to onboard somebody—an agent or a human—extremely quickly, like instantly. So no waiting for the credentials, no waiting to be approved. I should be able to request credentials and receive them immediately so I can consume my information immediately. Same for making that first API call or the `n`th API call. I should be able to deal very well with spikes. So agent traffic, I think, is going to be very, very spiky. It’s not going to be predictable. You might have a lot of data that you have to distribute in a very short amount of time, and then no data at all, as the agents move on to something else. In fact, there are dedicated tools like, I think, AI gateways that are kind of more API gateways, but for being able to deal with the spiky type of traffic. And then, I would say, be consistent. Follow standards. Make it easy for the LLM or any kind of tool to understand your API. And that’s good advice, you know, even for human developers, and you should be doing that anyway.
Final Takeaways
Derric: Definitely sounds like we already have to be tracking developer experience metrics and how long it gets to generate that key and make an API call. But now it’s beyond, you know, much more accelerated. So getting that type of metrics and tracking and improving is going to be even much more important. Well, thanks a lot, Emmanuel. I really appreciate having you here on the podcast. Any takeaways or items that you want to share with our audience today?
Emmanuel: Yeah, I think definitely, if you don’t have product managers in your API organization, definitely look at that. It’s going to enable you to do a much better job at APIs, and a product manager is going to be able to bring that customer point of view inside the organization. Now, if you don’t have a product manager, chances are somebody’s already doing that, and they might not just have that title. Maybe a lead developer is doing that. So I would say, formalize that and make sure that you do have an API product manager that’s trained to do that, and maybe offload some of those customer conversations to a person whose role is dedicated to that. The problem with not having that role is that you might have some myopia, and you know—have only kind of built products looking internally. And there, there’s a risk that your products might not find success in the market, even though you did all the work and spent all the resources. So I would say, look at some API product management as a thing even for internal APIs, not just external APIs.
Derric: Important piece. Make sure if you’re gonna treat it as a product, make sure you truly treat it as a product, not halfway there. Otherwise, you just cause a lot of commotion between the different engineers
Emmanuel: 100%, yeah.
Derric: Well, thank you very much, and have a good day.
Emmanuel: Yeah.
Related Articles
API Development
Using Moesif for API Observability and Analytics in NGINX One
Enable API observability in NGINX One with Moesif to track latency, errors, and usage patterns through powerful API analytics and user-aware monitoring.
API Strategy
How Engineering Teams Should Monitor Customer Health and API Usage
Learn how engineering teams can monitor API usage, debug production issues, and track account health with Moesif for better API observability.
API Development
Moesif for API Observability and Analytics in NGINX OpenResty
Set up API observability in NGINX OpenResty with Moesif to track performance, monitor errors, and gain real-time insights into your API traffic and users.
API Strategy
Usage-Based vs. Outcome-Based Pricing for APIs
Learn how outcome-based pricing compares to usage-based models, and how to track API value with Moesif for better revenue and customer alignment.