Software at Scale - Software at Scale 51 - Usage based Pricing with Puneet Gupta

Episode Date: October 13, 2022

Puneet Gupta is the co-founder and CEO of Amberflo, a cloud metering and usage based pricing platform.Apple Podcasts | Spotify | Google PodcastsIn this episode, we discuss Puneet’s fascinating background early at AWS as a GM and his early experience at Oracle Cloud. We initially discuss why AWS shipped S3 as its first product before any other services. After, we go over the cultural differences between AWS and Oracle, and how usage based pricing and sales tied into the organization’s culture and efficiency.Our episode covers all the different ways organizations align themselves better when pricing is directly tied to the usage metrics of customers. We discuss how SaaS subscription models are simply reworking of traditional software licenses, how vendors can dispel fears around overages due to dynamic pricing models, and even why Netflix should be a usage-based-priced service :-)We don’t have a show notes, but I thought it would be interesting to link the initial PR newsletter for S3’s launch, to reflect on how our industry has completely changed over the last few years. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.softwareatscale.dev

Welcome to Software at Scale, a podcast where we discuss the technical stories behind large software applications. I'm your host, Utsav Shah, and thank you for listening. Hey, welcome to another episode of the Software at Scale podcast. Joining us today is Puneet Gupta, the CEO and co-founder of Amberflow, a cloud metering and usage-based pricing platform. Thank you for joining me. Great to be here with you. Good stuff. Thanks for having me. Yeah. So can you tell us a little bit about your background? Like what makes someone decide they want to work on a cloud metering platform? Like what's your story? Yeah, sure. So, you know, I would say, I mean, just background-wise,

a little bit of an old hand at technology. I've been in the technology industry for 20-plus years. And, you know, I actually started life as a developer. First 10 years were hands-on developer back in the day, sort of a full-stack developer. And then off late, you know, last 10 years, just stepped into more of a product management ownership roles. And one of the seminal experience was working at AWS.

A little bit in the early days of AWS, I joined them back in 2011. I was there for about three years, three plus years. So those were some formative years with respect to experience, obviously learning about cloud computing. And as you asked, what got me to where we are today with Amberflow. So that's where the dots connect. A lot of that experience gained at AWS, where my team built a couple of tier one AWS services, one called Amazon Cloud Search, another called Amazon Elasticsearch. So that brings us to the start of Amberflow. Okay. How old was AWS when you started? I feel like it started in 2007, 2008.

Yeah, so relatively still early days. I wasn't there at the very beginning. You're right, started 2006, 2007 when they first launched S3. I joined in 2011. But just to give some perspective, I think we weren't even quite a half a billion dollar ARR business back then. So relatively early days, very hands-on, all the leadership team, very hands-on with technology product, building out new services, exciting time for sure.

Like half a billion ARR is like very, very big for most startups, I think. That is true. But, you know, at the same time, you know, don't forget that even AWS was a single product company at some point, right? It was started from ground zero. So they truly were also a startup, albeit, of course, inside a big company. But they did start from ground zero too.

Yeah. And the first product was EC2, right? Or S3. Yeah, first product was S3. And there's a thesis behind that. It wasn't by accident why storage was the first product and not compute. So to their credit, they had thought it through. Was it just that Amazon needed that first, like Amazon, the retail side?

It's hard for people to manage backups and stuff. That's why S3 is what people will try. And it's also easier to build. Yeah. No, it wasn't actually, wasn't that. In fact, again, you know, to their credit, it was actually really pretty well thought out. So, you know, you have to go back in time, you know, imagine what the world was like in 2006, 2007 technology landscape. I mean, this was not an idea that was considered anything even close to being a viable idea, right, to have compute infrastructure in the cloud.

So, but to their credit, you know, they said that, okay, if we are going to do it, we are not just going to dip our toe in the water, so to speak, and test. We are actually going to put out a full platform that could be meaningful. Somebody could actually do something, build something end-to-end. But of course, even within that, then the question was what to do first and what to do second. But because they had already made up their mind that they were actually going to put out a full platform, not just one aspect, not just one feature. Within that realm, they said, let's get storage out because once somebody had moved their data to the storage service, then it would be a natural extension to offer compute because then they could do something with that data. And it'll be co-located and then they don't have to think

about it. Yeah, that makes sense. Yeah. So data was felt that was a lower bar for people to, you know, because everybody had like archives and all data that was sitting around, lying around. And it was felt that, you know, people would be okay to move some of that into the cloud and just to, you know, see if they could experiment with that data. So that was a well thought out plan

of what to do first and what to do second. And in that realm, they started with storage followed by EC2 computing. And if you have compute without storage, then maybe you can't really do much, especially if you're doing work. Exactly. Because though, as you said, if you don't think from that perspective, a natural inclination would be to just offer servers in the cloud.

But you're exactly right. Just for that reason, even if they were to offer EC2, but if there was no storage tier, what could you really do with compute? Because it would be just sort of ephemeral. Yeah, yeah, yeah. That's interesting. That makes a ton of sense. I also read that you worked at Oracle,

and you kind of helped them with their cloud transition. How was that, especially compared to AWS? Yeah, it was different. The two companies, to be honest with you, I think they couldn't be further apart in terms of just culture and just overall optics, how they look at businesses, how they look at growth. So my story was just a little bit interesting.

You know, I joined Oracle after AWS. And I've been, you know, Bay Area based, San Francisco Bay Area based as you know, Oracle's headquartered here, but AWS is headquartered out of Seattle. So even though I was based here in the Bay Area, I used to go to Seattle pretty much every other week for travel to be there. So Oracle just kind of came about for me. There was, you know, when Oracle got serious about building organically, you know, homegrown cloud infrastructure, as you know, they tried a couple of times through acquisition. And that did not work. And by the way, anybody could have actually told them that, that there weren't any blueprints out there to build public cloud infrastructure that you could buy your way into. So this is something that companies had to build organically. But anyways,

