Usage-based? Hybrid? Tiered? Which pricing model is right for you? — Stripe’s Jeanne DeWitt Grosser

 So I thought we could start the conversation at a high level talking about, um, some of the benefits and or trade-offs of usage based pricing. And what's really interesting is across your career, you've both dealt with more traditional SAS, uh, business models and pricing, and then obviously have had this incredible set of experiences at Stripe, um, building much more of a usage based pricing business.

And so I'm curious when you zoom all the way out, um, how do you think about the positives and negatives of usage based.

 on the positives. It drives strong alignment between a customer getting value and your company getting paid. So it's very purist in that way. Um, but what that means, right, is like you actually really have to have your customer be successful if you're going to continue to drive usage. Um, so some of the things that have been really different as we've, you know, Stripe has very much ad valorem or, or usage based pricing, um, is in particular thinking about your plan for implementation and customer success.

So, you know, in, in stripes case in particular, which is probably an extreme example, we truly don't make money and tell the customer is making money on Stripe because we're taking a percentage of the revenue that, that runs across. Our rails. Uh, and so for us as an example, right, again, extreme example, when you sign a contract, we call that moment in Salesforce deal signed, which is different than any other company on the planet.

It's not closed one it's deal signed. Cause that's all, it is a piece of paper. It's not even really a booking event. Um, and so time to value is key. How quickly can you deploy? How quickly can you get from live usage to fully ramped? And so I think folks can underestimate that sort of implementation and success piece on, in a usage base model.

The other thing that I think sometimes happens is that. You frequently don't have commitments at the outset. So I think with tech companies, right there tends to be this sort of purist approach to pricing. Often. I remember when I was at Google, um, Dave Gerard, uh, who's now the founder of upstart had this whole pricing thing.

It was called the Dakota ring, right? Where you, you really didn't want to have opaque pricing. We wanted to have clear, transparent pricing, and we wanted to earn people's business every day. And that's really frequently true. And usage based models is, is basically people will just let you sign up and let you kind of pay as you go consume.

Um, but what that means is you in the long run, don't get predictability. Um, and then you do also open yourself up for churn. If you think that you're, you know, earning somebody's business every day, but maybe because you're scaling really quickly, you aren't necessarily talking to everybody all the time. 

 if you were to talk to a founder and you were studying their business and you were trying to advise them, let's say they're more of a traditional SAS based business today.

 How should they think about if they might be a great candidate to try to pivot their business from SAS to usage?

 Yeah. It's a good question. I mean, basically it's sort of like, where does the customer. Get value. And How does that value scale? So, you know, I think a lot of SAS models are licensed space because the value is derived at, you know, a per seat or a per human level and scales with the number of humans using the product.

So then the question becomes as add, as you're adding functionality to that, maybe SAS based license is all of that functionality still, you know, tied to the human, using it, or is some of the functionality actually scaling with the outcome you might be driving. Um, so you'd have examples of this. And in a lot of products, like maybe certain marketing products, right.

Where there's a, a seat based fee in general, but then there might be a usage or a consumption-based fee with the number of emails you're sending or SMS you're sending. Um, and so it's both kind of about the operator as well as the end delivery. So that's probably what I would focus on is who's getting value.

 How do you think about the opportunity for that hybrid business model that you're talking about? And do you think ultimately that sort of a bit, you know, have your cake and eat it too, and more and more of the ecosystem is going to move to sort of SAS plus usage. Um, or do you think there's just going to be splintering and companies are going to be doing all sorts of different things over the next few years?

 Yeah, I think my assumption would be, it'll be all sorts of things. Um, but that doesn't make it easy. So let me give you a good example of this one. So Stripe payments, right? Like I said, it's your, your sort of, one of your more pure usage based, um, Uh, pricing models, we launched Stripe billing. So it's a subscription engine.

