The Truth About SaaS Pricing | Expert Advice From Head of Product MET3R (EP# 52, Part 2)

James, you have the distinction of being the first person to do 2 episodes on our podcast. So we're releasing this, we're releasing this as a part 1 and a 2, a 2-parter as you described. I'm so excited for the conversation.

Awesome. Yeah, great to jump back on the phone.

So today, you know, I think we've got, we're going to try to really go deep on 3 areas. We're going to try to talk a lot about Segment and the pricing journey that Segment was on that you were a part of. What you learned, what you saw, what can be instructive for founders and operators. Then we're going to go into Meteor. You have been leading product at Meteor for just about a year now, full-time. And so I imagine there have been quite a bit of like super interesting learnings on pricing and packaging, having come most recently from being more on the consulting side at Insight to now being in the seat and really leading on the product side. And then we're going to talk about what I think is on everybody's mind, which is AI and what this means to pricing.

I've seen a couple of posts about that. Recently. So that's something that seems to be on everyone's mind for sure.

So we got some, some interesting stuff to talk about today. So let's start with Segment. Um, maybe just however you want to tell us the story, what is Segment's story with pricing and packaging? It is very instructive and it is, it is so instructive that people like Simon Kucher and A16z have all tried to write about it. So tell us a little bit of the story.

It's a really interesting one. And I will say I'm borrowing from some people, like people's notes from before I was involved with the segment. Journey. But I think from 1 to like, or kind of 0 to at least 100 mil-ish of ARR when I was around, the growth and the story of that pricing journey is one of the most interesting ones. It really started, and Peter, the old CEO, tells the story far, far better than I do, but I'll do my very best. Really started when Segment launched off Hacker News. It was actually an internal project for another project that they then launched. And it was, I believe, $10 a month flat fee, all the segment you want to use, which I think was very, very good in driving a lot of demand. And my favorite thing was the Slack message or email or something that someone got, which was a customer saying, I really like your product. I think it's amazing, but I'm slightly concerned you're not going to make enough money to survive as a business because turns out $10 a month for an unlimited use of a CDP is neither a great pricing model or a great overall business model, because it will most likely cost you more than that in a lot of use cases. But the, so I think that was V1, very like, or like almost V0.1. And I think there was then a move to shift everything towards kind of packages online, not $10 a month, but not crazy expensive. And so when I was first involved, I was actually an advisor at the time. It was kind of a range of packages over two products, usually bought self-service, and then a business option. Challenge I think that we saw was that the self-service packages were really, really, really generous still. So you ended up at, I believe, the highest cause of churn from the business tier, which was actually making kind of good money. And we had some fantastic salespeople driving the train for the first kind of few mil of ARR, they were making some really good deals, making some really good money. The highest cause of churn from that business tier was down to self-service. So we were losing money from every customer that turned down and quite a significant amount of money. And the number of customers, certainly a few customers, there wasn't a huge churn problem or anything like that, but there was definitely a few customers who said, wait, I like the product, I'm using the product, but it's easier and cheaper for me to pay £6,000 a year by buying it through self-service than far more than that buying through—

It's a classic example of self-serve tiers cannibalizing.

Absolutely. And then on new deals as well, but you couldn't track the new deals quite as well because you don't know necessarily if they've already just cannibalized. But yeah, we basically had that problem where the business tier was actually performing really well. The self-service tier was working. I mean, it was driving to a good kind of starting revenue number, but it was almost certainly hitting a plateau in terms in terms of revenue growth. And a lot of that was because of this, because we didn't have that much expansion out of packages. Like the packages were flat. They included a certain limit, but there was no expansion past that. So you very much ended up with people firstly going for self-service over sales because it was much more generous, but then also not expanding from where they were. So the kind of growth path, the growth path for happy customers actually wasn't really there at all. That brings us on to, I think now we're on to like the third pricing model of Segment, or as in at this point in this story, we're now on to the third iteration. And this was when Segment shifted to MTU. And I think this is probably the pricing model that everyone's familiar with. So Segment moved to MTU with one self-service package that did kind of everything. It combined the products and then offered a very simple entry point for low-volume users, and then expanded in price as you went up. So you're able to acquire customers using self-service, but then actually expand them. The kind of price went up a little bit so that it matched with the business pricing. So you actually, instead of then having a conversation where you could basically say, well, I can go for self-service way cheaper for the same limits, you then had a cut a kind of break-even point where sales could actually contact the customer and say, hey, how about you get a discount for the same map you're already using? So completely flipped the table on it and basically meant that business was the right answer for a lot more of the market. And it was the right answer, like trying to sell, I mean, for a very young startup or something like that, getting onto a CDP, you can engineer it together in a day. If you're a large company, an enterprise company, these are 2-month, 3-month sales cycles, big rip and replace of data analytics and data engineering, long implementation cycles, all that kind of stuff. Like it wasn't necessarily a self-service product at some, some part of the market. And at that point, I think that's when we managed to align the revenue model and the pricing with how people actually wanted to buy. And that I think was what really propelled us forward. So that version of that model took us belief segment kind of there are evolutions to this model, but the core structure is in place today because it works very well. At some point, I think we were looking at something like 150% net revenue retention, which is pretty up there in terms of quality of benchmarks. And then we also had a really, really good motion of self-service customers going in and being effectively upsold into business. So I think a large proportion of the leads to our business tier, like certainly in the SMB segment, came through self-service. So that's a— it proved the model was working. And I think from a point of having had a bit of stagnation, that revenue growth flipped back. And I think what was really driving that model effectively was the fact that you could align incentives as you go. So as customers expanded, you could go to them and say, hey, how about a discount and a few more features for the same, like, same usage amount that you're using? And it's a pretty no-brainer sales conversation at that point. And I think the only kind of question mark that arose with that model is, do we go too far too soon with the price level? Because you kind of don't realize until 2 or 3 years later how that acquisition path has changed and how that funnel has changed. Because there's such a long cycle between getting people onto self-service, nurturing them, then upselling them, that it's hard to judge that lag. So potentially we could have like taken slightly smaller steps in pricing in, in the interest of preserving some more of that pipeline or preserving more of the acquisition play. But I feel like it was generally a pretty strong and successful model. And from that point, I think the real answer is iterating on it. So we launched two new products. Those ended up being monetized on top because it wasn't obvious that they would always be bundled in. Like they were slightly different use cases, slightly different buyers. So those went on the top. And I believe some changes have happened since then, but like basically, yeah, there's additional features and additional value being added to those packages. And then the other important thing was cost protection. So we shifted to a metric called monthly tracked users. And then we maybe semi-invented it or certainly were one of the first people to use it, which was great because it actually really scaled with the size of the business that we were working with. It was a very good proxy.

And what was the price metric before? MTUs?

Before it was API calls. And I think you realistically, you could have like made a sliding doors argument that with API calls, it still would have worked. And you still, some, you see some players in that space, like RudderStack, for instance, use API calls and it's successful. I think the benefit of MTUs though, was it really did scale with the business size and it made sense to businesses of all kinds and all use cases very effectively. But it opened up that it's an interesting, like, first, second phase kind of conversation because as the market evolves, then API calls became a like good metric, like a good metric to fight Segment on because, because Segment used monthly tracked users. But the other challenge that we had with shifting away from API calls is API calls was very strongly aligned with cost and MTUs wasn't as much.

That's interesting. But maybe just to consider what's happening here is Segment's realizing that the customer perceives MTUs as more aligned with the value they receive from the product?

Kind of, and also customers to see customers across the spectrum of different user types. I think there was definitely some areas where customers would've had a very, very cheap ride for what they are tracking because they track very low number of API calls per metric and things like that. Whereas actually, and certainly for some of those use cases, some of those use cases, if you talk about consumer, if you talk about media and like the actual value that you're delivering is actually pretty high because a lot of the marketing pixel retargeting, all of the like data linkage stuff that you, you want to do with those companies is actually super, super valuable. So you end up with, it's, it's a relatively low value per user still, but it's certainly a higher value per user than their API calls alone would suggest. And as a result, you end up, you ended up with MTUs working very well across a space, a swathe of market and also working pretty well when it came to scaling across business units and things like that, because most companies knew how many customers they had. And you could start to land and expand through, for instance, like Turner Broadcasting or something like that, where you had a conversation with one business unit, you covered that one business unit, and then the metric really scaled very well as you brought on new business units within that. Certainly wasn't perfect. And I will always say almost no metrics are. The one thing with with it is it wasn't aligned with cost. So at one point, what we did do was have a secondary cost protection measure, API calls added into that pricing model. Because I think it would make sure that it would scale with cost.

Do you remember, was there a moment when it just became obvious we need to shift the price metric? Or was that uncovered through a lot of analysis?

I actually, so we did a lot of analysis and actually it was actually very interesting that the analysis kind of pointed to, you could go either way on this one. It was actually a world where you could have done either metric and been very effective. I, I mean, I think the success story in itself proved that MTUs wasn't necessarily the worst, was a good metric. I mean, there is, there is a lot of benefit from, and it certainly spurred up, they had a pricing model that was pretty effective, but the sliding doors question of like, what would it have been if it was like API calls? It's kind of hard to tell. It may well have worked out well. It certainly works for some companies in the space. But I think it's an impossible, like, hindsight question to ask. But I think it was an interesting one where two metrics came out really head and shoulders above everything.

That's a really, it's a very fascinating situation. And maybe, so if let's imagine we have founders and product leaders listening to this, how do you make the call when it's, when the analysis suggests that it could be both? Do you lean on the metric that customers have indicated is most intuitive to them in terms of how they receive and perceive value? Or do you think about it differently?

It's a really good question. And I would say I have an opinion. I don't know if it's 100% the right one. But like, my instinct would be to go towards what's most predictable and most sellable. And in this case, that was definitely users. Like everyone knew what you— how many users they had. Everyone knew what a user meant in this company. I mean, The definition of that gets funny in any scenario, but like generally speaking, pretty easy metric to like explain to customers and understand. We could tell them to look at some analytics tools they're already running to get an idea. Like, whereas if you're trying to estimate a whole year of API calls at an enterprise scale company, good luck. It's, it's, it's not going to be easy. You've just got to throw a big number out there and hope that you don't, don't beat it. Right. And I think that's where. That's where my gut would point again. But again, you're, you're playing around with the benefit of then having a better cost protection measure than having something that speaks better to an engineering persona versus a marketing persona potentially. There are definitely like big trade-offs either way. Like there's no right answer. I think there is, there are a number of wrong answers, i.e., not those two metrics, but there probably could have been success in either, either of them. But my gut feel always points towards what's most sellable, what's easiest to implement. Because at the end of the day, I think the— in many different sales practices, it's very easy to scientifically design a pricing model. It's much, much harder to get it working in practice. And that is really a question of how do you get sales, customer success, and customers all understanding the same thing in the same way. And that I think worked really well with, with TrackTees.

Maybe one more question on segment. And it does get also to maybe a potential third price metric that the company added at disposal. And that's— and maybe for those who don't know Segment, I think of Segment as a tool that allows you to very easily pipe data to many different sources. Is that a good simple way to describe it?

Pretty much, yeah.

And so it, it seems to me that sources— maybe there's a better word for sources— could have easily been a price metric. Um, and I think I've read that the CEO and founder just was like convicted that's not the way to build the price metric here, even though that probably what would have felt relatively intuitive to customers. Yeah. Do you remember any of that?

Yeah, yeah. So that, that definitely came up, and I think the thing that we saw with sources is it didn't scale well with size of use case. So like very well and good that you definitely do get more value as you add more sources. It's massively better. Or sorry, I guess there's two things. That is the first one that it doesn't necessarily scale that much with scale of business, but you could have someone wanted to pipe to 5 sources and they are a small startup with 500 to 1,000 to 10,000 users. And you could then look at a media company also wanting to pump pipe to 5 Kurzgesagt sources, but they have like millions or hundreds of millions of users. There are very, very big distinctions in how much they'll pay. And that would have been hard. So sources would have had to be compounded. And that's where I think it comes to the second, like it would have to be matched with another metric in some way. That's when it comes to the second question of Actually, and this is, you get a little bit with API calls as a metric as well here. And the leadership team was very, very adamant in many cases that they didn't want to block off usage. Sources and to a lesser extent destinations, sorry, sources and destinations being two different elements here, definitely added value. But realistically, what you didn't want to do was put a tax on every new integration that you set up. Because then you actually get a lot worse of a product experience from Segment because every time you try to bring something on, it's like, well, that could cost me it.

Right. Because in other words, like Segment is far more valuable to the business if they're using it across all destinations and all sources. Why disincentivize that behavior?

And that's definitely been something that I've seen in other companies I've worked with as well, where you have the option to put a metric that is really close to a value, but it's not, it's not passive. It's very active, it could really change the way that people operate in the product. And usually I would go for the thing that drives usage as much as possible. And if you can then put a, put a monetary value on the usage after the fact, or on the proxy that drives usage, then it works really well. But as soon as you're starting to limit usage, and actually that's what another thing where API calls wasn't quite as good is because people may have tracked fewer things, tracked less data per user, all that kind of thing. Users had none of that. You don't have any active control over how many users you have. And actually, it's probably a good thing for your business if that number is growing quite significantly. So it's actually fairly well aligned with the successful outcome kind of.

So Segment is just a really instructive story for founders and operators. And so I think that's why we wanted to spend the time on that. Thank you for that. Let's talk about Meteor. So you have been at Meteor, I'm pretty sure, for about a year in a full-time capacity.

Yeah, just coming up to a year, uh, the end of the year.

And you'd been involved with the company before that in an advisory capacity, but full-time for about a year, you're leading product. You're operating in, obviously in the context of a fascinating space, which is, you know, let's just call it billing and usage-based billing and subscription management is quote to cash. We can describe it in a lot of different ways, but I'm very interested to talk about what you have learned over the last 12 months about pricing and packaging itself. I mean, I imagine you started to learn things that maybe you hadn't even learned before in your roles at Segment and Insight and Simon Kucher. I'm curious if you can talk about that.

Yeah, that's the big— one of the most bizarrely eye-opening things from this last year for me is I've seen a lot of pricing models and I got to the point at Insight where I hadn't seen any more or new ones for the last year or year and a half. But as soon as you get into having to service this from the vendor side, right? Like you don't really get a choice of do I support this pricing model? Do I support that pricing model? Because if a customer comes in with a need, you either support it or you don't. And for Billing, I would say, I don't know if you guys are finding this, but like, if you have 95% coverage of someone's whole pricing spectrum, including all the legacy models they might be supporting, all that kind of thing, you don't have coverage. Like, it's very binary. You either have it or you don't. And then you have a really hard conversation about like, well, we can do this for you. We can do this for you. We can do this for you, but we can't do that. And it becomes a big sticking point in a conversation. I would say we're in a fortunate position of being very flexible and having many, many use cases we can support. Like we can deal with a heck of a lot of pricing complexity, but there are things that I have seen in the last kind of year or so that have been like, the customer wants to do that. I have never seen that before in my entire life. Yeah, we can do that. It might need to build to it a little bit, but like having to, having to checkbox off the entire world of pricing. You realize how deep that rabbit hole goes and how crazy some models like, and I'm talking about like things like the first 5 costs this and then the next 2 costs this and then it's capped off at 7 total. But that then combines with other ones of that metric to become one super metric. And you're like, I can't, I don't know how your sellers sell this, but good luck to them. But yeah, we can make it work. But it's been a, I would say a good number of the challenges have been around, hey, how do we actually make this pricing model work if it's a pricing model that I've not seen before? And I definitely came into this role being like, cool, I kind of know this work. I know pricing. I can set out on a piece of paper all the models that we need to build and we can build to it. And I've definitely eaten a little bit of humble pie on that one of like, there's definitely things I didn't think about.

You know, one thing I'm curious about is, you know, you're describing like pricing models that you've not seen. That in some cases sound like they're quite complex. And the question that emerges for me is, have you come to sort of believe that people, businesses are creating too much complexity for themselves in the way that they are pricing? Or have you come to view it slightly differently, which is actually businesses can be very unique and they have found pricing models that actually are just very specifically kind of well suited for what they are doing? Like, how have you started to kind of fall on this?

I would say it sits in between both. So I think there's definitely, there's a level of complexity that at some stage of business, like, is just endemic. You can't avoid it. You have multiple SKUs. You need to, you want to co-sell them or combine them. That leads to having multiple metrics in one plan and all that kind of like, there is, as you get certainly to a certain stage of company, complexity just creates itself. And actually that's the right answer for the business. I think there's also definitely pricing models I've seen that have clearly been some train of Well, we sold it in a deal and then we added this. We then sold it in another deal and we added this element to it because we wanted to make sure that our customers didn't like overuse something or like we added a protection to like make that one customer happy and then applied it across the whole spectrum of customers or applied it to our entire model. And then you've ended up with a little bit of a Frankenstein's monster of a pricing setup. I would say a lot of the time those are models that are now legacy within our customers, if that makes sense. But again, the challenge with operating in this space is if you don't cover all the legacy as well as the new models and all that kind of thing, then you're severely limiting the amount of value you can add to the business as a whole. Because it's all well and good to balance your book for 90% of your revenue, but if you can't then balance the book for the other 10%, then again, you haven't done the job that you need to do. But I think that's— you definitely see both. But I think complexity drives itself. And I think some industries lead far more into complexity. Like we do a lot of, for instance, ID verification and fraud stuff. It's actually very little way of making a pricing model that isn't somewhat complex in that world. Because there's a lot of different metrics and usage parameters and things like that, that you can charge on.

Can you talk, if you can talk about this, I'm curious the extent to which Meter's own pricing and packaging has evolved in the 12 months that you've been there. And if not, how you anticipate it evolving as you meet the market. And as the product evolves and as the market evolves.

Yeah, and I actually think it's maybe even broader to say that it's around market positioning and overall product-market fit. Because I think from kind of historically, we'd sign any deal that came to us, we'd definitely speak to any kind of customer that would come to us. And there was a lot of hugely complex like pricing models and businesses that would come to us wanting what's effectively a systems integrator job, like white glove service, managed service for all of your billing, they would have a relatively low willingness to pay for that. And we'd end up kind of burning a lot of money. And actually, a simpler solution may have been better for their use case, because they didn't have a huge amount of complexity. They just had a lot of, a lot of demand, like demands around particular pricing models and things like that. I think as it— and it's not the best fit for our product, which is hugely flexible, very much enterprise-grade, very reliable, like, and we do a lot of work to make sure that those things are tense in the product. I think once you have a kind of somewhat scattergun approach of like market strategy, you end up seeing that the product market fit works in one space, doesn't work in another. So I think that's what we've, we found more than anything is like, there is a right kind of customer for us. And it's generally a business with a little bit more complexity that have a lot more kind of financial processes and things like that, like usually will utilize a CRM as well as billing and things like that. And then, then you start to find, oh, that's a better fit. And also they have willingness to pay rather than let's try and manufacture willingness to pay in a market that doesn't really drive it. Like the smallest startups won't have that much willingness to pay for anything, but they also don't need a bunch of the stuff that we can provide. And I think we were definitely, we did ourselves a great thing by going in with more intent with how we positioning ourselves, who is our right customer and driving it that way. And actually the pricing just kind of follows suit, to be honest. Like it was actually, you could get the same kind of price with far less negotiation with the right customer than with a kind of endless amount of negotiation with the wrong customer.

I think it's a really instructive story for founders.

Yeah. It's actually one of the few cases I've seen where it's almost like we found product market fit by changing the market element rather than the product as much. I feel like usually you look at that and be like, well, the market's static. This is what the market looks like. We need to change the product to match the market. And actually it was very much finding our space.

Yeah. And that is one of the things that's interesting about billing. And maybe this is maybe podcast episode 3 as we talk about the billing, but there are so many markets within the billing market. Yeah.

And there's also the, I think the other thing is the ecosystem generates its own markets as well. I think you can, you can even see this in many other places. Like you have entire ecosystems built around Salesforce. You also have entire ecosystems built around HubSpot. They don't always look exactly the same. Like it's not all the same vendors in the same places. Those ecosystems drive their own market texture because you don't, as a, as a Route 1, you won't tend to replace your CRM or your billing system, or certainly not your like ERP or general ledger system, right? Like those are usually the things that stick and everything else moves.

Maybe one last question on Meteor before we get to AI more broadly. And that's when you find yourself in a situation where there's a potential customer on the line, but to your point on like the 95%, they have a new pricing model that Meteor may not support out of the box yet. Can you talk a little bit about how you want to go about that decision? That's a really important and hard decision. It's incredibly attractive to go after the revenue, but that has consequences. How do you like to come at that consideration?

Yeah, and I think my answer might be a little bit of a cheat here because I think, so to me, it comes down to the technical challenge of supporting that customer. And if that model is particularly difficult, and in certain cases, that is things like it requires multiple steps to create that calculation. Like now we can actually support that and that's a good thing. But in cases where there are like one too many dimensions or something like that and it's hard to support it really perfectly, then it comes down to a question of actually what's the technical challenge of adding that in. And I've seen some use cases where in order to truly support that pricing model the same way that you support others, you'd effectively have to replatform because you have to rate everything in a completely different order to how you would normally rate it. That's actually really hard. And so those are the ones that we're like, okay, but we may not support that right now. I, we haven't actually, we've come across a couple of cases of that theoretically, although not actually in practice. But there's definitely a, definitely a world of there is some things that are actually much more of a technical challenge from the rating standpoint. It's usually in the rating step. Aggregation step or rating step, that the order changes because of that pricing model being in a different way of operating. Those are the ones that we're like, okay, we need to think about this more carefully. Pretty much everything else, we're fortunate enough that there may not be the absolute perfect, like, native solution, but certainly that the meter will be able to help.

Let's shift into the topic du jour. So, you know, this is what's the jumping off point into AI here? I mean, I think I'll start with a little bit of a story and that's last week, um, I had a founder CEO of a company called Invoke.com. It's a really interesting AI company on the podcast, and he said something that has felt to me to be very true, and that's companies that are building like AI-specific products, even enterprises that are launching AI-specific features, they have a relatively complex road ahead of them in terms of pricing. And I'm curious if you can maybe react to that and talk a little bit about the extent to which any type of framework for pricing AI startups, like, and maybe kind of AI features has started to develop for you?

It's a really good question. I feel, and there's plenty of things going around about like different AI models, what's the right AI model, all that kind of thing. I really feel like it just brings, like, the principles haven't changed in pricing and packaging. Like, the way to think about pricing AI is the way that you would have thought about pricing standard SaaS, maybe even even kind of like things that lie together better, better CPAs. I think the thing is that it forces you to rethink all of those things again. And maybe the right, the right comparator is like more infrastructure-based things like cloud computing, all that kind of stuff, like factoring in the cost component as well. But I think it, what it does is definitely brings around a few different challenges and will probably be a bit of a reset point. Like if you aren't at least reassessing your pricing and packaging in light of AI, you're probably doing it wrong because there are so many different components. Components. But I think as you start looking at like, first you've got the split between is it like a Copilot type AI, in which case, if you're already pricing on seats, maybe it makes sense to continue pricing on seats. But you've got a bunch of other things to consider there, such as where's the true value of that? And actually, does it make, like, does it actually reduce the amount of people that you need to bring on and things like that? Therefore, seats becomes a declining metric and maybe that's not the right answer for your business anyway. If it does end up kind of replacing, replacing seats by making people more efficient. The other thing is, well, if people were using this product that I built on top of LLM and I'm paying LLM tokens for the usage, I need to cover that cost. And it's usually, if you take a standard kind of desktop software that people use, far, far more expensive if it's AI powered with the processing and the LLM tokens that you're utilizing than if you were just running this as a standard desktop software where the user was in it, because usually the cost base for those kinds of companies was super low. Now, now usage drives cost much more. And I think you need to then think about that. And maybe the answer is like a hybrid of it starts off with seats, you get a certain amount of usage, you pay over that in a token or credit model or something like that. But I think realistically, the answer is too new for people to have answered that question perfectly. But then again, if you're, if it's more of an age like agent model. I think that's where we're going to start seeing it push more into like your primary metric is usage of some kind, whether it be kind of more similar to Segment, like a proxy for the value that you're generating or something like Intercom's model where it's actually on everything that the AI solves for you, you get priced. To be honest, I feel like there's a few different models, probably more people are waiting on the fence without picking a lane currently, but there's a few different models. I think it's way too early to really see what the right answer is for a lot of businesses. It will be very, very interesting to see the next 2 years because I think you're going to get the blend of some interesting use cases and studies and things about these kind of models and then like what is working, what is succeeding, what actually drives best in especially the agent world where this is a relatively new kind of area of product. And then I think we're also going to get in the next couple of years, a lot of people being like, oh yeah, we should probably rethink our pricing. But I think the good, the good news is it's very much following the same steps you would have without it being in AI, like you would have anyway. It really is about understanding where the value is generated and where the willingness to pay is. So the steps haven't changed.

To the point that it's early innings is one reason it's really hard to talk about like how this is going to evolve because is one of the reasons it's very difficult to kind of know where this is all headed because right now costs, fuel costs are here, but tomorrow they will be here.

Yeah, I think it's really hard to see how that will evolve. And I mean, I think everyone understands that it's kind of going to come down by a magnitude, but whether that magnitude is X, 100x or 1,000x is a massive differentiator to like, because I mean, with a certain amount of usage, like based on tokens, you can, if someone is using an AI tool every day, that's a lot of usage. Like they were putting in a lot of tokens through a system. That cost may need to come down for really high volume use cases. And especially as you start getting complete automation and APIs driving LLM use cases and working off it. Like, so you take the human out of the loop completely in some cases, like that kind of cost base could be Do you know, um, uh, Ulrik—

and I'll not pronounce his last name correctly— but Lerskov Schmidt?

Oh, I don't know.

He's, he's been on the podcast, and he's a pricing consultant based in Europe, Denmark. He, he's written something that I think is quite interesting. I'd love for you to react to it. And I think the gist of it is, you know, how do I think pricing AI and SaaS is evolving? And I think his argument, if I can capture it correctly, is we should think about this in the context of maybe there are two layers. There's the AI compute, which is like the token pricing, and then there's the AI solution, which is like the value that you add on top of the AI. And I think he goes on to describe a bit of a dilemma, which is today the fuel is expensive, at least more than traditional SaaS, um, and today the solutions are still relatively immature. They're kind of early-stage solutions. And so What that means for pricing AI today is that, like, you have to go charge usage-based, based on fuel consumption to cover your costs. And you also have to kind of focus on, like, low barrier to entry because you're an early-stage product. And that means that the way you price today is going to be quite different from the way you price tomorrow when hopefully the fuel costs have come considerably down. To your point, we don't know how far down they've come. And your product's better. And I think where he sort of starts to land sort of impost that logic is we're headed in a pretty meaningful way towards sort of the outcome-based pricing. I'm curious if you'd react to that. I mean, we're all trying to think through this, and that's, I think, an interesting framework to consider.

I think that could definitely be the case. I think the thing that I'd kind of caveat there though is I don't necessarily know if this points towards a certain metric or like a way of pricing as much as it does to a kind of general policy of maybe trying a few things out, but realistically, like making that call again, when fuel prices are down a little bit and the solution has hit full bore. Because I think the answer to that will change. But again, it really depends, I think, on your product and what, where the value is being created. I think it will be kind of, it is a tricky thing to get people to adopt something that's brand new if it's a pricing model that's different realistically at the, at the moment. And therefore, I think a lot of people, especially in the kind of Copilot world, are pushing towards, let's just price it how it is, maybe eat the fuel cost or put some kind of hard cap on the cost protection so that we're not kind of throwing too much away. But I, I, I do think that there will probably be a usage component in many, many AI tools in 2 years from now. But right now people are kind of sitting on the fence, waiting until they have a little bit more clarity on the outgoing kind of cost of the tokens and also are probably waiting to see a little bit about what other people do in pricing and how that market evolves. I think, but I do think that, and I think we'll probably end up with kind of 3 overall pricing models that work out. Maybe there's a few more that I've missed, but I think the concept of outcome-based is definitely one of them. I think it is definitely— AI really leads to that because it drives outcomes that you wouldn't have had otherwise. And I think it could be a really interesting way of pricing for some places. But then again, case studies are early. We don't know 100% what the success is of those. And I think that there's never a silver bullet metric. So there will always be challenges in explaining the outcomes and things like that. But I think it's a lot easier than it has been in the whole old world of SaaS to prove outcomes. I think proxy usage-based metrics, like number of users, Salesforce agent forces, number of conversations is a good one of that. Like, you don't know if those conversations are each driving value, you kind of hope they are. And you'd hope that at scale, the number of conversations is driving value as proxy. And then I think the third thing is going to be like a, especially for more, more of the Copilot use cases, seat-based, but with a cap. So you've got usage-based in there, you've got a total max limit and maybe you've got a pool or you can go over that and pay a little bit extra or like you've got a company pool of like extra usage that you can buy into. But basically that will help protect your cost and also align value. But I think that also gets— and sorry, final thing before, but like the one other thing that we don't know yet is what happens to seats? What happens to the number of users using your product when you start throwing in AI copilots? If that leads to a bunch less people using the tool because there are fewer people in those seats in general, suddenly seats really doesn't look like a good metric.

All right, James, this has been so much fun. I hope we do a third.

Yes, definitely. Definitely keen to return.

Thank you so much for doing this, and I hope you have great holidays.

Yeah, you too, Fynn. Have a good one. Thanks. Bye.