Sam Lee shares how to tackle SaaS monetization and scale usage-based pricing.
In this episode of Unpack Pricing, Sam Lee, VP of Pricing Strategy and Product Operations at Hubspot and former Snowflake pricing leader shares his deep expertise in building and scaling pricing teams. He joins host Scott Woody to explore why pricing “is a sledgehammer, not a scalpel” in business strategy.
Sam has over 20 years of experience in B2B monetization and pricing strategy is currently VP of Pricing Strategy and Product Operations at Hubspot. Prior to Hubspot, he spent 4.5 years leading pricing strategy and operations at Snowflake and has also built pricing teams at ServiceNow, Infoblox, and Microsoft.
He’s seen the transition from traditional software licensing to cloud, the rise of SaaS, and the shift from subscription to usage-based pricing.
[00:00:00] INTRO: Welcome to Unpack Pricing, the show that deconstructs the dark arts of SaaS pricing and packaging. I'm your host, Scott Woody, Co-founder and CEO of Metronome. In each episode, you'll learn how the best leaders in tech are turning pricing into a key driver for revenue growth. Let's dive in.
[00:00:23] Scott: All right, Sam, thanks for joining us today. Really excited to have you here.
[00:00:28] Sam: Excited to be here. Thank you, Scott.
[00:00:30] Scott: Awesome. For those of you who don't know, Sam is a expert in monetization. I think most recently he spent about four and a half years at Snowflake, and before that worked at kind of leading pricing companies in the cloud space in Microsoft and ServiceNow. So thanks for jumping on the pod with us. I want to start with a relatively easy question, which is why is properly pricing so freaking hard?
[00:00:52] Sam: That’s a great question, Scott.It's hard because I think it's really three things, right?
One is that it is a multidisciplinary domain and it spans really wide also goes really deep. You know, if you think about who is involved in pricing and what's goes on, there is really, like, some part product management is a large part of finance, but there's a lot of sales and marketing and like operations involved as well, right, to launch something in the market. You're touching a lot of different parts of the market. So, the effect of pricing leader and really effective anyone working in pricing, you kind of have to speak all these languages to get all these teams to work together. So, it's just a really difficult sort of interdisciplinary domain to really get right, right? You have to kind of bring a lot of people together. You have to get them to coordinate and then you have to really be able to speak the languages. It's also highly strategic and highly tactical at different times, right? So usually often at like different stages of the same projects, you start off with something being very strategic, and then you might jump into a next project... the next phase of the project that's becomes very technical and very... you have to go very deep, right? So there's this constant spanning wide and going deep kind of motion going on. That makes it very difficult to do. The second character is, is both an art and science, right? There's a huge analytical component to it. There's a lot of quantum research, but you know, a lot of pricing, if you have the, at sort of at the, at the very high level, it's really about incentive power structure, even down to like organizational, or if you're doing B2C, then the consumer psychology being a matter is a big deal. And those are, you know, a lot of this consumer psychology studies out there, lots of quantitative studies out there around pricing, right?
So it's a very interesting field that touches both the left brain and the right brain. . The last thing I'll say is like, people think it's hard because it's a little scary. Pricing is one of these, like what I call sledgehammers that you have is not a scalpel. It has this potential of having this really wide glass radius of effect.
You know, if you think about the really basic equation, revenue of a company equals price times quantity. Then, your price is literally the multiplier for the entire business, right? So as a result, you know, every little changes can have this massive impact on so many functions, so many teams. And so people are sometimes reluctant or a little scared to make the bold changes necessary.
The other part is also, it raises the coordination problem that you just, it affects everybody. Everyone wants a say in it, so navigating that decision-making process, navigating communication path, become exponentially more challenging as you know, company scales or as a company, you know, business becomes more common.
[00:03:22] Scott: Cool. Okay. So there's like a ton in there that I would love to kind of peel back at least a layer or two. So, I think one of the first things you said is pricing is hard in part because it's a very multidisciplinary function. So in your mind, does that lend itself more toward like a functional organization that's like really focused on pricing or is it more of a horizontal organization where you're kind of pricing is best done as like a collection of maybe a person over here in sales, maybe here product, maybe . Over in marketing, we kind of work together as a pricing council, like Or is that a false dichotomy?
Like what's the ultimate, you know, in your mind, org structure for actually accomplishing good pricing?
[00:04:01] Sam: I've seen it done both ways. Both well, and not so well. The pricing function, I think, is a center of excellence, but like any strategic organization, I think the job is to be a horizontal function that touches everything.
So I think you, you really do need a group of experts to coordinate the work, but though, but the pricing team can't do everything, right? Like they, they really, you know, as a service organization, you really are not... you have to work with the PMs to drive the business case. You have to work with finance to drive the business model, financial forecasts, you have to work with sales on, you know, making sure that the way it lands is correct.
You know, there's a sales enablement aspects, how it affects compensation, how it affects sales operations. You know, those things all need to be worked through these teams, right? So there's a centralized sort of center of excellence component of driving these, these functions that there is very much a, really not much needs to be a cross functional thing.
So, you know, being a pricing kind of function person, you're a large part of your coordinator and a project manager, but you are also, you know, setting the tone and driving the narrative for the company.
[00:05:07] Scott: Right. I’m curious, whenever I see these kinds of large, really cross functional kind of projects, I'm always curious, like where, like how much do they need, like a really strong executive driving force to kind of push it through? Is successful pricing, like, always a top-down thing, or are there ways of having driving pricing changes that are much more like bottom-up or kind of like lateral kind of collections of folks. Like, is it always like the CEO needs that like has to drive or are there other ways of kind of successfully driving pricing initiatives?
[00:05:46] Sam: I think it depends on the altitude and types of pricing projects. I know that we get into a lot of 'it depends', but it is true. I think, for a lot of pricing projects, anything that touches a price point again, because of that blast radius issue, it really should require a pretty senior, like strong senior level visibility, right?
And frankly, for public companies, this pricing is considered core business control. So, you have to have a strong governance policies around how to make these decisions. Something that is important. And for many types of pricing projects, you know, you may not be a CEO, but it might be a group of executives, but you do have to have senior leadership be the decision making body, right?
So a lot of companies stand on what's called pricing committee. Sometimes the CEO is on it, sometimes it's not, but usually I think that's what a lot of really smart people would say, you know, best practices that have the CEO, CFO, Head of Sales, Head of Product. Those are, kind of, the four, leaders that, that really cares about pricing in different ways,
Right? So that's usually how it's managed. Now there are other pricing projects, you know, especially as a company scales, that doesn't... shouldn't, doesn't know, or it really isn't appropriate to go to the C suite, right? And so as the company scales, as the function becomes more mature, you create more empowerment, kind of layers to allow for more tactical decisions to be made at a low level to maintain agility. And I think the evolution of how you evolve that, uh, policies and control is a, it's one of the core job of a pricing leader, and certainly you have done that Snowflake in a number of places.
[00:07:16] Scott: Very interesting. One last question on this is cause I'm so interested in kind of the, how effective pricing leaders work. What do you think are the one or two kind of meta skills that you, like you specifically needed to have in order to kind of handle the both super broad problem space, but all this is super deep art and science, analytic and like incentive understandings. Like, what are the skills that you uniquely have that make you effective in that kind of organization?
[00:07:45] Sam: Yeah. I think one thing that I have that is somewhat unique is that I sort of have experience working from an organization, from some product management, already the sales I've reported into.
At this point, a product team, sales team, finance team, marketing team now have that background and understands kind of leader. How these leaders think and really the language they speak, right? So, like, being able to do that and recognizing sort of what's important to each of these functions, I think it's a, it's very important.
I always sometimes joke with my friends that I sometimes like the translator between all these organizations. I kid you not. I've been in meetings where for 20 minutes, the Engineering lead and the IT lead were using the same word by saying different things that they weren't recognizing and talking over each other.
And then sometimes you're gonna have to step in and tell them that, you know, what do you mean by this? Do you mean that? And before they, they still recognize it. So I think that's a really important skills is to, you know, be able to effectively speak the language of these different teams. I'd say the second thing is that pricing, especially at tech companies where I spent my career, you have to love the product, you have to love technology. So in a sense, it's not a function where you can get away with by being sort of the domain expertise. You... you really, you know, I guess, especially because you have to work so closely with the product.
And, and really sometimes the engineers, you, you have to be pretty technically, you know, competent or, or fluent in at least their languages. And so... so in a sense, you know, if I, when I'm hiring a pricing manager, I look for very much the same skillsets as product managers say, especially folks that are working on the inbound side of things where they're working on the core pricing packaging of products, their skillsets are like 80 percent overlap kind of product people.
[00:09:34] Scott: Oh, okay. That's actually... that's kind of, Maybe I don't think super intuitive to everyone. So what I'm hearing is that to be an effective pricing expert, you actually need to really understand the product itself and I assume how it's consumed and why people are using it. Do you have a kind of a good example of how, you know, maybe take Snowflake or one of the previous products you've priced, like how your understanding of the product that you helped you get to a better pricing outcome by having that expertise.
[00:10:05] Sam: Yeah, I'll give an example of when we are looking at pricing for the Snowflake Copilot. The short architecture of how Copilot works in terms of the prop and the prop engineering and the additional token that's being injected into the system. And even, you know, it's a two-pass LLM. They pass through two different LLMs in order to try before the results comes out.
Really understand that is, and understand that to a pretty sophisticated degree, both in talking of engineering and talking with product. It's really important, because A, it impacts unit economics, right? You know, understanding how these, how much token, how many extra token you're injecting into the prop and all the other things that really drives it.
So it, it drives the financial model to a very sophisticated degree. And the second thing is also it drives a different use case, right? So you, you sort of have to learn to ask all the right questions around how is customers going to use it? What is this going to actually do? How is this going to help the customers?
Because again, like, all these are being used and what is... what the product is capable of, what the feature is capable of, drives the value proposition of the product. So in a sense, you have to be able to ask those right questions in order to sort of guide the product leader or the engineering leader to understand what they want or what they're missing from their business case, in order for you to sort of propose what type of studies or analysis or modeling you need to do in order to kind of build the business case and build the right pricing.
[00:11:30] Scott: Okay. So it's like this like deep understanding of the product that sounds like even the technology. Also definitely how the customer gets the value from it. And what I'm hearing is a little bit of a feedback loop between okay, what does the product do? How does the customer experience it? And how are we going to price the value?
[00:11:49] So basically like kind of mapping, you know, the price to the value and then the product experience needs to express both obviously the value of the thing, but it needs to be coherent with whatever your pricing unit is. So, you got to, you got to make sure that the entire package is a coherent feedback cycle where it's not driving a bunch of usage that then is un-monetized or leads to a mental model mismatch between I'm not really getting very much value and you're charging me a lot of money for this thing.
[00:12:16] So, I'm really curious if you've, in that world, like, how early in a product development cycle do you think pricing should be involved?
[00:12:25] Sam: I'd say as early as possible. Every company I've been at, I've pushed for. The, at least me or the pricing leaders to be part of the product ideation roadmap. So, I would love, ideally love to have visibility a year, a year and a half out into at least what's being thought of.
And partly because I think, especially for larger companies where priorities gets booked up a year in advance, sort of planning and other organizations are done, you know, on an annual basis. So, it's important to have, like, visibility and to sort of the capacity and the capabilities that you are all parts of the organization, right?
So, you know, it's good to kind of have those early on and be able to identify potential proposals that could have large impacts on the business, and then loop in the appropriate people. So in a sense, I think a little bit on the PM side of things. I've heard other people says that pricing manager, pricing strategy people are like product managers with like a different spin.
They instead of focused on the product, they really focused on the system. Right? So, the overall feedback loop of the, of monetizing that, the product would have helped. So the other thing is, you know, while product focus on creating the product and features that delivers a value, what pricing manager does to help augment and helps help the product team as they create those values, to bring in these outer contexts, bring in the context of the finance team, bring in the context of the overall company strategies that's outside of the scope of what the PM thinks about and bring in sort of the context of the capacity of IT and others that downstream business requirements that, that needs to be considered.
So that's really, you know, again, same skillset, same thought process, but applied to a different way.
[00:14:10] Scott: That makes a lot of sense. So in a way, pricing, it's very um...like akin to the skills that are needing to be a great product manager. Do you... have you seen examples where like the two are merged? Is it possible that you could have one person who's both a great product leader and a great pricing? Or is it, is there some like kind of necessary distance between the two to get to the right answer in your opinion?
[00:14:33] Sam: No, I think most of... I've seen many great pricing team built out of the product organization. So in fact, you know, I say since I've been leading pricing and building pricing teams, majority of my career has been spent in the product organization, right?
So I've always been at Infoblox, I was on the product leadership team, reporting directly to the CPO and then at ServiceNow and a good chunk of my time there, I was, uh, I was in the product management organizations. So either way, you have to be pretty embedded, regardless of where you sit. So that's a really critical relationship, especially given that most product company, most technology companies, are product-driven and you really have to be embedded with them.
[00:15:12] Scott: Well, one, one follow-up question I would have that I've like, I think is always very challenging when you're bringing a new product to market is finding the right unit of value or value measure, especially in a usage-based business. And so, you know, I think it's all well and good when you're kind of entering an established product space.
And it's like the kind of de facto way of thinking about values already been established. But I would love to hear how you would advise someone who's kind of maybe doing something that's like net new in the industry, how to start to make head roads into a good value measure for their pricing, if they want a price to value.
[00:15:51] Sam: Yeah, I think, one of the things I would say is the value metrics or the metrics that you miss, especially in regards to usage-based pricing, there are really two, I guess, top level requirements or criteria. One is that it should align with kind of how the customer's perceived value, right? So, ideally you want to make sure the scaling of it is something that customer understands and that customers sort of almost intuitively recognize that, yeah, like it makes sense for me to pay more based on this, right?
So you can't, you can't clear that bar then you're in trouble. The second thing is, ideally, it's something that scales with your cost as well. Now, that's, this is a little tricky because sometimes those two things could be orthogonal, but ideally, you don't want to be priced on a metrics that doesn't scale with your cost, right?
It's sort of one reason why, you know, a lot of these SaaS companies today that are all in pure usage subscription-based pricing are struggling or really are really thinking hard about their pricing model because AI, that potential to lower the number of users, right? And then also the cost of AI is really scaling based on tokens, for all the B2B companies doing API calls to OpenAI.
The tokens is this proxy of usage for compute on GPUs is... it scales orthogonally to release from users, right? It could be one user's using a lot or many users using very little. It's a very different way of scaling costs. So it's something that you really ideally want both of these things that to occur in the enterprising metrics.
[00:17:18] Scott: Cool. Yeah. So I guess kind of taking the first one, like finding a value metric that makes sense or resonates with the end user. Do you have any kind of tips or like in the early days, how to like explore, you know, Snowflake has a very specific way of talking about value. I'm curious how that was discovered.
Was that like something that kind of came to market and like, we're going to just sell it this way. And this is the right way. Or was there like a market discovery process and like, When you're thinking about launching a new product or launching a new kind of, you know, usage based product, how do you go through that discovery exploration process?
Is it like user interviews? Is it like a top down taste? Like what's the, what have you seen work when just like when trying to like pioneer a new usage or a unit of value?
[00:18:09] Sam: Often the customers is good, right? So early adopters is really important. In the case of Snowflake, it's really interesting because I don't think there was this... Snowflake was consumption from day one.
It was... there was not even a discussion. It was a core philosophy that Benoit and Thierry, the founders had, right? They set out to build a cloud native data platform. And if you look at what, you know, if you look at, you know, if you're going to design a database or a data warehouse that runs in the cloud, you look, I see model of these cloud providers and they're all on consumption base, right?
So, again, like the hyper-scalers have been on consumption since day one. So I think, I don't think there were many discussion or any at all from the early days where they're going to go consumption. So Bob Muglia, the CEO before Frank, he was kind of a big believer in the cloud as well, I see even since his days at Microsoft.
And I think he recognized very early, you know, if they can mirror the economic advantage that these hyper-scalers have around, you know, the pay as you go, really pay for what you use. That can be both a very powerful message and really powerful economic driver and kind of advantage for the company.
So it's really something that sets the tone from the beginning and it's something that I think Snowflake really hit that the farm on early on. When I joined Snowflake, there was no, no debate about, you know, whether there should be consumption or not, but by the end it was very much a hundred percent consumption driven and it turned out to be the right bet and it was very successful.
[00:19:32] Scott: Yeah. I feel like a large part of the, if you read like analyst literature and you kind of just study the physics of that business, it's like a consumption-based model is like one of the huge reasons to say, yeah, this is like a successful business and it sounds like they kind of lived at a philosophical level in the early days.
I'm curious if there were any edges to that philosophy that kind of made certain things hard, cause whenever you have a philosophy, there's like benefits, right? It simplifies a lot of things, but then it also closes off like possibility space and others. I'm curious if you ever kind of ran up against an edge of the philosophy where it actually got really hard to do certain types of things because of this pure usage philosophy.
[00:20:11] Sam: Yeah, it is not easy, right? So. Paying for what you use a very powerful message. I'll go over the advantages first and then go over some of the disadvantage. It, it helps lower, I think something we learn over time as a company was that it's really advantageous because it lowers the barrier to entry and so removes that doubt about value delivery, right?
So for example, with ServiceNow, there's always talk and worries about, Hey, are we over subscribing? Are we over licensing users? I'll be, is there a lot of shelfware that, so even back in Microsoft, when we're selling licenses, there's always talk of like these vaporware shelfwares, these phantom licenses customer spot, and everybody utilizes that risk. With consumption pricing model, it's you don't have to worry about that. There's no question on that. You only pay for what you use. So that's a very powerful message that allows you to kind of roll, grow efficiently, grow leanly, like, you know, your revenue is high quality as much as, you know, there's not a lot of kind of extra slack. The other thing that sort of turns out to be extremely powerful for Snowflake, and I think other companies will discover as they do the usage based pricing, is that consumption based pricing, at least the way Snowflake does it, it unbundles the sales motion from the procurement motion.
And that's a very powerful thing to do. So, you know, for example, with Snowflake, for a lot of the enterprise customers, once the contract is signed, any incremental new features, you could custom, like a product can launch out these new features while launching new SKUs, right? So you just put in the consumption table, you update it. The customers, the minute you GA, customers can start using it and then start paying for it really, or start consuming it immediately. So sales can... the sales motion becomes this continuous cycle where you're, the sales team isn't aligned to, you know, driving a new, it's not nearly, it's not necessarily just looking for to sign a new contract or if customers want to use the new features, they don't have to like wait to like go through a procurement process, buy a new SKUs. They can just start doing that. And so, you know, sales, job of sales, when you're selling, you're really looking for new workload and driving new workload into the platform. And that can happen anytime throughout the year. So I think it's vastly simplified, like the procurement motion and also accelerates the times of value and also times of revenue for new features.
Now under disadvantages, of course, like there it's a lot harder to forecast.
[00:22:29] Scott: We just talked about all of the nice advantages of having a usage-based model internally.
What are some of the challenges that come with being a pure usage business, especially at a scale of a company like Snowflake?
[00:22:40] Sam: Yeah. You know, there are challenges in the sense that I think it's hard to operate. It's inherently harder to track and harder to predict than from a revenue forecasting perspective, so consumption-based pricing is very challenging, right? At Snowflake it took a long time and frankly, a lot of sophisticated data science and modeling to really get to the point where you can forecast via public company.
It is also harder for the complexity of the workflow to make sure you are metering and billing and rating the customers correctly. It's also very critical. So there's inherently sort of a large, larger kind of overhead to making sure you do that. So that's a challenge that a lot of companies obviously don't know how to meet. They don't know how to organize the work to make sure you do that effectively. And, you know, and everything has to work right? If you, if one thing breaks the entire getting revenue from customers. So, it's pretty critical. It's also, you know, I don't know if there's an advantage or disadvantage, but, you know, it's shortens the product feedback loop in the sense that if something is not right or you ship the bad product, you will know right away. Customer's just not going to use it. So in a sense, it's really scary because you are, you know, you're, you're really constantly exposing yourself to a customer churn all the time. You're not locking any customer in, but at the same time, I think if you're able to live with that or acclimate to that, then I think over time it helps the company build better products.
[00:24:00] Scott: There's actually, you said two things there that I think are super interesting and kind of at least unintuitive, even to me, which is the first you said was in a pure consumption business, it actually... it makes it easier to continuously insert value into your product suite. And this is like hits home for me cause I... before this, I worked at Dropbox and every time we launched a new feature, it was always like, well, should we give it to the free tier? Should we give it to the paid tier? Should we give it to the team tier? Which of those should we do? And it was always like a really complex calculus. And what it meant was that it was actually quite hard to go launch new features and get feedback. And so if something was speculative, you really had to be thoughtful about like, what's the up... how is this going to change our upgrade cycle? And what I heard is that in a usage model, it's actually the incentives are aligned. If it's useful, people will use it and they will then therefore pay more for it. And it can kind of like lower the friction to deployment.
So, I would love to kind of hear a little bit about how in practice that you think that changed the product development process or the launch process at Snowflake. Did you have big bang releases or was it more of a continuous process? And like, how did you think about like incremental value being stuffed into the product?
[00:25:17] Sam: Yeah, all three at the same time at Snowflake. So, I'd say for the most part, values are being injected into the features and packages continuously. Both in terms of, you know, just frankly, something as simple as making the efficiency gain in how the software writes where you're passing on a lot of this efficiency gain savings to customers, thereby they, for the same amount of stuff like credits or people they consume, they can run more queries.
New features are, we have the same debate, right? So when product launch a new features, you know, stuff like, 'Do you have sort of good, better, best additions', right? The standard enterprise and business critical. And there are constant debate of what do we put, which edition do we put it into? But it's not really about... the interesting thing is like, even though we're debating which features it goes into, we never have to worry about customers not paying for it because if those new features drive incremental use of compute, they are paying for it because those, those additional CPU cycle times gets accrued and they pay at the rate that, you know, those other need are on. So that becomes a very advantageous and very powerful message.
At the same time, you know, there are brand new kind of large big bank leases, right? Whereas Snowflake goes into a new workload, we're driving a, for example, launching capabilities on a whole set of new compute primitive
[00:26:42] Scott: I think one, one area in that vein that I'm actually kind of... , you touched on a little bit, like, how do you think about what changes about operationalizing a pricing change in a usage model?
So like, what I'm thinking about is how does a usage model change the incentive behavior for what an AE should do or an AM should do? Like, you know, theoretically it should. And so I'm curious, like what the, like maybe unintuitive parts of being an AE at a Snowflake or a pure consumption business are that might differ from a, you know, maybe a traditional kind of subscription- or license-based business.
[00:27:18] Sam: Yeah. Sales incentive and sales planning becomes different. And it's something that I think Snowflake evolved quite a bit over the years. The revenue in a usage-based company, especially a pure usage-based company like Snowflake, is tied to consumption, right?
So really, when a customer pays you, especially if they're paying a contract up front like most of Snowflake customers, dollar collections or signing the contracts around gaining bookings or RPOs, that has nothing to do with revenue. So in a sense, incentivizing the rep to sign a large contract or get a large commitment from customers isn't necessarily a good thing, right?
Especially if there's no plan behind how customers actually going to consume. The real metric is around consumption and how to drive consumption. Over time, you know, Snowflake has certainly evolved the sales compensation model to more aligned to the consumption. It took a while to get there. It also becomes somewhat unintuitive in the sense that you almost have to treat what's something called greenfield versus kind of brownfield type customers differently, right? So established customers where you have already sold into the account and you're just looking for to expand out of it. That's really about driving incremental consumption, incremental workload, and consumption is a really great unit of measure for evaluating the sales productivity and rewarding sales productivity.
[00:28:34] Scott: So maybe talk a little bit about kind of…the difference between like, you know, you have large accounts and driving incremental workloads versus net new logos, maybe smaller logos. Were those separate reps did like, or did a given rep both, you know, hunt and farm, and it was just like a mix of their time?
Did you actually find a specialization in reps or how did Snowflake approach those kind of two very different ways of growing a book of business?
[00:28:59] Sam: Yeah, that's a really good question. That has evolved over time. I think early on Snowflake sort of have really compensate rep on what we call net new ACVs, you know, net new growth on the contract.
And then over time, we found that that's less effective because again, you know, revenue is really tied to consumption. So you really want, especially the more mature reps and more mature accounts to be focusing on growing kind of consumption because that's what it's tied to. But for smaller companies, for especially the reps that are focused on territories that aren't more, that new logo rich.
That's where we still sort of have elements of compensating them to sign new ACD and locals and that can net new tokens because again, compensation for a lot of these smaller accounts may not materialize right away, especially for net locals. It takes a, we... what we found is that this takes, you know, usually six to nine months for consumption to really ramp up.
[00:29:52] Scott: Do you know if reps basically stayed attached to deals after the, like, cause again... it's like, you know, in the beginning they might start the beautiful thing of consumption that they start and they have no spend. And then maybe they have a commitment. And then if the customer commits and then just never uses the product, then, there's no value created.
And probably that customer is going to churn at some point. Were reps kind of incentivized to stay attached and help make sure that initial commit actually translated in to usage or do they hand it off and it shifted to more of a traditional account management model?
[00:30:23] Sam: So one quirky thing about Snowflake, and this is a Frank Slootman thing, is that we have no customer success team at Snowflake for kinds of areas with every adamant about this idea that it's everyone's responsibility for customer success. And that sort of makes sense.
And so double down, we'll speak with in consumption- or usage-based pricing, because you don't recognize, so you have no revenue unless the customer actually uses it. So the sales cycle doesn't stop. You're both trying to stay in and drive new workload, but also at the same time, you are cutting, making sure like all the reps and all the SEs are on a plan that's tied to consumption.
You're also incentivizing them to make sure that they are consuming to plan, so to speak. So really driving that alignment has been very critical for Snowflake's kind of growth and success over the years. Now, there are skillset differences and, you know, what Snowflake has also discovered that hunters don't like to farm and hunters don't like to hunt.
So, there are specialization issues that we're discovering over time that needs to be fixed. So there is a recognition that there may be AEs that are more focused on kind of the customer success motion, versus AEs that are out there trying to acquire new business, acquiring with Snowflake, but I certainly are seeing inkling that we might create pseudo customer success team within the sales organization, you know, going back full circle.
[00:31:42] Scott: I see. I see. Well, I do think that kind of like everyone's in customer support does align to the usage based philosophy in a way that you said. So I think that's a nice, coherent worldview.
I'm curious. I noticed you wrote some blog posts on usage pricing. And one of the things that I saw in there was kind of this framework around how to price in terms of resources, utilization, activity outcomes. I'd be curious if you could just kind of explain the high level framework, and then I'd love to dive into a couple of details of the different ways of doing usage-based pricing for companies.
[00:32:21] Sam: Sure. I think it's really an exploration of, and then helping to recognize that, you know, not all usage metrics are the same, and broadly speaking, when you're, when talking about usage or consumption can really be measured based on some input and output. So, you can be metering customers or you can be pricing metrics that are tied to more input-oriented activities, or they can tie to more output or out, out of the activity.
And we then expand that and say, 'Hey, like maybe there are maybe four general categories of potential usage metrics out there'. Or one, say, most tied to consumption of resources is really, you know, pricing to resources, pricing to the activity and pricing to activities where you're pricing to the, you know, like AWS, you're pricing to the number of seconds that you're using on the VMs or another terabytes consumed. That's kind of pricing the resources, right?
And then pricing to activities is this idea of some kind of usage or proxy of consumption resources, right? So, Snowflake, for example, if you're talking about Snowflake credits, that's pricing to activities. It's a proxy for a Snowflake that is really a proxy of the resources use and it serves as a measurement of compute and utilization and activities that's on there.
Tokens is another, if you look at AI. Like tokens is an activity based metrics is that in terms of it's really placed about four characters, right, on the Chrome and in and out. So those are the activities. And then, when it goes to kind of pricing to output, you'll be seeing a lot of startups in the airspace and Synthesia is one where the pricing to the number of minutes of videos being generated, right? So this is now you're shifting to more sort of value-centric type pricing, so the more cost-centric pricing where pricing to the output of the applications or services. And then, if you're really kind of on the far end, where I guess where sort of from a pricing practitioner perspective, you're where you can be most aligned to the value of what you're trying to price out, you're paying for the outcome that you desire, you know. The most prominent example out there is today's Intercom's Fin where there was a customer service agent.
They price based on the number of call resolves the customer service call, right? So that's a very powerful way of kind of really aligning outcomes to the value and aligning that monetization. But, you know, that has challenges because it's oftentimes really hard to... there's an attribution problem of 'Are you sure this is... you can attribute the value solely to the application, not to the value that this AI provides or the software provides. So, you know, oftentimes that's difficult. So then, that's kind of the high-level spectrum. There's a survey of, you know, thinking, getting folks to think about, hey, the artist spectrums of usage metrics and really finding the right one is something that you should be thinking about closely as you go and try to build a product and figure out how to price it.
[00:35:10] Scott: Yeah. The thing I hear a lot when talking to folks in Silicon Valley is the outcome-based pricing. But when I look, I actually think the examples of successfully doing this are very rare. And so one problem you mentioned is the attribution problem. It's like, really? Did this software do this or did the human using it, do it? How do you think about that?
Do you think that's like a education and kind of bake time thing, as AI percolates and sits for years and years, we're going to all agree that this is the outcome? Or is the outcomes more of it specifically works in very specific instances, but mostly like you should be thinking about input output or activity based metrics.
Should companies try to get to outcomes? Is that like ideal or is it more of like a, you know, only in certain circumstances type of business model?
[00:35:58] Sam: I think only in certain circumstances. I think you're gonna find, we're gonna find spectrums of AI. I think you're not, I know especially in investor class, and you know, the VCs, everyone's really excited about the agent stuff that's coming out.
I know a lot of companies are saying we have AI agents, but doing, they're not there. But it's certainly coming where you have these more sophisticated AI systems that can sort of work on complex workflow and complete complex workflow. And for those type of AI that's working to automate or working on complex, really complex tasks that involve multiple steps and making decisions, et cetera, I think there's more possibility of driving, using a outcome success based pricing model. But at the same time, if you look at a, let's just pick any large workflow company like Salesforce or ServiceNow, they're going to have AI eventually everywhere, right? There might be some type of AI agents that are... that they'll be offering, but their core businesses and their core products and suites of services.
[Also we'll have a lot of AIs. They're really not designed to automate, but really designed to assist human. And in those cases where they're completing a task of generating content or they're summarizing tickets or what ServiceNow is doing, you know, but the outcome pricing is nonsensical because really it's about human productivity, right?
So, I think you will... you're going to have, I think all of these... I think models will have its place based on how AI and these FTP launch language models are going to be used in the product. Going to be used to assist the human or help human do better. Are they there to generate content or are they there to automate workflow?
I think each of these I've been calling, uh, modality of engagement of how they engage humans and how they engage... deliver value for companies and customers will, I think, drive a lot of these pricing models out there.
[00:37:54] Scott: That makes a lot of sense. It's ultimately you have to really understand how the customer is going to value the product and make sure you find the model that is best aligning price to value.
But I think the other aspect of AI, at least right now, that's super interesting to me is that It's also really expensive, typically. And like the costs are definitely input based and output based. And so like how, what's your advice for companies that are kind of thinking about adding AI into a product line?
Maybe let's say they have a seat model and they're adding an AI to kind of do some gen AI stuff. Like, how do you think about pricing in a world where the underlying resource utilization is extremely expensive in a way that's like pretty different than, honestly, most technology?
[00:38:42] Sam: Yeah, I think it's an area and it's a topic of, that's being vigorously debated in the market right now. Certainly, I think a lot of companies have come to the conclusion that we need to start thinking about a usage-based model or some kind of hybrid model where you have usage limits or usage caps or some kind of usage metrics that scales with kind of some of these AI usage, because to your point, yeah, a lot of these... the cost of these AI scales differ from the user.
And then there is also this risk of the automation and AI really over time creating a situation where, you know, there's just going to be less user required to be using the software. So, that's one of the kind of like main implications of the cost side of the equation for AI. The other interesting thing I think will happen is that AI is also making software easier to write and faster to write.
So, with Copilot and other things, you're going to just solve them like a feature is over time, I think, has the potentially more commoditized. So, in a world where you are becoming more commoditized on your base features, think about what that means for a company like Upwork or ServiceNow. Other companies or competitors want to copy your features are going to be able to do it faster, easier, cheaper.
So ,you do have to find new ways to create new packages that would value differentiations. And you're going to have to stick to say the better, best package features may not. Like your traditional software features or use cases may not be the right kind of ways to create these value differentiations for it to try to tighten up that type of optimization.
It's what it's going to take its place. So AI might be a place where there can be different value differentiations that can be created based on these service offerings. So it's a very interesting dynamic. And these AI and then, you know, it becomes this positive feedback with the caps that goes on and say, you need more AI to drive more feature differentiations in the future.
And your offering also puts additional pressure on the usage pricing model. And because AI services scales differently with these and with usage, right? So, I think there'll be a very interesting transition to for a lot of these companies to figure out how do they, in the short term, retrofit their pricing model into AI in mind... aI services in mind.
And then over time as these, I think, AI services becomes more important and part of the value chain that they did or the value that they deliver, then, you know, how does that impact the business model over time?
[00:41:10] Scott: So, a lot of people are paying attention to this stuff. They're kind of maybe like they're a pricing expert. They're sitting inside a company that has a pretty big business, like a couple hundred million in AR, let's say. And it's a subscription- or a seat-based model. And, let's say that person's looking to kind of explore or maybe potentially transition to usage pricing. What would your advice be for that pricing expert to kind of even just start the conversation?
How would you advise, like, what are the analyses or the things that they should be doing on day zero to kind of prepare for the potential move to a usage based model?
[00:41:46] Sam: Yeah. I think the first thing is to really understand the AI roadmap. We alluded to this earlier where AI can be... there can be different ways of AIs being used, right?
So really understand what is the use case? What is the value that these new AI systems that the SaaS want to incorporate into your product? What's it going to deliver and really understand that roadmap and understand the cost element of these roadmap, because making an API call to OpenAI's relatively cheap on a per unit basis, but if you're doing fine tuning, you're doing rag, you're doing all these more context specific use cases, then all of a sudden this, these costs can be exponentially more expensive.
So really understand both and then we'll ask the question of, or really force a conversation around, is this a net margin accretive strategy or margin dilutive strategy, right? So, really understand is this something that's going to help make the company more profitable, less profitable and what's the revenue potential there?
And that should be the starting point of how every company evaluate AI. And, you know, at least that's certainly one element, right? So there's, there are other issues that should be brought in around competitive dynamics and the market pressure of kind of doing these things. So those are all important, but certainly really understand how AI alters the unit economics of your business and the revenue potential and the ones to pay, really pay attention to that.
And this is a rapidly evolving space. So, I think people are still companies are really still discovering like product market fit. And really problematic pricing of AI and how they use it in a way that drives the most value for the company and the customers. So something that I think, you know, this is a conversation that's going to be repeated over and over again at many companies.
[00:43:26] Scott: Are there skill sets or like types of people that, that theoretical subscription organization might not have. And that like, in order to execute what you're saying might need to go... talent that they might need to bring in. Or do you think it's like, You know, the traditional kind of strategic finance or pricing function can be adopted to the usage based modality?
One thing I heard very strongly is in a usage based context, you really have to understand the unit economics in order to price properly. In a seat model, of course, you need to understand it at some like gross high level, but in a usage based context, it's really like the kind of one of the dominant factors and something you have to be like very front and center.
Are there other like pieces of information or kind of philosophical or operational things that you know, that you might want to bring into your organization as part of thinking about usage pricing?
[00:44:18] Sam: Yeah, I think the general strategy and frameworks used to price other products applies to AI generally the same way.
So my comment is really more about usage based pricing in general, like regardless if AI is part of the picture or not. I think it's really important for pricing managers and pricing leaders to have a deep appreciation of the... that the operational mechanics of usage-based pricing, it's more important than ever where you can't recognize revenue unless you understand how it's being metered, how something... how telemetries are emitted, how things are being metered and rated and, how that connects to the downstream system is something that is, again, like if one thing breaks, everything breaks within that workflow. So I'd say, you know, in the world of usage-based pricing, I think pricing leaders needs to... it's a focus area that's, that cannot be neglected.
Product managers typically don't have a good... sense or good... have large expertise on a lot of downstream systems and how they affect kind of monetization. So it's up to kind of the pricing leads or really people who are doing this job, regardless of what we call them, to help compliment the product leaders, to help them understand, whose job it is to emit telemetries for rating these products and drive the usage statements for the customers and, how does this all connect down to the downstream systems and around revenue recognitions, around collections, around invoicing, right? So understanding that workflow very clearly, I think it's very key to success, right, in terms of execution.
[00:45:55] Scott: Awesome. So, it sounds like if you're thinking about a usage-based model, data fidelity, data workflows, data integrity, become like critical things that need to be threaded through the entire stack from where the telemetry originates all the way through down to how the revenue gets recognized. And you need to make sure that that data is there and track the entire time. It's like a really... I strongly agree. I've seen many companies that have not, you know, had to solve that problem.
And as soon as you move to usage, it becomes like a problem that you straight up cannot operate the business unless you fix it. So I strongly agree with that. Well, this has been great. I would like to close on one question.
You're obviously sitting at the forefront of a bunch of like big trends- AI, usage pricing. What's one unique idea or one idea that's you want to put out into the world that you wish more people would spend more time thinking about that you think is key to the future of pricing in Silicon Valley?
[00:46:54] Sam: Yeah. And this is still very speculative, but one of the implication of AI and Sam Altman this, right? Like large language models at the end days kind of like compressed data, right? Like, there's this data of highly compressed into a model for to run inference. And because AI at the end day is just data, one of the implications that AI can potentially alter the commercial relationship between software vendors and their customers, right?
So in a sense that the value exchange becomes not one way. Customers now have these datas that frankly the company wants to need to kind of train and build and really continue to evolve their AI services. So, it becomes this more bilateral motion of value exchange, not just 'you're a software vendor, you deliver value, customers, customers pays you money'.
Now there's this other component of, yes, you're doing that, but at the same time, customer also has some data and some asset that you want. And frankly, you know, as these AI models evolve and these AI services evolve, probably you're required in order to create differentiations because if everyone is on ChatGPT and running kind of the pre-trained model, then there's no differentiation in the AI services, right?
So, to create these enduring differentiation, you really need more kind of private, more... so these usage data that are more tied directly to your company's specific contents or the specific use cases. So what does that mean? I think, that means from a pricing strategy perspective, I think, leaders will start and then have to start thinking about not just acquiring revenue, but also acquiring data.
So, data acquisition needs to be part of kind of the equations that we think about the value exchange of the companies. And so, how does dynamics impact pricing. And, you know, as the... especially these more sophisticated AI systems are more context area, context trip, how it's going to be used, are they going to be used specifically for the customer itself? Are they going to be allowed to use outside of that to train and fine tune the broader model That will be really fascinating to watch in terms of where things are. I certainly think because there is this new element of customer having something that companies want, I think that alters the commercial relationship.
[00:49:07] Scott: Very interesting. And I look forward to this new, weird, interesting future where companies are both, they're paying us for our data and you know, we're paying them for their services as like a super fascinating model.
[00:49:21] Sam: Exactly. So that's... it's all this... you can almost imagine a world where you might pay one price if you want your data to be private, or you're allowing your data to be used in some way to train a model, then maybe you pay a different price. Who knows where else this will go, right? This is me thinking ahead.
[00:49:37] Scott: Very, very cool. I think this is what I love about this space is that the kind of commercial product functionality, AI, it's all combined in this weird, nice kind of stew, and I think, the only thing I can predict is that the world's gonna look really weird really fast and I'm very excited about it.
So, Sam, thank you so much for your time. Maybe, before we go, where can folks find you? What's the best way to kind of learn more about what you're up to?
[00:50:03] Sam: For the most part, I'm on LinkedIn. LinkedIn is probably the best way to reach me. I am on Twitter, but it's mostly a private, like, personal account. Yeah, LinkedIn is probably the best way.
[00:50:12] Scott: Awesome. Well, I really appreciate it. This was a fun conversation. And I hope you have a great weekend.
[00:50:17] Sam: Thank you, Scott. Thanks for inviting me.
[00:50:19] OUTRO: Thanks for tuning into this episode of unpacked pricing. If you enjoyed it, we really appreciate you sharing it with a friend. We'd also love to hear from you. Feel free to email me at scott at metronome. com with feedback and suggestions for who you'd like to see on a future podcast.