Kate McCullough:

We're here with RevOps review, and we're going to talk usage, pricing, quoting, billing, and just general customer lifecycle. Usage-based pricing is a hot topic right now. Everybody knows that it tends to align business value to the customer, and it's great for an economic pinch in certain regards, but we do see within the industry people struggling to get pricing designed and also operationalized.

 

There's tons of different pricing models, usage overage, credit burndown, pay as you go, and then you can tier them many different ways. So I've brought together two experts on this podcast to talk about it. We have Peter Lukens, who's the General Partner of NJP Ventures, who is formerly VP of Sales Ops and Enablement at Snowflake. And then we have Tina Kung who's CTO of Nue.io and my co-founder. She formally worked at Zuora for many years, Salesforce CPQ, she built the CPQ for the largest CRM in China. She also worked on Oracle CPQ, so she is no stranger to both billing and CPQ.

 

Thank you so much for joining, and let's just jump in. I'm going to start out with Peter. Usage-based pricing has emerged. What do you think is the ultimate goal of it, and how is it working within the economic landscape as we see it now?

 

Peter Lukens:

Right. Well, philosophically, usage-based pricing goes to the principle of how to price a product. It aligns the value that the product provides with the value that the customer gets from the product. So that's the fundamental principle of pricing, and it's why usage-based pricing exists. If you go to the store and you only need to buy one can of soda, you buy one can of soda instead of buying the six-pack, right? Because the one can of soda is what you value at that point. And if it's the six-pack, you buy the six-pack. I think it's really as simple as that. In technology, the big change that enabled usage-based pricing, in my opinion, is the cloud.

 

Kate McCullough:

Yeah. I'm curious, when you looking at it, I'm going to layer onto that question a little bit, how should companies, in your opinion, and this is such a loaded question, so it would be a multi-hour podcast, designing usage in that potential to customer value, what are some considerations you think through, Peter, as you're talking to portfolio companies or potential investments of how they're designing usage into their pricing? Are there any best practices that you can think of or offerings that you tell founders?

 

Peter Lukens:

Great. Well, I mean usage-based pricing in the sense that we use it in tech isn't right for everyone. It's right when you can measure the customer's consumption of the product. If you're selling a server in a box, usage-based pricing is not the right model. Usage-based pricing, that's why I go back to the cloud, the cloud enabled us to consume, compute and storage and networking, the fundamental building blocks of technology in more granular pieces. So therefore, that changed the pricing model. We're then able to pay for what we consume rather than buying a box, some networking equipment, and some storage, which was the way that you consumed in the past. So the past was actually consumption-based pricing, it was just the architecture that existed at the time didn't enable the granularity of consumption that we have today, which the cloud provides.

 

Kate McCullough: 

Yeah. Tina, I'm curious your thoughts on this. What are some of the models you see with usage being enabled or used or different ways it's used?

 

Tina Kung: 

Well, I think in today's economy I see more and more usage-based model. It's really helping a very different go-to market motion. For example, I don't have a very high entry point just to start using the products and getting built for the amount I use. When I really like the products, when I'm ready, I can talk to sales, I can just convert to content base or subscription-based model. So it really helps to attract early adopters. I see that in the cloud infrastructure industry so much. We actually use a lot of pay as you go usage-based model companies. It really helps the products engineering team for either startup or even mid to large enterprise companies to actually start adopting new technologies, new services. So I see that more and more popular as a pricing model.

 

From the company side, especially for the cloud infrastructure utilities, it really helps the companies to pre-allocate resources. For example, we're going to talk about credit burnout model, it really helps companies to not wasting resources on underutilized services or products.

 

Kate McCullough:

I think that what's really interesting is that you have the AWS model or other models that are dominantly usage, but another area that I see amongst our customer base as well closely is that there's hybrid models. Tina, the VP of pricing for DocuSign agrees with you that usage is a great model for that low end motion, and actually my podcast with him articulates how they are leveraging usage in that way. I see it oftentimes companies have a hybrid model of a recurring subscription, one-time fee, and then usage is a component of that, it's not the dominant model, and I think that's increasing in popularity. I'm curious if either of you have thoughts on trends you're seeing in that direction of companies wanting to put usage in the mix but not wanting to risk the entirety of it.

 

Peter Lukens: 

Well, I think that's a good point that Tina started to make, and I'll go back to saying that not every application, even every cloud application should be priced usage based. Take for example an ERP application like Workday. Basically everybody in the company needs to have access to some module of that application, but they're not using it on a daily basis. There are some users who use it much more frequently and are power users of it, the HR department, but a salesperson may check into it when they need to review their benefits or when there's the quarterly review process.

 

So that type of application is not the best fit for usage-based pricing.

On the other hand, you have other software applications like Salesforce that have traditionally been seat-based licenses. And for the core product that may be great, but then there are pieces of Salesforce that could be priced with a consumption model. So I think it really depends on the value, again that you're aligning the product the value's providing with how the customer's using it. So if you're evaluating whether you should or you can deploy usage-based pricing, you have to make sure that the way that your customer consumes your product is consumption-based, not licensed-based. It's better they measure the value in increments, and they'd be willing to pay every time that you provide some value.

 

Kate McCullough:

Yeah. Now, this is kind of slightly off-topic, but it's near and dear to my heart because I've been at many companies, I won't name names, where pricing decisions were like a hot potato. Nobody wanted to own them. The implications were so significant. I'm curious, Peter, if you have recommendations from your Snowflake experience or other companies of who do you think is best suited to make a determination of what is a usage-based pricing model in terms of who it is? Sometimes I see product eng owning this, product marketing owning this, it could be a CRO driven or a CEO-driven approach. Do you have any recommendations for getting to clarity on, A, is usage a model you want, and B, where should it be applied?

 

Peter Lukens:

I like to turn around and say your customer will be telling you if they want usage-based pricing usually. Some areas are obvious. If you're providing cloud infrastructure, that's an obvious candidate for usage-based pricing because it's not something that is always used. You want to only pay for the compute that you're using or the storage that you're using. So some of them are obvious, but then if your customer's asking for it, then your salespeople should be screaming for it, the product team should be figuring out how to implement it, and your finance team should be in there as well. So I think it should be customer driven, and then it's really a multi-discipline endeavor to implement it.

 

Kate McCullough:

I know Tina knows that. We're going to get into that shortly. Tina, I'm curious if you have any thoughts on successful companies where you've seen pricing owned in a particular way that incorporated this like Peter just said. He said customer demanded it, do you have anything of color to add on that?

 

Tina Kung: 

Yeah, I completely agree with that. And also I just want to add that the entire outcomes to deliver more values for customers, and then they actually see values of the products too. While we were starting Nue, we actually did a lot of pricing research. One pricing model which was really amazing to me was Slack. Slack everybody knows is actually a seat license based, but they throw in a usage component which they only bill you on active users.

 

And then of course there's the definition of active users, but that's really attractive I found out because you can bring in contractors, employees, and they can all be in your Slack applications to collaborate, but you are only billed for active usage of that. It's very easy for customers to see the value of such a model. And then also I think that was a really impressive and creative usage model layer onto the regular seat-based, subscription-based model.

 

Kate McCullough:

I think looking at our Slack bill, it basically prorated the seat model against how much of the month they actually used. So it was a hybrid seat usage. It's pretty clever, and I know that that probably took a lot of custom application building to get to because it's not necessarily an out-of-the-box function for a lot of billing providers, but it's super, super unique. Peter, I'm really curious, obviously Snowflake is a great use case of successful usage. Any thoughts to share on ideating and then getting that working to be a success?

 

Peter Lukens: 