Uh, so again, sort of the value you're delivering broadly scales with the transactions running across the engine. So we priced that way. Um, so like basis points on, on transaction volume. Um, and it's actually not how the bulk of the market prices. They, um, tend to price it more in an annual subscription where you might, uh, sort of have that full, like basic and run a certain amount of volume through the engine.

Um, and then you've got some overages. And so that's been really challenging for us because you've got sort of one core model that you're really used to. And so it's easy for you to conceptually layer other things on, in that, in our case usage based capacity. And it's been hard for us to then think about actually, how do you move this product potentially to more.

A licensed based model or more of a core subscription. Um, and then talk about the two things at the same time. So if you're trying to sell two products simultaneously that have fundamentally different commercial models, it can also be an awkward conversation from a sale perspective. Um, so I would say, you know, for us and getting that right, I think we'd ha we, we could certainly benefit from putting, you know, more enablement behind that thinking a lot more about how you present the different pricing models.

Um, but it's not, it's not supernatural. I would say 

 And so in that case, the biggest challenge was that the customer was trained to be buying something that was non usage. And, and in your case, you were trying to bring something that was used its price out of the gate, or was it sort of this hybrid model of where you're trying to do both at the same time?

 Yeah, it was more of the latter. And so what would end up having it happening is, you know, we weren't necessarily the market maker at that point. So I think that's the other thing that startups have to think through is like, if you're going to do something differently, either your product has to be, you know, 10 X better so that no one's really debating whether or not there's a relative comparison.

Or you've got to know that if your product has a comp in the market and the market broadly prices fundamentally differently, you're probably going to wind up having to reverse engineer your pricing model into the existing construct. Um, and this, I, you know, it was mostly when you're starting to get into like, uh, you know, mid market enterprise type deal, where you've got finance organizations, procurement departments, and they've got to do a side-by-side financial comparison.

So I think that's like the other thing to consider is if you're going to be really different, uh, you know, are you basically going to wind up having to just re-explain yourself in somebody else's terms. 

 And so you talked a little bit about this, but how did you solve that problem or are attempting to solve that problem? In the case of Stripe billing?

 Yeah, so we're attempting to solve it now. And basically I think what we figured out is the usage based model. And this is actually often true. I would say of usage based models in general scales. Well, for companies that are smaller and growing, and then it reaches a point at which companies really want predictability.

And then we are actively changing our model there to be more of a SAS. Um, so if I'm selling into a high-growth series B company, I'll probably price, payments and billing the same way, and that just sort of scales. Um, but if I'm going to go sell into a public software company, they really want cost predictability.

And so payments, we still are sort of figuring out how you get that on a, you know, a committed contract. But, um, for billing?

we've increasingly been able to see actually folks want to do a five-year committed revenue, no, their annual spend for half a decade going into the future. Um, which isn't necessarily a bad thing for Stripe either.

So we're just working through the mechanics on how do you bill for that? Uh, you know, how do you present that side-by-side with payments, which is priced differently, um, And have it all land and come together.

 And when, when you talk about sort of what is the customer want? You sort of mentioned, obviously the, the benefit of usage based is that you better align, uh, the value you're creating with the value you're capturing is the number one reason that customers don't like it or have an issue with it is the, the predictability issue.

 I think that's one of them. The other big one is, uh, obviously if you scale a lot, you pay a lot more money. And so then you have to get into smart volume-based discounts, basically. So companies are happy to play, pay you more over time because you're adding more value, but they tend to want the per unit cost to go down because they also have their own unit economics to think about and, and present.

Um, so then you need to get really smart about your discount curves and things like, you know, do you do progressive pricing where it like, sort of like the tax like taxes, um, but you know, so you don't have big drop-offs as somebody goes from a million transactions to 1,000,001 transactions and maybe kicks into the next bucket in a volume-based discounts.