they eventually came around to it. So there was a team that came from AWS already at Oracle that sort of was spearheading that. And there was a couple of things happened at AWS. My manager had left and my option was to then actually relocate to Seattle. And just for family reasons, I could not do that. So the team that started Oracle Cloud Infrastructure, they said, hey, come join us. We've got a mandate from Larry

to build this organically and have a carte blanche autonomy and it would be fun to build something from the ground up. So that was my draw to come join Oracle and do that. Would you say it was worth it in the end? Was it a lot of fun? It was fun for a while. I think initial stages was exciting.

I think as any developer would sort of agree to it, because we had a clean slate to start with, and a little bit to Oracle's credit at the time, like you said, they kind of gave us the mandate and they gave us a carte blanche. They kind of gave us the mandate and they gave us a carte blanche. They kind of left us alone. And so we have, you know, a level of autonomy that you would not otherwise experience at a company like Oracle, right? So that was a fun time. You know, got to work with some good folks, sharp folks, exciting stuff, building things from the ground up.

But at the end of it, a little bit farther into the game, you can't escape the Oracle machinery, so to speak. So yeah, that was that. When you say the cultures were completely pulled apart, maybe if you

can share one example of what would happen at AWS versus what would happen at Oracle. Yeah, you know, actually this is, I can talk on this topic for a long time because it is primarily and specifically that, you know, that really defines the company. And if you look at AWS Amazon in general perhaps

AWS in particular and I think you know obviously a few things that we're going to talk about further into the podcast about the whole usage-based pricing and all of that see it's sort of a all the dots all connect. If you look at AWS, the fact that they were usage-based, the company culture, and within that, how the internal teams operate, how do teams interact with each other inside the company? More importantly, how does the company interact with its customers' prospects? See, it's all connected, right? That whole posture, engagement model, the beginning of the engagement model, the end of that engagement model,

that whole life cycle, it's all a function of, you know, how you conduct business. What is your business model? So right there, they are essentially pulled apart because AWS started with this, as we're going to talk about, usage-based pricing. They don't have you sign long-term contracts up front.

It's pay as you go. You use more, you pay more. You use less, you can dial it back down. There are no commitments. That's been the AWS way. Oracle has been sort of on the other side of that cap, right? And I'm not decrying anybody. It's just that they come from that world.

In the earlier days, that was the model there was. But that has shaped what Oracle's culture is, right? How they engage with customers, what that engagement model looks like. So we can talk more about that, but they are very different. Yeah, so like you can imagine you buy and dine your customer and then they sign a three-year contract

and then you never provide any support. That's the kind of thing I'm imagining. That, yeah. And again, just to, you know, it's not just Oracle. I mean, that kind of was the status quo or is still the status quo in many places. But I can tell you that's changing and that's changing fast. In fact, if you're a company that's still doing that,

let's just say that the customers are becoming smart as they should. And you cannot take customers for granted anymore. Let's dive into usage based pricing right that's kind of what Amberflow does maybe you can talk us through in your own words like why build Amberflow and like what does it really do? Yeah so you know we started Amberflow my co-founder, Leo, and I. He and I work together. He's also from AWS. See, our view is that, so let's take a step back. Business model, right? Usage-based pricing or subscription or the one before that, sort of a term, perpetual, whatever you want to call it. Fact of the matter is that business models don't change very often.

In fact, just for you and me, we've been around for a while. I'd say we've only really maybe seen one change for the longest time when, from the advent of software, it was sort of that traditional model that we just talked about, wine and dine and the term license, perpetual license. And then about 20 years ago, we saw something that's called subscription. And a lot of people attribute that to Salesforce.com. They sort of pioneered it, or I don't know if they pioneered it, but they certainly propagated it or popularized it, right? So it doesn't come about very often, right? Like we said, the last one we saw was subscription, and that's already 20 years old.

So what is these changes don't come about very often, but when they do, they tend to have a long and deep ripple effect. And what I mean by that is, you know, they tend to impact just about everything inside a business. Okay. Now, we can draw a parallel between, okay, did we see something similar in terms of the ripple effect when subscription landed versus are we going to see something similar to when now things are shifting towards usage-based pricing in the billing? And I would say, and the reasons for why we started Amberflow, because our view is that the shift between the very first traditional term perpetual to subscription,

in our mind, was really not that big of a shift. It was essentially at best a step function. If you think about this, and I'll back that up with the following statement, because see when a subscription came, I would say it's one of those things where the concept or the idea was well-intentioned, but it didn't play out that way. The idea was that subscription model, the companies, vendors would have to renew their mandate with their customers every month, subscription. But if you look at what happened, there's hardly any company out there on a subscription model that is usually doing month over month. Almost all of them get you to do a yearly deal, at least 12 months. Some even have you sign a 36-month subscription deal.

So that whole idea of renewing your mandate, the companies have to kind of stay on their toes and continue to earn customer trust month over month, never really happened. In fact, so much so, money gets collected up front because when it's collected up front, there's no incentive to really track anything. So at best, it was just really a step function from the traditional model. Nothing really changed. All it became was just a different way to recognize revenue. So that's what happened.

But even with that, we saw a lot of new technology categories, or at least subcategories emerge. CPQ had to change, configure price flow, document management, contract management, renewal processes, all of that, even though it wasn't that big of a change. Now, when you think about where things are shifting to usage-based pricing and billing, this is a total 180. This is not a step function change in our mind.

And with that said, then you are definitely going to need new technology. The existing infrastructure will not scale if you are looking to shift or to build from the ground up usage-based pricing and billing. And that gave us the confidence. And as you might imagine, this is not just something that we've been dreaming about or thinking about in our head that things are going to change. We've actually seen it. I personally have seen it at AWS. Everything was built from the ground up to cater to delivering, maintaining, supporting, growing