Well, again, I mean Snowflake was really created with the idea of taking the enterprise data warehouse to the cloud. Enterprise data warehouse is the market that Snowflake started in. At the time, that was a big company product. You literally bought boxes which were compute and storage wrapped in sheet metal, and you bought it at a certain capacity and you made that investment for the next number of years, the working life of that box. It was a big investment. You couldn't consume enterprise data warehouse software as a startup or in a small increment. It was a big upfront investment.

 

By bringing the enterprise data warehouse to the cloud, we're able to offer that service in much smaller increments and bring it to a much bigger market. Benoit and Thierry founded the company, that was the vision, is was to really democratize the use of data and starting with the enterprise data warehouse market. So that was absolutely fundamental, and the pricing came after. How do we price that? The idea was, hey, this is what we're doing and the value that we're providing to the customer. And then the pricing was an afterthought, but it was really dependent on their original vision for the company.

 

Kate McCullough:

Kind of crazy. I'm really curious what the operational headaches were trying to get this going across teams at Snowflake. If you don't mind sharing.

 

Peter Lukens:

I think no one had really done it. I mean, the cloud providers were using consumption-based pricing, but they were selling raw units of Amazon EC2 instance or storage that was being used. Obviously Snowflake was built on top of that, so it was our cost and the value we were providing is derivative from Amazon's pricing, but there's a value that we're adding on top of that. So we knew the pricing at least had to cover that cost, and then what's the value that you're adding on top of that? And it was really a comparison to what the incumbent legacy architecture pricing is and ultimately what customers are willing to pay for it. But the great thing with most cloud models compared to hardware models is that it's much, much cheaper in that you don't have to make that upfront investment, you don't have to pay for capacity that you're not using, and you can use what you need. So that gives you more flexibility. But yes, it was a triangulation of what historical pricing is, what our cost was, and what a customer was willing to pay.

 

Kate McCullough:

I think you also had the lift of you had to actually build your own billing to operationalize it. I'm just curious, what was the bridge between sales, product engineering, and finance to get that all working properly?

 

Peter Lukens: 

Again, it was a multifunctional effort. I don't want to underemphasize the importance of engineering in building that metering and track into the product. Our model was really the only real model that existed. Outside of the cloud providers was utility pricing, and utilities have been pricing using usage-based pricing since they started. You pay for the electricity or the gas or the water that you use. The only out-of-the-box software on the market at the time was software that was made for utilities, but they're a little bit different than enterprise technology companies, so we had to do a lot of customization on our end to make sure that this type of product could handle the metering data that Snowflake was creating.

 

Kate McCullough:

So you created a new pricing model and then you had to figure out how to build a tool to do it. I'm sure that even though you got it up and running this huge engineering lift, it was still fraught with difficulty. I would be curious if you're willing to share what are some of the pain points that still lingered even after getting it live.

 

Peter Lukens: 

Well, initially relying on the commercial billing software that was available, again made for utilities, is what we did. We did that for a number of years, and it supported the company to a certain level of scale, but it wasn't operationally efficient. So about five years after the product had been released, we made the decision to build our own billing system that could handle the scale and the complexity of the Snowflake product but also the intake of data and the creating of monthly or real-time invoices.

 

So ultimately that was a big effort but one that we had to do and undertook that effort to be ready for IPO so that our data was clean going into an IPO. Because if you don't have all the pieces aligned, the cost piece, the cost of your underlying infrastructure, your own usage, how you're using the underlying infrastructure, what your own cost is, what you're charging your customers, and then what you're billing your customer. I mean, it sounds simple, but there are a lot of moving pieces there. And depending on how many different product offerings you have, it just multiplies complexity, and how many customers you have, it multiplies the complexity. So owning that and making sure that data was totally clean was a goal that we set for ourselves to have done before IPO.

 

Kate McCullough:

I know Tina's smiling because Snowflake was such an inspiration for us to found this company, and it was actually this origin conversation with your CFO, I think it was even after you had custom-built it. And this speaks to how hard usage pricing, consumption, and billing is. Tina, I'm curious if you want to share that story because a lot of what we've done in our tool is actually out of a Snowflake conversation, and you are considered the paragon of doing usage correctly.

 

