From Vision to Venture 04: Kin Lane - API Evangelist

Well, welcome Kin. Really great to have you here, you know, from the API Evangelist. Today we’re going to be speaking on how to best productize and monetize APIs, especially in large enterprise settings. Just jumping into things, what does it mean to productize and monetize APIs, and why is it growing traction within enterprise environments?

Well, I mean, folks, you’ve got to justify your spend. I mean, first and foremost, APIs cost money. I think the last research bit I did, you know, it costs 50 grand to stand up an API and sustain it and maintain it. You’re spending money. And then secondarily, we all need to make money. So you’ve got to be able to say, all right, what resources are we making available here? And how are we going to not give away the farm, especially in an AI world, and just give away all of our digital resources? I think that’s one of the biggest misconceptions people have about public or, you know, externally available HTTP APIs — they’re going to give away something. And so that monetization is really just about getting a handle on your digital resources and understanding, you know, how they’re being applied.

Makes sense. And definitely, you know, as we’re looking at the cost of deploying those APIs and standing those up, has anything changed? You know, APIs have been around since, you know, back in the enterprise service bus and the like. But why is it such a topic now?

Yeah. You know, interestingly, my Amazon bill has gone up. It has not gone down since 2010. I’ve been running APIs ever since. You know, the shift — I mean, and I’m clearly not an enterprise operations, but just, you know, relating it here — is, you know, with regular instances and VMs to a more containerized and/or serverless approach. I kind of leaned heavily into the serverless, but I’m coming back to a kind of common, more basic virtualization, because my resource management and what I’m having to do hasn’t changed a lot, to be honest, and my bill has gotten worse. So, you know, I’m really trying to figure out how to get back to basics, and I know a lot of enterprises that I work with, they’re, you know, questioning some of the more spendier parts of their rollouts that they’ve done around other types of APIs — GraphQL, Kafka, other things that may not have achieved exactly what they needed — and then the sprawl, the API sprawl, and figuring out, you know, how are we going to pay for all this and how we’re going to make money here. So not a lot has changed. It’s gotten more expensive and more complicated and more sprawling, but I wouldn’t say the technical bits have really changed all that much.

So, sounds like driving a lot of efficiency, trying to get more out of those investments into these API programs, right?

Yeah. Yeah. I mean, think of FinOps, you know, and how that’s kind of spun up as far as financial — you know, understanding your financial operations. So think of that in terms of APIs, from just, you know, what’s our cloud bill, what’s our spend, what does it cost to run these things. But you can’t just pinch pennies and you can’t just, you know, impose austerity on API operations. You’ve got to understand and make sense of that and actually try to figure out, well, what do we have here that’s worth keeping? What digital resources, what capabilities do we have here that are needed, that are useful, and maybe we’re not squeezing as much revenue out of them as we could if we just kind of carved them up in new and interesting ways, or we paid attention to different groups of users in different ways, we looked at things regionally. I just think there’s a lot of ways we can — I mean, my business is helping you survey and assess that sprawling API landscape that you have, but you’re really in the business of, all right, you know, as we’re surveying this, what’s here? What’s valuable? What’s useful? How are people using it currently? And then how do we incrementally maybe start optimizing and generating new revenue from those digital resources?

So sounds like a lot of, you know, analytics and trying to understand, you know, the sprawl and consumption of these different APIs. But from there, then how does someone actually execute on that strategy? You know, what are the key things that you typically see to try and drive efficiency through these, you know, different API programs?

I mean, I’ve talked to quite a few folks. I’ve talked to people in the public sector as well as the private sector, just taking existing APIs — whether they’re REST, whether they’re SOAP, whatever they can — trying to expose them as just simple REST, really focusing there because that’s the cheapest, that’s the easiest, that’s what teams know. But they’re just taking individual resources and assessing, well, who’s using them, getting an awareness of who’s using them, what are they doing with it, and making sure that they have the analytics in place to kind of understand that and observe and see that. And then start really kind of inventorying those digital resources. So each path, you know, you have images or videos or accounts or whatever those slash-digital-resources you have, and then understanding how people are using them. They hopefully have existing customers. If they don’t, deprecate them; they should go away. They’re there. Who’s using them? And then start thinking about, well, you know, how do these work as bundles with other resources? In government, I’m seeing a lot of groups who are like, how do we, you know, join forces with other departments, other agencies? Because we know our resources, we know their resources, different applications spread across those. How do we optimize and build better business models and value exchange at those levels? So really, it’s pretty fundamental. It’s just basic API paths and operations, tagging and organizing those, pulling the data on who’s using them, pulling reports on that to try to understand what’s happening, and then getting all the business and engineering stakeholders together to talk about, all right, what’s next? What’s sensible? Where can we start maybe, you know, changing up our plans a little bit, changing up our rate limits, using fewer resources? I mean, that’s the interesting thing. I know you guys are very, you know — you guys are analytics and very monetization and product focused — but this is an intersection of technical and business. So like rate limits, you know, is a common conversation on the technical side, but rate limits feed into your business plan and your usage and what this costs and what people are paying for. And so you should really understand those technical details, but then put them on the table with the business details, and then have a conversation with the human beings who reflect both sides of that coin as well.