businesses on the backs of a usage-based business model. All functional areas had to be leveled up. Why was that so important? Basically, it's to provide the dream of elasticity. Is that the goal? Or is there something else that I'm missing? No. We could even go back to see, I guess the operative question would be, so what led AWS to do it in the first place? We talked about AWS starting back in 2006, 2007 with storage. Keep in mind, see, now in hindsight, everything looks one foot in front of the other and things have sort of connected the dots. But when they were launching storage, they could have launched storage on a traditional subscription plan, right? One gigabyte, like a Dropbox model, right? One gigabyte, $10 a month, something like that.

But no, they did it on a usage-based model, granular. And the idea was twofold. One, again, it was sort of well thought out, but the whole idea was, okay, we are launching something so new, so different, so disruptive, there are going to be a lot of questions right away, right? People, as is the case, you know, anytime something new comes in,

something that's truly revolutionary, disruptive, you go through this period of, you know, where first there's a denial, right, from the status quo. Oh, what is this? This doesn't even make sense, right? Then there's the next phase of, okay, it makes sense, but it only makes sense for this small audience over there, right? And then there's sort of these, you know, so it kind of goes through these stages before it becomes ever mainstream or fully adopted. So AWS knew that they're going to put this thing out there. There's going to be a lot of questions asked.

Will this even work? What is this thing? So what they wanted to do was eliminate areas of friction throughout that process. And some of it actually was also because, quite frankly, as we just discussed, because they did not have an Oracle legacy, they actually started from a clean slate. You know, they didn't really have a customer-facing software business. So they also quite didn't understand, you know, what the process was sort of like an enterprise sales cycle. There was just nobody in the leadership team who actually knew know knew what yeah like what is an oracle playbook and and good for them right because they didn't

fall in that trap so uh in fact if anything you know their expertise was in supply chain and you know operational efficiency right uh coming from retail margins are razor thin. So that combination gave birth to this concept of usage-based pricing where they said, you know, look, we can't afford to put a sales team right at the front of this whole thing. We don't even know if this thing's going to work, if anybody's going to bite. So what are the things that we can eliminate? And that was the birth of this combination of PLG product-led growth backed by usage-based pricing. And it worked like magic where you look at today, 20 plus years in or close to there,

there's about, and they've never looked back. If anything, they're only doubling down on it. Maybe as a consumer, one thing that scares me is that there know those like horror stories around cloud cost right but i left an ec2 instance running for six months and now i've lost my rent money right like it's those things where there's they there have been now billing caps and stuff that have been introduced but don't you have consumers that are a little worried about, you know, by like small mistakes or extra usage, just leading to like a much bigger cost than I was willing to pay?

Yeah, no, good question. And I think it's, it's the, the optic of what you outlined, the example is a valid example, or, you know, rightfully so that, you know, if by mistake, you left something running, then you, you are, rightfully so, that, you know, if by mistake you left something running, then you are straddled with the bill. Let's see, here's the thing, like, one is, as with anything, you have to imagine that with any kind of a system, an ecosystem, a platform, right, there are some areas of friction points. What I'm trying to say is even when, and I'll date myself, but just as well,

you remember when eBay was launched, the first time marketplaces surfaced on the web. Same thing, same questions are raised. Well, eBay, if I pay, but the other guy doesn't send me the goods, this thing will never work. What I'm getting at is that in any kind of a large-scale ecosystem platform, there are always edge cases. I'm not saying that this is truly a way on edge cases. I know this is something that perhaps a good set of folks encounter. So that is sort of, we have to sort of contextualize it, that it is not the leading use case, right? We do hear these stories, but we perhaps hear them disproportionately so because they get amplified, right? But I think

if you look at it as a percentage of all the people that are benefiting from the cloud, of the ones who get surprised by some resources that sort of went haywire, I think those are fractional, number one. Having said that, that still doesn't exclude the fact that something has to be done about it, right? That this is a problem. So I'm not denying the fact that, yes, there is this use case or edge case where something like this happened. But I would say the second point I would make is, see, the reason that happens, you have to balance these two in the context of the value that the cloud is providing.

So one of the huge, huge value adds for cloud computing, when I'm saying cloud computing, cloud in general, is sort of this autonomous elastic aspect of the cloud, right? So what does that mean? That, you know, you and me can go in and you have an idea, you want to do something either on behalf of your company or for yourself. You have this pool of resources that's available to you, right? You don't need to get somebody's permission. You don't need to go fill out a form and wait two weeks and all of that stuff. So the downside of that is you may forget to turn something off. So because they are giving you that tooling, that leverage, that autonomy, that yes, you can

turn things on, but then it's sort of your responsibility also to turn it off. So it's sort of this, you know what I'm getting at is sort of this sliding scale where AWS could say that, you know, every day you have to come in with stuff and make sure that you check on this box, right? But they're not asking you to do that because that will go counter to the whole elastic nature and the value add nature. There's always this contention, how much leverage they give you flexibility, then on the backs of it, there's the downside of it, it's that you forget something. That's number two. And then number three, I would say is, I think for folks who are experiencing this problem, right? Let's maybe even broaden the statement that you said, okay, rather than, you know, maybe a machine that was left running, you know, this whole domain of cloud cost management, right? My costs are, I'm having some runaway costs, right? I think it's important

to understand the context of cloud cost management is not that customers are complaining that I should not be paying more because I'm using more. I think it's natural thesis that if you use something more, you should be paying more for it. That's just their philosophy of life, right? So the whole space about cloud cost management is the efficiency vector, right? Nobody's saying, in all my time at AWS and then Oracle, you know, today with usage-based pricing,

nobody's come back and say, you know, I want to use more of your service, but I want to pay less than what I'm paying right now. Nobody says that. People will ask for discount, but that's discount on the basis of volume. Hey, look, I want to actually use more. You have a volume discount for me. Okay. And then the question is, okay, now that I'm using so much, does AWS have any best practices, strategies to optimize what I'm using? Can I fine tune it? Right? Can I get additional efficiency out of it?