on that point, where do you advise companies? Sales teams, product leaders sort of start as they're kind of building their first usage base. Pricing plan because you just sort of hinted at one of the dozens of things that you have to consider. And it seems like things can get mind bendingly complicated, um, and things can get, I think, quite custom and bespoke, which is kind of one of the, one of the inverse sort of pieces of what's nice about usage based pricing, because ideally it should be simple and elegant, but it sounds like it can get exceptionally complicated exceptionally quickly.

 And so do you have sort of a starting point or, or sort of way that you would kind of frame or educate a founder on how to get going on thinking about the early days of their usage based pricing model?

 Yeah. I mean, I think as far as where you get started, um, to me, the things I would want to do is, is outline what are the different things in your product that are the value levers. So let me give another example here. Um, stripes connect product. Um, so a lot of marketplaces or software platforms use this to do complex money movement, and it has value in a number of places.

It has value in your ability to onboard a Lyft driver as an example, and make sure they're, you know, they're. Uh, sound as far as being part of the financial network, it has value in letting you move money around. It has value and let you letting you pay out that, uh, Lyft driver. so we actually wound up pricing it on those three different things.

Um, so that it's sort of more straightforward with, with how you would explain, you know, why you're pricing something to, to a, um, a customer. So I think, I think that's one is sort of like understanding. What are the drivers of value for your customer? And then how do those, um, those drivers scale over time, right?

Are they linear, uh, with, with the product, um, or, or we're not? Um, and then I think, you know, like all founders, you got to kind of put something out there, that's your best educated guess, but then I think people increasingly need to be treating pricing like a product and have a built in plan for how are you going to get feedback on your pricing construct, just like you did on your core product and how are you going to iterate on that rapidly?

Um, we've had all sorts of examples where we've launched a product at Stripe and figured out that, um, you know, we got either the core pricing construct wrong or similar to where you launch a product and all of a sudden you figure out there's an entire segment of the market that you didn't realize was interesting and is loving your product.

We've seen that too, where sort of the pricing works for. You know, 80% of the market, but there's this other area we didn't contemplate and actually it needs a different approach. Um, and so I think, you know, there are a bunch of ways in which we've been slow to iterate in places that would have been better for our customers.

And also I think, driven more revenue for Stripe. If we'd had sort of that dedicated team earlier on and figuring out how do you adjust your pricing based on all the reactions you're getting in the market.

 so on that point of treating pricing, like a product, can you, can you sort of explain that a little bit more detail, or if you are treating pricing, like a product, what, what are you doing or what does that look like?

 yeah. So we now have a cross-functional team focused on pricing for quite a few of our products. So it's got, you know, a person we ultimately wound up with a pricing team. Um, but early on it was just a member of the finance organization. Um, you got, uh, folks from product marketing folks from product and folks from sales.

And so sales often will get a ton of feedback when you're trying to go and win these first deals or you, you know, it works for the first deals and then the next 100, all of a sudden you get other gotchas out there. So we'll bring those back. Um, as far as like, you know, you get in competitive situations and the competitor is offering this sort of package or discount or whatever, and we'll, we'll bring those together.

And then, um, increasingly have set up our internal billing platform to be extensible to other product organizations so that they can. Play with it as if it, you know, frankly we're a product and be able to do more pricing experiments. Uh, similarly we do a fair amount, um, in thinking through the way that you bundle or test different strategies like freemium.

Uh, and so, you know, have a team that will put those proposals together. We often test them actually with the sales organization. Um, so we'll package them up as if they were, uh, the way the product was priced and, you know, make it work on the backend. And if it's really resonating, then we sort of productize that pricing construct.

Um, so, you know, try to do a bunch of things that let you iterate more.

 So on that point, when you're testing, let's say a new model or a tweak to how you're doing pricing today, how do you bring that to potential customers, I guess is sort of one question on the other would be like, how, how do you know if your pricing is working or as effective or could be improved?

 Yeah, I think, um, so we at, at Stripe actually, so it's relevant for early startup founders. Uh, in, in my sales organization, I have an incubation team because Stripe, you know, we've got a payments product and that's, you know, very large product that hundreds of people sell, but we're bringing new products to market frequently.