I really like this term value exchange, you know, around these APIs, especially as we, you know, try and drive efficiency through these businesses. Is that the same as monetization, or, you know, when does it make sense to monetize? And if it’s not monetization, you know, what is value exchange?

I mean, that’s all part of that understanding your consumer, and I would say even having a conversation — it’s pretty identical right up to the point where maybe the credit card doesn’t get charged. You know, you’re still metering, measuring, understanding your consumers. You’re still invoicing them and saying, “Hey, here’s how much of this resource you used, Department C, or, you know, West Coast Group, and here’s those resources that we maintain, the ones that cost us 50 grand per resource to stand up, and you’re using them, you know, and let’s have a conversation about that on a regular basis, because you’re a producer and — or I’m a producer, you’re a consumer, and we’re exchanging value.” There’s got to be reciprocity here. So you either got to be paying, you know, or it’s got to be justified that, hey, we’re incurring these costs and you’re using them, and then there’s got to be some other value exchange or something, you know. So a lot of times I’ve come across government agencies — one was in the Department of Commerce, and they said — well, they were talking at a panel. We were doing these kind of roundtable sessions as part of the General Services Administration, and a whole bunch of different agencies came in. So Commerce is up there on the panel, I’m on the panel, we’re talking, and they say, “Well, we’ve got like this API. It’s got like five users, but there’s quite a bit of traffic on it. It’s, you know, a useful resource, but, you know, it’s just never really exploded into the thing we thought it was going to be. And so we’re probably going to figure out how to wind that down, you know, and move on to something else.” And then a hand went up in the audience. The person goes, “Well, you know, I’m with NOAA, the National Oceanic Administration, and we’re one of those users, and you’re totally critical to like six different groups I know who are doing research. And if you shut it down, it’s going to be a real big problem for a bunch of projects we have going on. So can we maybe talk about that?” And so what I see is a lot of things like that happening over and over and over, where groups just don’t talk. These are digital. We don’t have a handle on who’s using it, and we don’t have a plan, a business plan, in place. We don’t have any monetization strategy. It’s just as simple as that.

That’s a really interesting point, where you have an API, it’s used by only a handful or small number of people, but maybe there is a lot of value being, you know, delivered through those APIs, or, you know, one of those users happens to be, you know, one of the largest business units or customers.

Yeah. Yeah. It’s important. And I think there’s a kind of a sickness that creeps in, you know, around scale sometimes — that everything’s got to be big and massive. And unfortunately, a lot of the promise around public APIs was that kind of build it, they will come mentality, where, you know, you put out a pretty basic resource that costs you $50,000 to stand up, but it’s useful to 15 people who, you know, will pay anywhere from a thousand to two thousand a month for those resources or something, you know, and then maybe you can crack that open, find some new interesting ones. You know, there’s a lot of opportunities there without going big. You know, not everything’s got to be big, and there’s a lot of value in the cracks.

And we’re starting to see that as well, you know, starting smaller with a smaller group of design partners to help really iterate quickly on that API strategy, versus a big marketing launch and the days of 2021 and spending lots of money on that type of stuff. You know, these days it is much more important to drive efficiency even through these new initiatives. But, you know, as someone who’s, you know, setting up a new API and trying to externalize that, you know, what are some of the key challenges that you see? And, you know, what are folks doing today to address that versus even a couple years ago?