Can I drive the efficiency curve? So that is a separate conversation, right? That's not the fact that, you know, you can leave something on and forget to turn it off. And more and more tools are coming on the scene where I think if you put in the right infrastructure and you put some discipline and you put some right tooling, I think you can get ahead of it. Yeah. So what I'm hearing is basically there is this decentralization

that this model allows you to do, which is you don't have to go organizationally to my billing team and ask them on my financing can i provision 20 more instances and then they have to modify something in like aws console like the console kind of lets you do that and charges you more and that speeds you up and of course the downside is that sometimes your costs are higher but those kinds of risks control, like those controls on that risk can be done at your side. Like you yourself can install a tool and say, you know what, I'm going to monitor this.

You can also make it easy perhaps to have some kind of guardrail, but since philosophically people agree that you should pay more for, if you're using more of a certain resource, it is still fundamentally like the better approach. And I think that kind of makes sense to me. Perhaps maybe what's challenging to me is that if let's say I'm a startup that does not do usage-based pricing today,

I charge people like 10K, 15K a year for using my service. How easy is it for me to switch over? I don't know if you have companies that have tried doing that. I'm sure you have some customers who are basically going through that model. Because the main issue that I see that now,

it seems like my pricing gets more opaque. Before I knew that my contract said, I'm paying 15K a year. I know I have to fulfill that. I can keep track of that in my budget. How do I, as a company wanting to make that transition, how do I successfully make that transition? Say, you know what, future customers are going to be like usage-based pricing, current customers three years from now, you have to switch over to this new pricing model or two years from now and how do i can retain the confidence of my prospects and my customers yeah yeah fair enough you know yeah good question a lot to unpack there um so let's uh you know let's maybe look at in the context of

um so you talk about okay making the shift right making switch. So if I'm already on, let's say, a traditional model, like a subscription model, and I want to move to a usage-based pricing model, and we have some customers who are doing that. In fact, the majority of the world is going to be in that realm. I mean, we have startups who are looking to start with usage-based pricing and billing, quite frankly, they consider that not just pricing and billing, but actually one of the strategic advantage in whatever domain and category they're playing. They feel coming into that category or field as a startup, leveraging usage-based pricing and billing further adds to their differentiation and disruption. But let's talk about companies who already have an install base to customer base on a subscription model and maybe contemplating thinking about should they? And then if they do, then what does that look like?

So, again, you know, just with the caveat, of course, even within that, it kind of depends, you know, what kind of company, what kind of a domain, all of that. But let's talk about what that would look like. So let's kind of tackle this first thing right off the bat. And this comes up quite a bit. So that, you know, look, in subscription, I have this visibility, right? I sign up the contract up front, and I know what the next 12 months are going to look like. So the reason why that is not going to sustain for very long, see independent of usage-based pricing and billing, let's just, I'll give a point of view

of why that model is under attack. Most of that today is pegged on a user. It's a subscription-based pricing. It's almost always a user-based pricing, X amount of dollars per user per month. Of course, you can get discount. You do the 12 months, 36 months, or whatever. I would put a point forward, and I think I have a feeling most developers particularly will agree because they're getting the first line of sight into this.

See, increasingly, everything is becoming microservices-oriented. And the reason why we are in this renaissance of startups, more and more startups are coming, is because you don't have to build everything yourself. You don't have to build A to Z. And I'm not talking just the technology. I'm talking about the ecosystem of services. I mean, you look at us at Amberflow, right? We provide you a full end-to-end soup to nuts, metering, pricing, rating, billing, invoicing, payments, integration, tax calculation,

integration with, you know, backend NetSuite, QuickBooks, right? Integration in the front end on the Salesforce side. But we didn't build each and every artifact, right? For payments, we use Stripe gateway and others that we're going to have integration with. For tax, we use TaxJar, right? So anybody building anything today as is working in sort of this ecosystem of microservices you know you pick something from here you pick something from there right so if that is what your cause is that's what you're not just the technology aspect right but if you are building a service that has that ecosystem, then obviously there's a dollar that comes in, needs to get divvied out and paid back to these vendors on the backs of which whose services you build your service. So right away, you're sort of in this distribution model.

Somebody has to do a calculation inside your company, especially that, you know, what does this matrix look like? How does a dollar in gets divvied up? And that's why this model of subscription charging per user seat is increasingly under attack because today you can get by by sort of arbitrarily placing your per user price at some high enough number where you know that, you know, okay, my backend is all taken care of, even though I may have to put a dollar here, you know, $5 here. But if I just charge $99 per user per month, I'm I'd be okay. But somebody else is going to come in with a better optimization curve and they can unseat you. So where this trajectory ends,

it ends with whoever has got the best alignment with what's coming in from the front and what's going out the back door. So that is one sort of a way why this model of subscription is I think increasingly going to be under attack. And then of course the way is, okay, how increasingly going to be under attack. And then, of course, the way is, okay, how do you then transition?

What does it look like? How do you, quote-unquote, grandfather existing customers to the new plan? So there's some strategies and frameworks for that too that companies can employ to make that shift somewhat easier. Yeah. Like, I guess, do you think it's a fit for every company, right? Let's take the Netflix example that we were talking about

just before the episode started, right? Would it make sense for someone like Netflix to say something like, we're going to track how much you're viewing Netflix, and based on that, we're going to charge you. So're viewing netflix and based on that we're going to charge you so let's say you have a subscription with us or you have you're paying us on this usage-based plan if you don't use us at all for a month we don't charge you but if you binge watch narcos or whatever show you want to watch you get charged more based on how much time you spent watching things. Does that really work in your opinion? So short answer, it absolutely works.