And so we have an incubation team. That's not that different from. An early startup sales team, there are three people on it. Um, and so honestly, like you get pretty quick pattern recognition as you go out and pitch these, uh, as far as the questions that get asked where you get objections. Um, so, uh, I think we're just, it's not really different from any other startup out there.

There's just the fact that you are very thoughtful around realizing that pricing is really a part of the product. And so we review it with the same level of attention that we do. Hey, you know, we need this feature over here. This button should be blue, not red, uh, you know, those, those parts of it. I guess on that point, how do you balance kind of what you hear from customers? Like, well, I'd like more predictability or I don't like this relative to sort of what you're trying to do as an institution, which to a certain extent ismaximizing the amount of value you can capture or sort of having it, you know, in balancing it in some way.

Yeah. So we learned a lot on this one as well, I would say. And there's a certain point. At which the market actually has, I think a relatively strong ability to kind of dictate where you land on this front, unless you are truly doing something that is, there's no comp for it and or you are 10 X better. So we, as an example, Stripe on payments, um, has historically, you know, priced at a relative premium.

And, um, the thinking there was we're this tech forward API, you know, you can build things much more quickly. Our time to value is fundamentally different than other solutions in the market. And therefore you should pay something for that. Um, and you know, when we first got into enterprise sales back in 20 17, 20 18, we got feedback again and again and again, that the pricing you're coming in is like, quote, unquote shock and awe tactics.

Um, and we tried it, you know, again and again and again, because we, you know, felt, Hey, you know, there's a real value we're providing here from, from a technology perspective. And you know, when you have eight of those deals where you've truly gotten a technical win, you've been told, assuming we can come to an agreement on price, you are the product I want to move forward with.

And then you don't get eight of those deals across the line. Uh, then, you know, you have a pricing problem. So I think maybe to your, to your question, Brett, the thing from a sales process that folks can do well is get to that statement where the customer has said to you, assuming we can come to agreeable commercial terms, you are the product of choice or the solution of choice.

Then if you don't end up closing the bulk of those, that wound up with that statement, you probably have a pricing problem. 

 so kind of building on this point of the intersection of, of usage based pricing and, and sales and, or kind of the different pieces of go to market. I was hoping we could spend some time talking about maybe in what ways the go to market function looks similar to kind of selling more traditional. And maybe in what ways is it different or, or what do you have to do to set up a go to market function to be successful?

Um, when you're building a usage based pricing, uh, business model,

 I think that broadly you wind up with the same functions is, is sort of in my experience, it's just sort of like the relative emphasis on of them. Um, So a good example would go back to kind of earlier in the conversation, um, implementation and customer service. It's not that SAS companies are licensed based companies don't have those functions.

They, they certainly do, um, for usage based ones. I just think they're that much more important. And earlier in the cycle, I've had a lot of conversations actually with, with other founders around this, um, where the, sort of the intersection of sales and customer success, they just won't wind up being that much closer.

And you've got to figure out where one stops and the other ends, right? So like a traditional, uh, SAS model is typically the sales person is responsible for, uh, getting the contract signed, started getting to that closed one state and having the booking event and usage based models. There may not really be a booking.

And so then the question becomes is the sales rep responsible past that? Um, so it Stripe as an example, We came up with this concept, we call it first year sold, which is basically the revenue a customer brings in the first 365 days after they have activated. And we have a definition of active, um, and we disproportionately, um, target and pay the salespeople on that rather than on getting that contract signed, because we believe that aligns the customer's success with rep incentives and ensures that, you know, you've done a really robust sales process.