Well, I mean, I don’t want to be a downer on it, but I’m seeing a lot of people kind of closing up and tightening up their portals, because there was already a lot of fear. I remember Pinterest, when Pinterest first was kind of talking to people on the forum about launching an API, they’re like, “Oh, we want to do this thoughtfully. We don’t want to make the same mistakes as Twitter.” So this is like, what, 2017 or 18 — I forget when they launched. So there’s always been a lot of anxiety around public APIs and how do you launch it, how do you support it, how do you do it right. But look at like Twitter and Reddit and anybody else who’s got a valuable resource right now — what’s happened to it because of kind of the appetite around AI consumption. It’s kind of, you know, scary to have your valuable resource out there, even if you do have a portal and a login and keys and analytics in place. But you’ve got to have a pretty tight business plan and plan on the front end of that. And I’m not just saying like well thought out initially — like, you need to be well down this road and have some experience and be playing around with what works and doesn’t work, and building up the muscles on your team to understand that design of your API, that design of your business plan, know your audience, know your customer, and be able to really iterate before you’re going to have, I think, a solid defensive strategy in an AI era that’s so volatile and so crazy. So honestly, I think more people are worried about having public APIs. But that doesn’t mean they’re going away. They’re just kind of going shadowy and darker, and people are needing, like Moesif, to make sense of this and understand it. So it’s going to kind of go back to, I think, that partner dimension, where it’s like, oh, they’re public APIs, but we only tell you about it if you talk to us and we know you and we trust you. Which just — you know, you still need to keep your public portal, your public strategy. You need to have solid security on the front end of that. But like I said, your security, your rate limits, the technical details give way to the business part — the metrics, the dashboards, the plans, the revenue, the costs, the billing, the invoicing, all of that stuff in there. It’s just as important as security and a DDoS attack. Like, you need a business defense, you know, a business line, a plan. Otherwise it’s going to be too volatile, too crazy out there, to be out there with anything valuable, any resources.

Does this mean maybe, you know, things like developer first and, you know, all the PLG stuff we’ve heard for the last few years — is that, you know, going by the wayside to more of these, I would say, closed, build a relationship with someone? And kind of what does that mean from a go-to-market standpoint? You know, how do you think about go-to-market of an API program or external API?

I don’t think it’s going to go away. I mean, these things don’t just disappear. But it’s going to get much harder. It’s going to get, you know, much more — you know, the winds against it, and the things against you and the things you have to think about are going to be a lot more difficult to do. And so it’s going to be partner, know your customer, you know, KYD, know your developer. Have a firm kind of grasp on that. And a lot of groups don’t really — a lot of large enterprises don’t understand that with a public API portal, like how to do that performance properly, what to put out there, what not to, how to have an access control layer, how to have that set up. So it’s scary. But you still need that transparency and that kind of public access. You know, honestly, it should just be part of your regular public website, in my opinion, and be out there. And it’s just like anything else on your website: what do you put publicly, what do you put behind a paywall, and, you know, how do you monitor its usage and understand its usage and evolve it so that you can, you know, be doing this well? It’s really not any different than your web properties and your mobile properties. It’s just whatever your applications are.

That totally makes sense there. And, you know, speaking on getting analytics and understanding consumption, you know, we’ve been hearing, you know, quite a few folks think around, you know, how AI is impacting that cost. You know, it could be sometimes quite high. You know, you’re building out a new API, and so there’s real costs associated with it that we haven’t really seen before, just to run the API. How is that impacting, you know, these things like monetization and potentially some of these somewhat closed or open API programs? And, you know, where do you see that going, right, especially as now cost is being considered?

Well, AI just got a lot cheaper, I don’t know if you heard. Seriously though, you know, that’s part of that cost management. I mean, you’ve got to understand what it takes to operate these things — you know, what does each API cost to stand up, maintain? What are the direct and indirect costs? You’ve got to have a handle on that, and that’s what the cloud was kind of supposed to promise, I think — to help us kind of slice and dice this a little bit better. I don’t think it’s fully lived up to that. But you’ve got to have that cost side and have real numbers and a real spreadsheet, you know, a real formula for like what’s expensive here, what’s worthwhile doing, and then translate that into the consumption side, you know, and with the right metrics and analytics, service composition, organizing your API resources, understanding your consumers. And you’ve got to do the math on all of that. You’ve got to have a spreadsheet, or, you know, a good solution like Moesif to help you kind of see, you know, build a dashboard and understand it, because it’s going to get tight here. I think a lot of people have spent a lot of money — not just, I don’t want to just point at AI. I think there’s been a lot of spend in a lot of technological areas that people are pulling back on. We’re already seeing companies start having to do more with less. I think there was a lot of promises around labor and employees and being able — you know, what was the Gartner thing? Gartner was saying that, you know, people either need their existing staff to do 10x, or they need to cut their staff 10%. You know, and so how do you translate that into a dashboard and a set of API resources? All right, what are our API resources, and how does our existing staff take that and squeeze 10%, or, you know, 10x more work out of those resources we have — by cleaning house, organizing, better understanding customers, getting some freeloaders off some APIs maybe that were launched at a certain time for a certain thing that doesn’t exist anymore. So just get more efficient about, you know, assessing the API landscape, enterprise and public, and then, you know, figuring out how are we going to make money on this? How are we going to pay for it and do it sensibly?

Makes sense. Does that mean that the role of the API product manager or product owner is changing? You know, especially as, you know, these teams are trying to get more efficient and lean. What does an API product manager do today that, you know, they were not doing five years ago with these APIs?