Let's come back and unpack that. And I'll just want to make one more point to the last point you made. I think I left it a little bit unfinished. See, just back to sort of that point. If we are thinking about making the shift and, you know, subscription versus usage-based, realize and, you know, and you'll do yourself a favor, usage-based pricing, just don't think of it just in terms of pricing and billing.

That would be a mistake, right? When we are having a conversation about this shift from subscription to usage-based pricing, or generally, you know, is usage-based pricing for me or not? Will it work for me or not? You cannot look at it just from the lens of pricing. And, you know, what does my pricing plan look like? Instead of, you know, $99 per user per month, I'm going to break it down based on value-added vectors and things like that. That is certainly, of course, usage-based pricing

and a big aspect of it. But the shift to usage-based pricing has to be looked in the context of your operating playbook. The conversation that you and I had at the start of this podcast, right? Culture. How is AWS different from Oracle? That is really what we are talking about, the shift to usage-based pricing, because pricing is just one component. How then you interact, how you service your customers, how you do cross-sell, up-sell. How do you take care of your customer?

What does customer success look like? How does your sales engage with those customers? At what stage do they engage? What do they engage with, right? That is, you know, when you think about usage-based pricing, it is that ecosystem. And then collectively, our view is that there's nothing that matches the efficiency and the organic growth of that business model. Okay. Yeah, I think that makes sense to me.

I'm trying to frame it in an example where services like AWS, you will get a salesperson or an account manager if you're spending more than X thousand dollars a month. And that's an efficient model rather than having like a customer success manager for every customer, because maybe someone doesn't need you that much and they just need you for something really small. So like these kind of benefits come out of a more efficient pricing model. Right. Is that, is that fair to say, like as an example? For sure. And, you know, like, you know, we used to say, and again, it is no accident, right?

I mean, I know I keep giving, leaning back to the AWS example, but now there are plenty of other stories, right? You look at not just AWS, and just now there's countless. I mean, Snowflake, Databricks, MongoDB, Twilio, Confluent. I mean, the ghost story goes on and on. In fact, every new company that's listing on the stock exchange is on the backs of a usage-based model.

So now there's ample evidence that the new measure of a company's health, a new measure of how do you evaluate a company, the new metric, it's not ARR. In fact, I personally think ARR is dead, or it's going to be soon. The new measure is NRR, net revenue retention, or the net revenue rate, which is basically a measurement of how your customers are renewing your service. Are they coming back for more? So this is all what you just asked. It truly is the more efficient model because you can lower your costs, you can automate a lot of this stuff. But I also, I won't get too far away,

but the point you made about Netflix, I think we should come back to that. Let's talk about that. Is it really the right model for every company? See, I uh answer that question from the following perspective i have no qualms and i would look you straight in the eye and i would tell you that the dominant model so i i you know i won't say every company because you know then of course there's somebody out there for whom maybe it will not make sense.

If your market is the 10 largest banks on the planet, who knows what that business model is, right? So if not for every company, but it is going to be the dominant model. There's just no question about it. It is, at the end of the day, fundamentally better aligned with your customer's needs. It is putting customer at the center of the equation, right? I would argue that the current models are perhaps more skewed or inclined towards the vendor, not the customer, right? Oftentimes, customers left holding the bag. And I get a lot of flack for this, but I'll go ahead and still say it. And I think most people do agree, though.

I'd say that, you know, if not at least one third to one fourth at least of the tech GDP today is shelfware. You're paying for software that you don't use, right? I agree with that.

Right, okay. Well, and then so if we do then you know well let's unpack why that is the case and my contention is well thanks to the subscription model right people have been made to pay or whatever they they've obviously felt okay they were getting a deal they paid money up front based on some amount of users or whatever and i you know as we just agreed that you know people have not realized the value okay so first is subscription cuts through that i mean usage based pricing cuts through that And we just agreed that people have not realized the value. So first is subscription cuts through that.

I mean, usage-based pricing cuts through that. So customer is empowered. Customer has a choice. If I use more, I don't mind paying you more because I'm using you more. But if I don't use more, if I actually use less, then I should have the option to not be held hostage to what we just signed up six months, a year ago that no longer applies. Okay. So that's what, so for that reason, and when I said earlier that, you know, customers are becoming smart as they should, if you are still not on board with the usage-based model, I can guarantee you, your customers are going to start asking for it. Okay. So, so that's sort of my, my general view. Having said that, I'm sure there are certain

industries or some holdouts for which, you for which maybe the model doesn't make sense. We talked about Netflix. I think, let's say, if something is just below a certain minimum threshold of economic value, like today, I live in the U.S. Bay Area. I mean, if it's something like below $5 a month, you know, I don't, you know, it's just below that threshold. It doesn't register. But I think Netflix is not. Netflix is now a little bit above that. And I think it's running into that problem where, as we just saw, you know, last quarter or whenever they announced, right? I mean, there's huge churn of customers.

So some of that is also because of the competitive landscape but i think that's netflix is a fascinating story we should talk about it like i think from understanding your point the idea is that netflix probably would have had less churn when it tried to increase prices if it didn't try to increase prices in a sense right it's like clearly it was shelf life for so many people that rather than paying the two extra dollars a month it was like a perfect reminder for them to turn off that subscription so i think we agree that for a lot of people they were not using it and they're paying the eight bucks a month or ten bucks a month and when you increase it you find out that actually you know i should go

back i've been paying this for like for six months i haven't used it i should turn it off but if you had like a usage based pricing like you wouldn't like turn your subscription off and maybe you would find something on netflix to watch right yeah that is it just think about it right so simple see in in a usage-based world like i'm saying uh subscription is just a bad thing to be honest with you right because subscription means there's a overload thought process that goes in at the beginning of the cycle and then there's a similar process at the end of the cycle where I have to then unsubscribe. And clearly many companies make it difficult to unsubscribe. Like I know companies where you can subscribe online, but to unsubscribe, you actually have to make a phone call.