And so when you sign something, the customer is in fact, ready to deploy, likely to deploy, you know, we'll ramp and be successful. Um, so I think, I think that's a big one is sort of like just how important, um, the implementation piece is because you, you often don't pay at all until you actually are. Um, and then I do think like, you know, sales targets, compensation, et cetera.

 So on, on sort of this implementation and cost the emphasis on implementation and customer success. Could you maybe talk in a little bit more detail, um, how you've set up Stripe given sort of how important, um, implementation and customer successes and maybe some of the tricky things that you've had to figure out as, as you just mentioned, the balance between customer success or sales or who owns what, at what point in time

 yeah. A great, great question. So how are, um, how our org is set up is, uh, basically we have, you've got your account executive in the U S actually we also bifurcate our account executives into Greenfield account executives. So folks who are pursuing net new customers who don't work. And install base account executives who are managing that now growing customer.

And then, um, you know, expanding as, as they move into different markets or have something else that they might buy from Stripe. So that sort of thing, one, the AAE pairs closely with a solution architect, we sell a pretty complicated, uh, API. Uh, so, you know, we have deeply technical essays. Most of them, all of them, I think have CS degrees.

And, um, depending on the segment you're in, you'll have a different type of ratio. If you're in the startup segment, you tend to have the decision maker might also be the one writing the code. So it sort of less need to have an essay, but in the enterprise space, you might have a one-to-one of an eight and. Um, so their job, their primary job is to get the customer to pick Stripe and to get the contract executed. But they, like I mentioned, they don't get to roll off after that happens. They actually own the customer for the next 365 days. We're actually arguably more than that because it's during the implementation.

And then for the next 365 days, um, then you've got, uh, we've got two, two roles and integration engineer and an integration implementation consultant and integration engineer. Similarly, a very technical resource that helps with scoping. Um, the, the integration works very closely with the engineers at a customer implementation consultant will do some overall project management as well as a lot of change management for various functional teams.

So their core job is to go from signed deals. Um, to live and ramping. And then once you exit that 365, uh, you flip over into an install base, IE and, and customer success. Um, so a big debate that, that we've had, and actually that we're in the process of changing, um, is the handoff between the essay and the E or the implementation teams.

So, uh, you know, you don't no one's ever swimming in resources. So an example is you ideally want the IAE and the implementation team to come in as early as humanly possible. Because as soon as the, um, you know, deal is scoped and the customer's writing code, you're shrinking the amount of time to go at going live.

But if you bring them into early, it's possible, we may ultimately lose the deal. And now you've used their time and effectively that could have been on another account. So we used to have the solution architects, um, you know, take things all the way up through a signed deal and not bring in our IES and ICS until afterwards. And now actually we've pulled that forward where we have a well-defined technical win. And when the technical win has been achieved, we'll start to pull in implementation while we're still, um, while that the, uh, the account executive is doing the commercial agreement. Um, so that's been one of the things we like debated over the years and I've changed as we've matured.

Um, you know, there's been others on, on CSM as well. Um, you know, when do you bring them in? Sometimes we actually bring them in right after you sign, if it's like a massive, massive, you know, sort of $10 million plus deal. Um, but those are sort of all the life cycle debates we have.

suit to kind of loop back to it, one of the ideas that you shared the idea of a green field account exec and an install base account exec, um, are the skill set of those people, uh, similar or different from each other.

 They're actually quite similar. It's more just like, uh, maybe the way to describe this would be like, they're both really good athletes. One's just great at playing baseball and the other is great at playing basketball. Um, so. They, you tend to sell slightly different things. Um, it's, it's a Venn diagram, but like a Greenfield rep, um, is, you know, always going to be a competitive sale.

We operate in a really competitive market. Um, and it will always be at least a payment sale ideally, or selling other things that Stripe has, but you will always have to sell payments. Install-base you've sold payments. Um, and so you're disproportionately selling, uh, straight billing or radar, you know, a different product of ours.

So you sort of major and minor on different product lines. Uh, you know, you do have, you do own a renewal motion, uh, which can also be very competitive, but the content and positioning of it tends to be a little bit different. Um, so we have people move from one team to the other.

Um, I basically said like, I don't have hunters and farmers.