Honestly, I don’t think it’s going to change a whole lot. I mean, I think, you know, for me AI is just another application of our digital resources. Web had certain constraints, desktop has certain constraints. If you’re doing IoT, if you’re doing mobile — if you rode the last bot wave, that was like 2016. If you got on any of the iPaaS kind of integration platforms — there’s been a lot of different waves. There was, you know, an AI wave around 2012, 13 — Wolfram Alpha and IBM Watson — and, you know, it wasn’t as big as this moment we’re in right now. This is, you know, massive. But, you know, there’s all these waves, and you’ve got to assess, like, what are the applications of my digital resources? What new digital resources are we going to invest in? Which ones need to go away? And you run it like any other supply chain and factory and warehouse and distribution channels — figure out what’s making you money and what’s not. And I think hopefully the smoke and mirrors from AI kind of fall down, go down a little bit, and people can kind of get a little bit more honest about the math of what all this costs and start figuring out where the actual value is.

Makes sense there. We’re definitely seeing a lot of, you know, innovation, especially with the AI stuff, but, you know, it’s hard to also, you know, parse through what is next. You know, we’ve been hearing about AI gateways and trying to understand AI as a product, or AI products, just like we saw with the API wave. But what do you see coming next with, you know, APIs and how AI is impacting that?

So here’s my stance as API Evangelist: nothing. I don’t care, like, AI anything. I’m sticking to the fundamentals. And starting next week, like Tuesday at 1:00, I’m going to have a basic fundamentals of schema workshop. They’re paid. And here’s basics of schema. 2 o’clock is basics of APIs, OpenAPI — what are the different types of APIs, a lot of what we just talked about. 3:00 is operations — what should you have? You should have a portal. You should have documentation. You should have an OpenAPI for these. So that’s Tuesday: three fundamentals that I feel like are really missing. People just don’t know their schema. They don’t know OpenAPI. And they don’t know their operations and have a consistent operational definition. Now Wednesday — or Thursday, excuse me — is going to be governance of that that we just talked about. So Spectral rules, and how do you lint that? And then 2:00 is going to be changes, where you just deal with changes — change management, versioning, how do you, you know, source control, how do you have a source of truth. And then 3:00 is going to be evangelism — how do you talk to people about this, how do you engage stakeholders, how do you have a conversation. And so three — six fundamentals that are rampant across every enterprise. Nothing’s changed. It’s HTTP. I’m not even talking GraphQL. I’m not going to talk Kafka. I’m not going to talk any of that. Your applications, how you apply your digital resources, are up to you. Web, mobile, desktop, AI — you know, I’ll talk to you about those nuances and how that impacts, but really, outside of that. And then once this is stood up, Wednesdays are going to be where I start diving into other fundamentals. So monetization is going to be one of the 1:00s, where it’s just basic service composition, basic analytics, basic metrics. And then I’m wavering between HTTP, pagination, rate limiting, and a couple other fundamentals, and I’ll probably rotate between those on Wednesdays. It’ll be the kind of looser day. I’m not going to talk to you about anything that’s outlandish, out crazy, because those are the same topics I’ve been talking about since 2010. And that basic monetization piece — like, very little’s changed. Very little’s gotten better. We’ve gotten better tools and better services and better approaches, but really the need and the challenges have remained consistent, and I don’t see them going away at all. So I’m going to just stay true to the course, stick to the fundamentals, and then I’ll let y’all, you know, everybody else, worry about the application of those resources. I’ll just help you kind of, you know, think about those essentials.

Totally agree. And, you know, definitely staying close to fundamentals, ensuring meeting customer needs, is still more important than chasing the next shiny object. And we’ve seen so many waves where APIs impact everything, from crypto and, you know, other waves as well. So at the end of the day, it’s about good API design and API governance, right?

Yeah, just the basics. And I’m going to do that for a few years. And I mean, I think that’s why what you guys offer is so important, because the value exchange piece, yes, the monetization piece — the analysis, the analytics of that API landscape is critical, is essential. It’s not rocket science, but you’ve got to do it. And you’ve got to do it consistently over time before you’re going to get better at it.

Appreciate having you here, Kin, for our podcast. Any parting thoughts you want to leave with the audience?

I mean, just, you know, figure out, you know, what do you do as an enterprise, and really kind of hang on to that in this moment. I think things feel like they’re moving faster than they ever have before. They’re volatile. They’re crazy. That’s not true. That’s just fabricated, manufactured. Stick to what you do best, understand that, understand your customers, and figure out the best ways you can kind of iterate and work on that. The rest, you know, will work itself out. It’ll kind of calm down a little bit here until whatever’s next, you know. And if you just have your kind of API strategy together, you’re going to be able to weather this stuff, and you’re going to be able to make money, and you’re going to be able to adjust over time.

Welcome. Well, really appreciate you being here, Kin, and until next time.

All right. Thanks.