Okay. So there's a burdensome process at the start and it weighs on customers, right? But that is what I meant that, you know, it is one-sided because there's a reason why they have made it such. So you have to call because they don't want you to unsubscribe because once they know customer acquisition costs in a subscription model or any kind of a model is high, getting the customer through the front door is expensive. What you just said, I think people need to take stock of this. This is really the essence of the usage-based pricing and billing. I'll just paraphrase it slightly differently. Because there is no subscription, there is nobody that is, quote-unquote, unsubscribing. So you never really lose a customer, right?

And that is the problem that Netflix is having, for the example that you just profoundly articulated. Their intention was good. I'm sure they agonized over how much to increase, and I'm sure they came up with a price point that was just barely enough could they had to do but what the what it ended up becoming is it served a reason for you to go back and look at it oh my god i've been paying for this i haven't seen anything on netflix for the last three months as i haven't right yeah i was just canceled i don't want to pay 15 20 bucks a month if i'm not watching it so it had a negative effect now you're losing someone who will be very hard to get back because now you're losing someone who'd be very hard to get back because you know cat costs are obviously very high so now you have to spend more money to

get them back so that is one aspect of it right it also makes you lazy as a product developer because you have all these people who are paying you even though they're not using your product and then you're kind of scared of like introducing a pricing based model precisely because you're getting all this money that you really don't deserve because the customer is not using your product. So if you start with usage-based pricing right from the start, then you know that you only get income when people use your product

that forces you to build a better product. That's right. Exactly. And you can then truly innovate around how can I bring the customer back? Or how can I provide, in the case of Netflix, better content, more varied content? And a lot of this is also for these kind of services is serendipity, right? I mean, I go in and out of Netflix based on what my friends tell me. So I think if Netflix were to just take a sort of a,

this patient approach, not this subscription unsubscribed, right. But if they were to just go on a usage based model, I bet you within a few weeks, maybe a month, two months, three months, a friend is going to tell me, Hey, check this thing out, check that thing out. And that will anyways bring me back to Netflix. And I don't have to think about, Oh, do I have to resubscribe? And then I'm again tied in for X amount of months oh, do I have to resubscribe? Putting my credit card in. Yeah, credit card in, and then I'm again tied in for X amount of months, or then I have to unsubscribe.

So I think this is what companies are realizing, that why usage-based models are better models. And particularly, I think, for these streaming services. I mean, the other angle is this whole ad-supported streaming. I think that is also a flawed model. And I think there's ample data to support that narrative. So that is also a step in the wrong direction, if you ask me. And taking the example to an extreme, right?

Like talking about ads, like Google is very famous for ad-supported free searches. What if Google charged me like, you know, right? Like talking about ads, like Google is very famous for ad supported free searches. What if Google charged me like, you know, a cent or like five cents for every search I made? That sounds like a little bit of a crazy change compared to what it is today. But it does kind of align incentives, in a sense. I guess what I'm what I'm worried about is I don't want to penalize people for using my product more. You know, I want people to kind of search more on my product. I want people to like view more shows on my product.

I don't want them to feel like I'm getting, I have to pay more, but perhaps that's where the philosophical difference is. Maybe it should be normalized that if you're using something more, you should just pay more. And that's just understandable. And since with cloud, that is the culture, nobody expects that I'm going to spin up twice the number of instances

and not pay a single dollar more. So it's really about normalizing the fact that you use more, you pay more, and that should be fine. That should be fine. And I think, like you said, I mean, people really don't have a problem with that because it's just natural, right? I mean, you don't expect to, you know, go into a restaurant and order more food and pay less, right? And it goes everywhere. I mean, if you're selling a service, you would expect the same from

your customers for them to pay you more, right? So when I go somewhere else, I expect this. I mean, that's just the basic norm. So I think that is not a problem. I think people, that's why I say, like, you know, we never had AWS customers that, you know, I want to use 100 more EC2 instances, but I want to pay you less for the 50 that I'm using right now. Nobody, like nobody in their right mind

would have that as a conversation starter. Yes, we will certainly say, hey, look, I'm doubling my usage. I'm going to be doubling my footprint. Can you not charge me twice? Yeah, exactly. Do you have a discount for me, right? Yeah, very fair question.

Because guess what? Every business at some point has economies of scale. So if you're going to use more, then I'm probably having a lower cost structure. And I'm happy to share some of that with you, some of that cost savings. But this thing about, as you said, the search example, right? Okay.

A couple of things. One is, so search is both actually a good and bad example. Bad from the sense that we are so now hardwired to expect it for free to expect it for free and ad support it that we can't even think of anything else though there is a little bit of a silver lining you know you have companies like duck duck go and few others right because of but again you know i don't think they'll be able to really get past a certain realm just because it is so ingrained and and the whole network effect that Google has is so dominant and everything they do is really to protect that.

So that's just the kind of ecosystem. Let's see that at the end of the day, the equation is not even, you know, do you charge me 10 cents or one cent or a fraction of a cent for research? The thing is, you know, what ultimately delivers value to the customers and what keeps them coming back. When you click on a link, when you find something. When you find something. So, so today I would say, you know, for Google, clearly their customer is not you and me, their customers are the advertisers. Let's see, I would, so that is the Google worldview. I'll make an interesting point.

I think your audience will find this interesting. And because I've also worked at Amazon and also at Oracle, not at Google. So Amazon has always had a choice to do Google-type advertisement on their retail website. They've never done it. You're great, right? You don't see like, you know, third party random ads. They give you recommendations. Okay.

But they're not. They don't put random. And they don't pull you out of the site for sure. They keep you in the site. Yeah. True. Actually, let's say it. Let's put it, let's say it even better and more clearly. Amazon does not have a model like Google AdSense where you can go in and buy your placement.

Better keywords and stuff. Yeah. Yeah. Can I do that? Right. Amazon decides whether you're going to show up in the recommended list or not based on the algorithm that they contain. You cannot buy your way.