Tina Kung:

Yeah, Peter, that was so fascinating to hear all these stories again. First time I learned about the credits and then the whole pricing model was when I was at Zuora. We were evaluating Snowflake back then. I was like, "Wow, this is such a unique and also smart pricing model." And then I think that was four years ago when we were doing a lot of market research.

 

Kate and I went to visit Snowflake office. That was before the Snowflake IPO, and then we talked to the CFO and finance teams. And then we were chatting about the pricing, the billing, the sales, upsell, cross sell side, and then I really learned that at that time Snowflake was already using the product-led motion just to use PLG self-service to attract early adopters. But then for the contract-based customers, you're using the credit burndown model. So basically you purchase credits and then over time based on the computing minutes, the storage usage, the number of [inaudible 00:22:42] queries and all those factors, the credits will be drawn down from the credit pool.

 

I think that was really amazing to start with because from your side of the story, it's really hard to create that, to implement that billing system but from the customer's perspective it's so easy to understand. So I don't have to worry about how do I measure the usage of the products and so on. What's really impressive was that there's this challenge to turn the PLG customers, like the early adopters, into the contract-based customers over time. And then what's the tipping point of that conversion? Basically what's the threshold? We need to be able to identify the threshold and then automatically create an upsell opportunities in Salesforce and then assign to direct sales reps.

 

I heard a story from the finance team how hard and time-consuming it was for engineering team to build that model so that will be able to identify all the potential conversion from PLG to contract-based, long-term customers. So I think I found that really fascinating. So after that I was like, "This is so interesting. And apparently because Snowflake did pretty much everything in-house, it sounds like there's a big gap here, then there will be a lot of opportunity for the market to have a tool that can manage these kind of usage models."

 

Peter Lukens: 

I'm glad you brought that up, Tina, because when I answered the previous question, I left out the biggest part of the answer, which was the concept of the credit. I talked about all the complexity or all the considerations that you had to take into account to price the Snowflake product, but if we had just taken that and put that in front of the customer or said, "Okay, it's based on our costs plus..." it would cause brain damage for the customer. Bob Muglia invented the concept of the credit, which was, okay, this abstracted unit is a representation of value of consuming Snowflake. In a data warehouse or in a database where you're running queries, it's not like you can price by a query because queries have different characteristics and one can use much more compute, be much more expensive than another one.

 

So the real genius of Snowflake pricing was the innovation in creating the credit. The customer buys the credit, they can use the product any way they want to, and that uses credits. So the metering actually occurs against the credit, which is different from the utility model where if you use so much electricity at a certain time you pay a certain rate. We needed to create that type of simplicity for the Snowflake customer. So like you said, that was really important. The problem with billing software that were available at the time is that it didn't allow for that credit model. It was more along the lines of, okay, you use this much electricity, the price at that time was $6 for this many watts, and therefore your bill is this. That was fundamentally different from the credit model.

 

Tina Kung: 

Yep, that's right. That's why when we started working on usage, one of the most important usage model implemented this credit burndown, and that is really the inspiration from Snowflake. I think that was really inspirational.

 

Kate McCullough:

To add on here, I think the other thing that is a little bit of a misnomer in the industry is that usage is exclusively a billing problem. I think that that was the little glimmer of light that Tina saw in this conversation of like, "Wait, what is my revenue against my product-led growth motion versus my direct sales motion?" And so you guys were pioneering this credit, and that credit is so nicely extensible to a product-led growth website motion, no sales person, and then also extensible for purchasing more in app.

 

But it's just really, really interesting that a lot of companies right now exclude the front office from this product eng and back office thing. And so what we see is product and engineering frequently going and building usage billing as a custom thing, but it's disconnected from the sales motion. And then you end up having people in between each of these departments trying to gluing it together. Credits are great because you can actually quote a credit, you can put in sold 500 credits, and then you fulfill it. If it's a usage overage model for instance, it's a $0 basis, it's based on usage. So you actually quote zero and you have to have a quoting tool that connects to billing and your ERP. It's a whole continuum where your sales team, your product and your finance team and customer success or whatever your account manager process is, has to be connected to this thing.