They're all hunters. They're just, you know, hunting in a different place in the life. 

 So, at what point does an account get handed over from a Greenfield account, exact to an install base account exec.

 Yeah. So this is another one that, um, we, I think we'll continue to iterate on. So today it gets handed over more or less, you sort of try to line things up with different quarter annual marks, but more or less after 365 days, uh, there are some exceptions to that. So in accounts, like very large ones where you, um, are unlikely to have gotten a very large portion of that company's total share of wallet and the original Greenfield sale they'll stay with the Greenfield AA because the value of that relationship is, is high.

And when you're in sort of like lower tiers, slightly smaller customers, often not initial sale, you got the bulk of what you were going for. Um, and so we'll, we'll do that transition. Um, but we've debated, do you pull the install-based person forward, um, you know, or do, do more of the life cycle model? Um, so like we're experimenting more with the life cycle model in Europe and APAC where the teams don't have the same amount of scale to have these, you know, clearly segmented teams and ultimately we'll see which ones produce the most productive account executives and happy. 

 On the, on one of the years, I was interested in what, what is the role of the CSM versus the installed base accounting? 

Um, so we only have CSMs in large accounts. Um, so think ones that are maybe spending on the order of a million dollars or more. Um, And so in those cases, there's a lot of work to be done, to really optimize the account, to ensure that they're, uh, getting as much value as they could out of Stripe. So, uh, payments strikes very interesting, right?

In that we're an API, you've got a tech company, but you also set in this legacy financial, um, industry. And so the intersection of those two things is, uh, is somewhat unique. So. CSMs has, as an example, might help you with payments optimization, which is basically figuring out are you doing everything possible so that when you use our API to submit a transaction to Stripe, you're getting the lowest possible underlying, uh, price, which isn't actually from Stripe it's from the card networks.

Like. So there's a lot of optimization work to be done around that. Um, you know, a lot of the companies Stripe is working with either their high growth companies. So they're launching new business lines or they're moving to international markets, uh, or in the enterprise space, maybe one with an initial line of business you're going into others.

And so there's a fair amount of, you know, ongoing change management work to do as, as new products or new people come on board. But they're, they're basically really about helping the customer realize as much value as possible from what they've bought. Whereas the AEE is, um, you know, more commercially oriented.

So find the next thing you should buy and then make sure we retain you on the things you have.

 And are those two roles working in concert in one in, in some way, or how do you create alignment? So you, you have a great experience on the, on the end of the customer. 

there, they work as an account team. So basically for the accounts that have a CSM it's, it's a three person pod of an AAE, an essay, and a CSM. And they work together as, as a, as a unit. So they'll do account planning together, all the QPRs internal and external happened together. Uh, they often have their own customer base slack channel.

Um, so, and you know, they, they have ways in which there's certain roles within an account. One might own more so than another. So it's not like they take every single customer facing meeting together. Um, but they're all going to be talking to each other every single day about the. 

 and you mentioned this a minute ago, but in what ways does the go-to-market. Uh, function in both pre-sale and post-sale change as you move up into the enterprise and, and sort of out of the mid market or sort of the startup, uh, segment

 Yeah. I often just the addition of more roles and then the deeper specialization of those. So to give you a sense, uh, for this, when I joined Stripe six years ago, we only had account executives. That was the only role that we have. And I, at first I was just blown away. I was like, we sell an API. Was it possible that we don't have any technical sales resources?

And the reality was at that particular moment, we didn't need them because we were typically selling to a series a or series B company. And we had some of the best documentation on the planet. And so basically the customer was their own essay and like, we could have hired out an essay team. I'm sure it would have added value, but like you actually didn't need to.

In this episode with Jeanne DeWitt Grosser, Head of Americas Revenue and Growth at Stripe, we dive super deep into all things pricing —  including the pros and cons of usage-based pricing, exploring hybrid pricing models, and treating pricing like a product. 

Usage-based? Hybrid? Tiered? Which pricing model is right for you?

Stripe's Head of Americas Revenue and Growth Jeanne DeWitt Grosser dives super deep into all things pricing. 