I can't bid my way into like a better keyword. Okay. That is the big one. Now, they could have always done it. They could have done it Google style and they could have made money hand over fist. See, it is a reflection of, you know, who is ultimately your customer. And Amazon has been clear from day one. The end user is our customer.

They realized that at the end of the day, advertisers would want to go where the customers are. For them, this equation was crystal clear. You can see they have built a thriving business. Google has also built a thriving business. Google has also built a thriving business, right? But if you ask me, okay, if these two are the only companies on the planet, which one would be at the top and which would stay at the top? I think we already know the answer. Amazon is getting ahead.

And one of the ideas that you kind of align your business to serve like the real end customer it's not to kind of create these bidding wars i i see what you're trying to say and like i think it is a big cultural shift but like as as what i'm seeing is that with cloud for example since the first time a cloud business was out there you kind of had usage based pricing and that's just the expectation in that industry it might be a little tricky for companies and other verticals to switch over especially if they have any incumbent who isn't doing usage based pricing but that is the future just because of how efficient it makes things and you're kind

of riding that wave with amber flow which is you're going to enable this infrastructure that supports companies and kind of calculating the usage for their customers and charging them accordingly um what kind of consulting do you provide like let's say that i'm a startup i have no idea i strategically believe that i should do usage-based pricing, but I have no idea. Like, I'm sure I can sign up on your platform. And like, I'm guessing you have a couple of SDKs where you say, you know what?

This is when a user use this. And it's kind of like a metering SDK. What kind of consulting do you provide to me? Like, let's say that I don't know how I should be charging my customers because it's so new. I just strategically think that this is something I should be doing. Very good question. Absolutely. We actually have a very precise offering for this. It's on our website. We call it the Accelerator Package. Just specifically for the reason that you outlined,

we know it's early. As we discussed earlier, there aren't really any playbooks or long documented use cases and case studies and frameworks out there. I mean, it's still, we're in the early innings of this shift, not, you know, barring the large providers who already kind of pioneered with this, right? So, no, yeah, you know, we, a lot of companies need help, no question about it. And it's not because of a shortage of talent or anything. It's just a new domain. It's a new category. There's not a lot of knowledge and information available.

So, at least we had, right from the outset when we launched, we have this accelerator package, which outside of us being ourselves, the PLG usage-based pricing self-service product, accelerator packages, we have dedicated hours of consulting services as part of this package. And this is where we will actually sit down with you and walk you through, first understand your use case and engage with you sort of at the strategic consultative level and helping you design your pricing plans. And then more importantly, what is the methodology? What is the step one, step two? How do you put one foot in front of the other?

How do you start with metering? What should those meters look like? Once you have that, how do you do price modeling? How do you do A-B comparison? How do you ultimately determine I'm going to price this thing? Should this be a tiered-based pricing model, block-based, unit-based, and tiered-based? Let's say an API account. What should be the tiers? And what should be the break-off point? How should you decide those things?

What is the framework to even decide those things? And I'm guessing as the industry matures and people have all these blog posts and VCs write blog posts about how this thing should happen, you don't have to be as involved in that process. Assuming your thesis is correct and the industry moves in this direction. That is correct. And there's already a lot of stuff happening. I should just plug in for OpenView Ventures. Kyle Poyar, he writes about this stuff on a daily basis. There are other thought leaders, venture capitalists, analysts who are now writing about this stuff on a daily basis. There are other thought leaders, venture capitalists, analysts who are now writing about this.

So it is now coming into the mainstream, right? So yeah, we're just not the only one, in fact. And we're glad that there are others who are also talking about this. And I think there's a good, healthy ecosystem that's already out there. Yeah. What kind of, if you don't mind answering, like what are the kinds of companies, you don't have to list specific customers, but more like which industries, like what kind of, are they like developer tools type companies? Are they just general SaaS tools? Stuff that you would have never imagined to have, like, you wouldn't be thinking about pricing models, like usage-based pricing in the past, trying to use this, like, what kind of customers are you seeing yeah so uh okay so you know i guess no surprise uh

the low-hanging fruit right clearly sort of your what we would call pass platform type companies platform as a service right and why because it makes sense like a heroku type company that's right yeah i mean anybody who's doing database data warehouse etl ai, AI, ML, DevOps, database, you name it, right? Candidate for usage-based pricing because inherently they're closer to infrastructure, right? Okay. So that's a no-brainer. In fact, obviously we engage with a lot of them. You look at our website, we have a lot of those customers because they're asking for it by name.

They understand, right? Okay. But I will tell you what's actually been super exciting. And I kid you not, clearly, you know, there's more data that will come out in the next few months or a couple of years. But this is, we are surprised every week, every day, every month that companies, application type companies, right, from the core SaaS layer are going towards usage-based pricing and billing. Okay. What are they metering based off of?

Are they metering off of really granular things like the amount of operations that users are doing on their platform? Yeah. Yeah. So again, the other myth is that most of the examples today is as we just discussed, you know, pass has sort of a direct, easy. Yeah, correct. Okay. But it's, it doesn't have to be that. And that is the thing. And I think this will take a little bit of time before everybody sort of,

you know, turns the corner on this. Right. So I'll give you a couple of examples from who we have, and then we can sort of extrapolate for that. So we have actually surprisingly a couple of companies in this specific category. So these guys, they provide leads, curated leads to their customers, right? So you imagine, right, there are many companies actually in this category. And a great business model, right? The contacts list leads, right? Well, guess what? So there's not really a direct correlation to infrastructure, right?

If anything, you're saying there's value in data here. It's value database. So what they are coming to us with, original business model was a huge step function to get started, right? $3,000, $4,000 to get started with. And then you kind of work your way through that. They're saying that we want to open up the funnel. We want to get started easy. We want to make this on a consumption basis.