That was the thing where we looked at it and said, "Hey, can we create a connection between that self-service motion and your direct sales motion for that upsell tick into an enterprise-grade account?" And so I think that it's been fun because we took so much of Snowflake's innovation and we're trying to build on it now. The industry is still stuck with the idea that usage is a billing problem. I would say, and this is my provocative take, Peter, you can tell me if I'm wrong, I think usage pricing is an entire customer lifecycle problem... not problem, opportunity, and you've got to think about who touches every single point of it. So I'm curious if you have any thoughts to layer onto that.

 

Peter Lukens: 

Definitely. Well, let me go back to the Snowflake analogy. One thing that we got really good at it, the engineers were able to connect metering to drawing down a credit. So the way you use the product and the relationship between the product usage and drawing down a credit is a formula. It's complex, but the engineering team got really good at that. But then like you said, on the front end, it doesn't end there, there's more complexity. Even though you have a standard price list, customers may have different pricing. They may have bought a lot of credits at once, so they have a discount and they're priced differently. Like you said, they may go over what their initial purchase of credits were and those overage credits have a different price.

 

There may be something happened in the product and you may have to refund credits or you may have to add credits. So there's a whole bunch of complexity added after the metering algorithm determines how many credits are used that you have to deal with before you can create a bill for the customer.

 

That's really what you guys are solving right now or allowing customers to solve that problem easily and taking that off their hands. You say, "Okay, you have a credit or you have maybe straight usage, but on the business side, once you get ready to build a customer, there's this whole other level of complexity." That's really what Nue does, the fundamental innovation. Otherwise, you'd have to go out and build that yourself and build that into your product or build the extension between whatever billing system that's not new you're connecting back to your product.

 

Kate McCullough:

Another problem we see is that a lot of people don't have a straight credit burndown model, they have a recurring subscription, they have other stuff, and that's and quoted in very specific custom ways. And then there's this little island called usage where engineering and product just grabbed a billing provider for that and then you have to somehow reconcile it back into the original order form that included other things, let alone that custom pricing on top of the usage. So I think there's this really big misnomer in the industry. I think a bunch of VCs went out there and invested in usage-based billing providers without thinking through that the pricing happens in sales. And so, Tina, I'm really curious, what are the deficits you see in the current set of vendors, especially on the billing side, in regards to that beyond the disconnection from the sales process?

 

Tina Kung: 

I just want to add on, I saw so many times where quoting essentially because there's no usage, so basically it's a $0 quote, however, there's a giant pricing sheet as attachment of the quote. On the usage billing side, whoever is doing that, finance team, engineering team actually has to dig out that large spreadsheet just to understand, hey, what was really the tier pricing negotiated for this very customer because every customer could be very different? We really need to bridge what's quoted for a customer all the way to what's consumed, what's rated on the usage side, and then what's built. And even more, when you go downstream, how is the usage getting recognized?

 

Revenue recognition for usage, we probably don't have time to talk about that, that's another big challenge for a lot of companies because they may not realize that when they just started with the customer, but it could be a big thing for the finance team. So that's why with usage, it's a very powerful model, however it does require the collaboration across all these functional teams.

 

Another thing to add on is the whole usage metrics is extremely useful. You see the consumption, you see the pattern. That's a time series data. You can leverage the time series data for many things. You can identify upsell or a downsell if you don't want to. For certain reasons, for example, a customer is not really using the product as expected, so what do I do? And to anything that prevent churn. So all these metrics really valuable for customers. So it's really a team sport to operationalize the usage-based pricing model.

 

Kate McCullough:

I was actually talking to someone yesterday who was an RVP of a region and he's like, "I can't forecast an expansion of seeds on renewal because it's self-service adding seeds because I can't see the data." So he has a huge account management team that's working on this, but he doesn't know where his year is going to end. And this is a very consistent problem that usage is a black box with product and engineering and kind of tied into billing, and then CS and sales are running blind as to the current status of the customer. Maybe Snowflake solved for having more visibility there, I'm sure they did, but it is a chronic problem I see. Even big later stage startups have not solved for this.

 

Tina, what are some of the technical attributes? We do real-time rating, which I know is pretty rare in the industry. How does that factor into this in terms of that visibility and the importance of real-time rating?

 

Tina Kung: 

Yeah, that's a very interesting topic because we can get really nerdy in this. But in general, one of the most important success factors in usage-based pricing model is transparency. For example, in the Snowflake example, I am consuming credits, but what actually contributes to each credit? That comes down to all of these raw usage data actually ingested into the rating system and being rated in real time into credits. So all of these data can be visible because Snowflake customers, we can actually view the usage data on a hourly and daily basis. So that give me a lot of clarity and transparency of how I use the system.

 

That's from the business perspective. From the technical perspective, all of this raw usage data, whether that's computing minutes, storage, or even how many envelopes you are actually using in DocuSign, so all of this usage data, once it's rated in real time, we actually spread the computation workloads across timeline. So essentially at the end of the billing period we can just grab all these pre-graded usage records and then do simple math, simple calculations to generate a invoice. So that makes billing really easy, fast, and scalable. So that's from the technical perspective. So real-time grading, it's not just really great for the customers to create transparency and clarity of the usage, but also from the billing perspective, the billing becomes much faster and also much scalable as well.

 

Peter Lukens: 

I just want to emphasize everything that Tina just said and then also add that usage allows you to predict the future more accurately. So if you know that you've used this much of the product at this time of year for this particular project, you can use that to model what you're going to need in the future. It's great for everybody. It allows the customer's finance team to better budget going forward, and it allows the vendor to predict their sales going forward. So it enables much more stability and predictability for both the customer and the vendor.

 

Tina Kung: 

100%.

 

Kate McCullough:

Curious, we're closing on time, what is a hot take or point of view you want to leave listeners with? And I'm giving you exactly 10 seconds to think about it. But what's something or advice to people thinking about usage-based pricing for their business, whether they're big or small, what would you tell them? I'm not going to pick on anybody. You can choose if you want to raise your hand to go first.

 

Peter Lukens: 

I'll keep it simple. Not every product is right for usage-based price. If you do have a product that is used in a way that is applicable for usage-based pricing, make sure that you align your pricing with the value that your customer gets. One more thing, and maybe this is a pitfall, if you have a bad product, it's not going to be used and your revenue's going to decrease when you switch to usage-based pricing. It keeps you accountable. You get a bad product that your customers don't use, usage-based pricing is going to reveal that.

 

Kate McCullough:

Wow. Good word. Tina, what about you?

 

Tina Kung: 

Yeah, I think one thing on top of my mind is that if you consider laying on the usage-based pricing into your existing pricing model, which could be subscriptions, bundles, or one-time professional services or physical goods, you probably already have them, right? When you design usage-based pricing, don't overcomplicate, start from simple, start from, for example, simple volume-based or tier-based pricing on one of the components. Layer it in, and then just do trial and error and monitor the effectiveness of that usage pricing. From the real time usage data collected by the system, you'll be able to identify pattern, identify the effectiveness, and then you can do fine-tuning or switch to a different usage-based pricing model like pay as you go, overage usage, credit burndown. It could be like they can have very different effectiveness, but start small and then keep accelerating, and then I think just gets to the business goal.

 

Kate McCullough:

I think those two perspectives combine well. It's like you will know if you have a good product, so you might as well start with a small feature to monetize first for less risk. So good words from both of you. Thank you so much for participating. It was super fun to do this with Tina for the first time, and thank you for joining us, Peter.