So make it a function of how many leads I send you. We actually produce for you. Exactly, right? And then I want to be able to monetize the lifecycle of the lead. So maybe the lead is just a dollar. But if this lead actually led to a meeting, then there's a charge for that. It adds a little value. Yeah.

And I can because you got value out of it. And if that meeting actually resulted in actual revenue, then I may be getting a... Yeah. Right? Got it. This is usage-based pricing, okay? What else I can... These are not our customers, but you can look at them.

This is a study on the web. Even as far verticals as companies like Caterpillar, John Deere, okay, you would never think about that, are exploring a business model where they charge for a unit of work performed by their machines, right? So for example, metric ton of dirt moved. See, combination of IoT and all that stuff, you can do that, right? Usage-based pricing.

So if the machine is just sitting idle, technically, you shouldn't really have to pay for it, right? Okay. There's a company here called Metromile Automobile automobile insurance charges you insurance by the mile how many miles your car travels and you know if it's just sitting there if you don't pay yeah yeah and you know they have like there's a base charge like you know every month because you know they have some fixed costs which is fine but yeah you know if i'm driving a lot i pay more if i'm not driving much then i don't pay as much so that's what was the thesis behind you know when i say that this will be the dominant model uh it is at the end of the day it is just better line you know you you pay for what you use nothing can be more nothing can be better than that as they say that's kind of the holy grail

yeah and it'll just take time for customers to kind of get used to that, especially in an industry that they're not used to that kind of stuff. And what I'm seeing is that it reduces your CAC, it reduces your acquisition cost. You can just pitch your thing as when you're tiny, you should use us because you're going to get charged much less and you don't have to go through like the whole sales motion. You might even get your first X requests or whatever for free. Like I saw on your website, you have like a million requests free. So great. When I'm a tiny

company, I can use your product. And then over time, I'm actually paying for what I'm using rather than, you know, negotiating a contract. I had a vendor this year who 10x their cost, the yearly subscription, it's out of the blue because I think they acquired the previous year and they're just probably trying to hit a revenue target and now we have to scramble and do a migration. So that's the kind of thing you avoid. That's right. And that's why I think companies who are leveraging this PLG usage-based pricing motion, I think the incumbents who are not, I think you're going to have to face the music pretty soon because they will be better off. Their P&L will be more efficient than if you're not on this model

and uh it's just that's that's just the way it is yeah what's what's the future plan right what's the vision for amber flow like next one year two year plan like you have a product it works right now what do you want to build like what's's not there yet? Whatever you can share. Yeah, I'll share with you a little bit. You know, I'll certainly sort of mention the fact, you know, again, for your audience that, you know, we started the company in all fairness, not just to put out a modern and next generation pricing

and billing platform. Okay. We're super passionate about it. Of course, you can see the work and effort that's gone into it, how new and disruptive that is, all that good stuff. But the motivation was really, again, what I sort of covered with you right at the outset. So if you play this model out as the world is transitioning,

as we discussed, this doesn't happen very often, maybe once or twice in your lifetime if you're lucky. So we just, everywhere we look, we only see opportunities. Now the question is, okay, well, that's pretty broad, right? I mean, anybody can say that about anything. But we do, you know, but we have actually a pretty well-defined thesis and a roadmap. But I will say this, and that we are on that path, and we are on that roadmap, but it is structured. It has to be...

So the path that we're on is the path we have to take to get to the next stage. So metering is the platform, and then pricing and billing is an application that sits on top. And then we have aspirations to build additional applications parallel to that. But you have to get metering right.

Okay. So once you build metering, I mean, pricing is the obvious answer. You can maybe do all sorts of things like optimizations, perhaps. Like not just on pricing, you can even inform your own product. If I'm metering how often an operation is happening, you can probably suggest recommendations on how do I cut this stuff down? Where should I be looking? Breaking that down across several teams. Interesting. It's kind of like an observability tool into how...

You can kind of build an observability tool on top of metering in a sense you you're spot on i mean that is what metering is in in the world of usage based right metering is the high order bit i i would say and you know, a little bit depends on what your overall posture is and where you're coming from, but I would profess to say, you are not a cloud business if you don't have metering in your technology stack. You cannot be.

And I say, independent of your pricing plan. If you're not usage instrumenting, what is being used, by whom, when, what, where, how much? You doning, what is being used, by whom, when, what, where, how much? You don't know what's being used in your product at all. Got it. Yeah, you're not cloud native in my mind.

You have room to go. So that is the... Let's call that... And I would stand up against anybody from anywhere. I'm not born with this. It's a lesson learned from eight of years. This is the first principle of the cloud.

You got to usage instrument everything. Okay. Yeah, I think all of the B2C marketing folk will agree with you. And it's kind of on that. Now I'm imagining something around like you can actually instrument what's being used or what's being looked at on your marketing site that can drive information about how your pricing should be you can all kind of live in the same platform so there's ideas yeah there's ideas yeah and if you kind of build a combined um your tool itself could tell you that

you know i'm counting how many times people are seeing this new product page based on that, you should be doing this next in your roadmap and you're going to get paid this much. Cause like this tool knows exactly what people are looking at and how much you would get paid if you built that. Okay. You're spot on.

You're spot on. Yep. Yeah. I think, I think there's a lot of interesting ideas. I really liked this episode because I think I learned so much and I think there's a lot of interesting ideas. I really like this episode because I think I learned so much and I think I changed my mind on, you know, whether Netflix should do this or not. So thank you so much for being a guest and I hope I can have you again at some

point to talk about just, you know, the technology, maybe a year from now and see, you know, has the landscape changed? Are people really moving towards this or not? Yeah. So thanks so much for being a guest. My pleasure. So yeah, I'd love to come back see, you know, has the landscape changed? Are people really moving towards this or not? Yeah, so thanks so much for being a guest. My pleasure. So yeah, I'd love to come back

and, you know, maybe next time talk a little bit more about technology, but that's awesome. Thanks. Thank you.