[00:00:00] PREVIEW CLIP

[00:00:26] 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:50] Scott: Welcome Justin. Thank you for joining us on the podcast. I'm very excited to talk to you because I think it's rare that we talk to someone who owns pricing, product and [00:01:00] growth. And you know, as a former growth person, growth in particular is very near and dear to my heart, and especially the intersection between pricing and monetization and growth.

Like, I feel very kindred spirit there. So, maybe what you could do is just tell us a little bit about you, and then also about the company you work for. 

[00:01:17] Justin: Yeah, sure. And thanks for having me, Scott. So about me a little bit. I live in Seattle and I've worked at a very famous real estate oriented website, Zillow, and had a growth role there and dabbled a little bit in pricing when I was there.

And then about five years ago, I joined GitLab. If you're curious how I went from a consumer marketplace business to a B2B-SaaS-devtools company, I had a big deep technical interest in helping developer ship code faster. As a growth leader, a core tenet of growth is how quickly you can run experiments.

And we had an era at Zillow where we were really bad at that. It was way too slow. And so I took on an effort to fix it and actually discovered GitLab in doing so, and then loved it so much that when an opportunity came around, I joined the company. During my time at GitLab, I was having lots of conversations, you know, being responsible for growth and working collaboratively with pricing and with, you know, monetization in general, our fulfillment systems, and realizing there's so much coordination that needs to happen. It kind of makes sense to have a single leader over this whole area. I was sort of pitching, getting a new boss. And then one thing led to another and I ended up earning that role and sort of taking over the whole team. 

And so for the past few years, we've centralized our growth function, product-led growth motion, our pricing function, so driving pricing strategy and sort of building new products and pricing plans and things like that. And then our core systems, homegrown stuff and, and sort of tools we integrate with to actually deliver that to customers. So, you know, web store, checkout, billing, monetization systems, licensing, provisioning and so on. And that all reports to the Chief Product Officer. So all of that reports into product.

It's a role that like I've stumbled into over my career. But I think maybe similar when you say kindred spirits, it's like everything I found interested and everything that I found had the most leverage to have a big impact, especially growth-oriented stuff, all kind of centralizes on these three things. And it was really important to me that they were all kind of in one place and it's been a great experience building that out and it enables me to work really efficiently and collaboratively with folks across the business. 

[00:03:28] Scott: That's awesome. I think at Dropbox we kind of stumbled into a similar model. I mean, there are some amount of directed evolution toward it, but the kind of deep realization that especially for these PLG-led motions that kind of... distinction between your product and your pricing and packaging is kind of there isn't one. Like they're just like two sides of the same coin, and so centralizing those things together makes a lot of sense. 

Maybe talk a little bit just at a high level about the current kind of ways that GitLab monetizes in particular, I think it's very famous for a PLG motion. Do you have, or is there like a enterprise sales component, too? And then I would love to kind of explore the bounds or the interactions between those two parts of the business. 

[00:04:12] Justin: Yeah, good question. So, like many companies, we started very heavy PLG. You know, maybe even exclusively, I wasn't here so I can't actually tell you. But, that was the way I bought GitLab. 

So when I was a customer back at Zillow you know, we identified this need. I was a director level person there and I, you know, I don't know if I had a P card or whatever, but I made the purchase myself and we started using the product for free and then eventually converted.

As GitLab has grown, you know, we went public in 2021. We obviously built out a massive enterprise-led sales motion. And so a lot of our, you know, revenue is attributed to that, and more and more large customers, you know, choose GitLab, but we maintain both. So we actually have both, we've maintained a PLG motion.

And one of the things I'm a firm, a big believer in this strong opinion, you know, PLG is not just for small customers. PLG is for small lands, but you can be a big account. Zillow is a very large company and land very small and land through a product-led growth motion. 

A lot of times what I see companies do that I advise and I talk to is they sort of bifurcate them and they think that oh, SMB will only ever land through a self-service PLG motion and enterprise will only ever land through a sales-led motion. I don't believe that's true. Obviously, lots gravitate towards those polls. But you know, we prioritize both. And so that means we have a growth team that does traditional growth things, figuring out activation loops, figuring out conversion loops, optimizing those things, and then we have that same team collaborating really closely with our go-to-market motion on the enterprise side, mid-market enterprise side, where they're feeding, you know, product qualified leads into those things, say 'Hey, we have this big customer that just started using GitLab in a much larger way, but they're a named account. They're, you know, potentially seven figures of revenue a year. Let's go, you know, have sales reach out to them and build that relationship'. 

[00:06:02] Scott: That's super interesting actually. I don't talk to a lot of people. I feel a lot of them who have this PLG motion, they really struggle in that kind of intersection between the two. It's kind of like, the handoff or the kind of like the, you know, it's not a handoff, right, 'cause it's like continuous on both sides? It's like as soon as they upgrade to that enterprise motion, they're still gonna be using the same product. They're still gonna be going through the same growth loops. I actually would love to hear you, you know, spend a little bit of airtime on what have you learned in making that partnership work. 'Cause it's like, in a very real sense actually, your team is probably the primary intersection between like the commercial arm and the R & D arm or the product arm. What have you learned in the past four years about how to make that a successful partnership?

[00:06:49] Justin: Yeah. The first thing is having a role like mine has been incredibly value in that we were arguably failing at doing that well before we centralized it because you had, you know, pricing function, a growth function, they had reported to independent leaders. And then you had the go to market side, you know, driving that enterprise sales motion. And each of them had to collaborate with each other. And each of them had to go break down problems and figure out where the rough edges were and smooth it over. 

And so having a singular leader... and then having a singular leader on the sales side too, we have a leader over self-service sales. Her name's Allie and Allie is responsible for that number and collaborating closely with me and my team, and then is a conduit to the rest of the go-to-market motion and the rest of the sales org. That's been really great to sort of uncover those problems. 

So, as an example, you know, it gets really murky in mid-market because it's pretty easy to say, 'Hey, SMB customers, by and large, they're gonna self-service. They're gonna go through that PLG motion. They don't want to talk to sales'. That's largely true. Enterprise, you know, today... very few enterprises do go through product-led growth motion. They do sometimes, but it's a very small number relative to the revenue that's driven from a direct sales motion, right?

But in mid-market, they're kinda in and out. Like one quarter, they're like, I don't wanna talk to sales, and then three quarters later they do. And so figuring out where those rough edges are and where we need to either change process on the sales side to make sure that that customer can be supported through the product directly, or build better product, better systems, better integrations with billing tools or with whatever so the customer can self-serve themselves out of a problem without having to talk to sales or without having to talk to customer success or solutions architects or whatever it is, right? 

And so it's all about talking very regularly. We do these quarterly reviews where we look at where those rough edges are. We take support data, we take feedback from the field, and we take what we're seeing in product data, product usage data and interactions with those systems and tools. And we say, 'Hey, where do we need to prioritize? Do we need engineering to go do more work over here? Or do we need to go consider a process change and how we scope accounts or how we reroute inbounds' and whatever it is, right? And that’s worked pretty well. 

[00:09:03] Scott: And that’s worked pretty well.

That's very interesting. I'm like curious, at least at Dropbox, like a lot of the growth teams, they think about activation, they think about retention, kind of, I would say like ultimately upstream of financial metrics. But it sounds like in a very real sense, you're partnering with a team that are commercial team. They're presumably gold on ARR. How do you think about metric setting for your team? Or like, is it more like, you know, you think of yourself as like this giant umbrella team and like some parts of the team care a lot about activation metrics and then some parts really care about how that converts into commercial. I'm curious, like just generally how you use metrics within this growth org that is so deeply kind of partnered up with the go-to-market side?

[00:09:46] Justin: Yeah. You read my mind. You're picking up on something that I think is super important. You have to goal, you have to create metrics for those teams that align when you're in this kind of organization where you have both motions. They have to align. So the growth team, instead of like a pure growth metric on this sort of first order side, they share a number. They don't share a number. They're not variable comp like a sales organization, but like the team's goal is a contribution towards the bigger, in that case, first order number, or you know, product qualify leads into that, right? But it's a first order number in that side of it, right?

How many new logos can we get from that product-led growth motion and from that self-service sales motion on the go-to-market side, that team that I said Allie leads. And then, you know, on revenue expansion, it was an expansion team, right? A depth of usage retention, that kinda loop.. There are metrics there that it's about ARR, it's about what ARR is expanding, not necessarily, yes, the sub metrics are important. Not to say we don't look at them, but what is the goal of the team? The goal of the team is similar to the goal of the team on the go-to-market side. And that drives a lot of alignment 'cause then you can have easier conversations around what are we prioritizing and what matters the most. And you don't have to squint to connect those dots.

[00:11:02] Scott: Yeah, that's actually, it's in a nice, I mean, because we kind of went through this at Dropbox too, where it's like I own the engineering side and then I worked with a commercial, or someone who was on the growth, like the commercial side. And I think we always had these arguments. It's like, cool, we care about activation but we care about money. And it's like, yes, there's some linkage between those two, but you're kind of talking slightly past each other. It sounds like at GitLab, you've solved that problem really well. I'm actually curious, like, it's pretty uncommon for an R & D team or a product engineering team to be so focused on revenue.

So I'm actually, a kind of hobby horse of mine, what have you found about recruiting onto those teams? Like the types of people who are really attracted or like just don't fit in that mode? Or do you think generally, product engineers, like growth people kind of can be slotted into that kind of unilateral financial focus.

[00:11:54] Justin: Yeah. Recruiting is really hard, I think, because what I wanna look for in an ideal candidate on one of those teams is they know PLG really well. They can speak that revenue language. And ideally, in our business, they have a little bit of exposure to dev tools and SaaS businesses.

All three of those things is really hard to find. But I think it's teachable. I think it really is 'cause, and this is true, I think of any product person growth or not, they wanna understand how their work connects to the impact of the business. They wanna know, if I do this thing and move this lever and move this number, does that mean that the company grows? Does that mean my equity increases in value? Does that mean I get paid more next quarter or next year, right? Like they want to know those things. And I think the closer you can connect those dots, the better.

The challenge there is that, you know, especially for a growth team, you want them to have a really quick feedback cycle. You want them to be able to ship something and know that it worked. Well, that's really hard to do with revenue and we don't, right? We just can't, right? Because you don't know if a thing you've shipped is gonna impact a core revenue number because sales cycles might just be that much longer than your release cycles, right?

And so you have to spend some extra time connecting the dots between say, an activation metric and what the revenue impact of that is. And so we spend a lot of time with... I have a data analysis function that reports into me as well. On the product side, I run it for the whole product division, and then we work really closely with our FP & A partners to sort of build that connective tissue and say, okay, we've moved this lever, this happens. And so we know that if we increase these things by this much, we have a good shot at hitting those first order numbers a quarter out from now, or two quarters out from now. 

[00:13:31] Scott: Cool. Awesome. I would have to say that it's pretty rare that a company kind of figures this whole thing out in the way that it sounds like you all have.

I'm curious, like if you had advice for a company that's maybe in a growth stage. They're, you know, maybe PLG-focused, but they have a working go-to market function and they don't have this like unified model. What's your advice? It sounds like you kind of were at the ground floor for helping create this unified model. What's your advice for someone who aspires to have this in their organization? What are the first steps that need to happen in order to start to kind of assemble these disparate functions under one roof? 

[00:14:09] Justin: Yeah, totally. I’ll say two first. Like, we're not perfect. There's a lot of warts. You know, we're an adolescent, publicly traded company, and so there's still a lot of growth we have in front of us to mature this thing. I think we're fortunate in that we did grow really fast and we grew off the backs of a PLG motion, and then enterprises started to love this product and really took to it.

And so we were in a unique position to be successful with it, but there's still lots to do. You know, but to your question on advice on sort of how do you start this? It really has to start with alignment at the executive level with the leadership of the company. 

Especially in a startup, right? It's really easy once you start to see that enterprise motion take hold to get really attracted by that, and over rotate in, 'Oh my God, we can close seven-figure deals? What if we could do three seven-figure deals a year?' And then you put all your eggs in that basket and you neglect your product-led growth motion.

I talk to peers of mine and so many different companies, they struggle with this all the time. Like, how far do we swing that pendulum? You have to get crystal clear on strategy with the leadership team whether it's a small company and it's just the founder or if it's a larger company, it's the entire executive leadership team. Get aligned on what the goals are and abstract the goals from like PLG or not.

That's why I brought up first order. We care about first orders at GitLab a lot. And so we're looking at a first order number. How we get those first orders? The grand scheme of things doesn't really matter, but we are able to create a healthy balance because we're not saying, you know, SMB growth from new logos, from a product like growth motion, that's specifically the goal, or, you know, only enterprise new logos through a direct sales motion.

And that's the goal. Like we are intentional about how we communicate it. So it lets people collaborate and find the right strategy, the right direction, the right body of work to go tackle those problems. But it really starts with alignment there because, you know, where we failed in the past at GitLab is, you know, orienting too far one way or another, whether that's a pricing change we make or whether that's, you know, a product strategy direction we take or something like that. And then, we learn and we iterate, but we might have went too far in one direction, and have to course correct. And so, if you can set that clear upfront with the leadership team, that makes it easier to collaborate across the organization to set those goals.

And then I think I would give the advice on the metrics thing we talked about. Figuring out how you can align a goal between those disparate functions helps drive... it just makes their job so much easier. So my PMs spend a lot less time arguing, debating on what to do with their counterparts when their stakeholders from the sales org coming to them yelling that they need some feature. And you know, they're saying, oh, but we need to do this for growth. Like, very little of that happens because you have those aligned set of goals and those metrics. 

So I'd say that's super important too. And then write it down, like write down the strategy, right? And get a lot of people to react to it and get a lot of people to align to it. Then that will also help you. 

[00:17:02] Scott: Cool. I'm curious, your remit is it's growth, it's pricing, pricing and packaging kind of a sense. Is it a centralized pricing and packaging? Like does it cover enterprise pricing and packaging as well? 

[00:17:15] Justin: Yeah, so GitLab is one price book for everyone. It's publicly available on the website. You can go check it. Yeah. 

[00:17:21] Scott: I was gonna ask about this. Okay, great. 'Cause GitLab is famously very transparent with their customers about everything from culture to pricing it sounds like. Okay. I would love to hear you talk about designing a pricing and packaging that works at both ends of the scale and how you think about like, it sounds like you have one price book for everyone, which is super interesting. Is that like a choice or is that a necessity? Can you make it work both like, you know, what are the pros and cons of that choice and how the heck did you do that? Just like literally feasibly do that across a self-serve PLG motion all the way up to like a big seven figure enterprise deal?

[00:18:01] Justin: Yep, totally. It makes a little harder to be honest, but I think there's a lot of pros to it, and I have to give credit to Sid, our founder. I showed up and this is how they were doing it. So I've only evolved it and improved it over my time here. But the premise is we think of this through the lens of what we call a buyer-based tiering model. And so if you look at the tiers and the products it is a singular price book, like I said, but we think of it through who is the primary buyer and what size of organization are they in, and what level of the company are they in, right? 

And so if it's a really small company, the primary decision maker, the economic buyer is, you know, the CTO-founder that has, you know, 10 engineers reporting to them, they're gonna make all those decisions and they need tools that make their 10 engineers successful. 

If you're going up to the enterprise the buyer is a cTO that has a thousand people in their organization or a CIO that has, you know, hundreds of people in the organization and has to consider like, you know, massive enterprise needs. And then I have a procurement department and so on and so forth. And so when, we created buyer-based tiering model to align to what that economic buyer is.

So for a given tier, your likely buyer is this type of person. And, so I don't have to get involved in every single feature tiering decision. I give that guidance to the product managers across the business, and they're able to independently operate and make the decision for a new feature they build based on that guideline.

And then for the go-to market motion, same kind of thing. Where should an enterprise land? Well, they should probably land an ultimate, which is their highest paid tier because that buyer aligns the most naturally to those needs. They need security capabilities, which is the cornerstone of the ultimate tier. And so they need that, and that's where we should start with them, right? Where a smaller customer could probably start on free and then work their way up from there, right? So, that's how we've oriented it, and that's worked pretty well. 

What you don't see is how do we handle that on the backend, because you might, you know, you're not gonna necessarily pay less price if you're a large customer. You know, that's just the nature of enterprise purchasing. And so we create you know, volume-based discounting that, you know, models and things like that to help the field operate so that they can scale organically with those customers and operate more efficiently.

[00:20:14] We use promos if we need to for the smaller customers to sort of land small, targeted in different markets and things like that. Because we are very public, it's like there's three tiers. There's some add-ons. Now we obviously have AI capabilities like most people do and so, it's become a little bit more complex, but it's all the same, priceless, all the same price books as a starting point for all customers.

[00:20:34] Scott: Cool. Awesome. I'm curious how you think about pricing and packaging and kind of I think every time I talk to folks, I think there's this concept that, you know, pricing is a way of... it's like pricing and packaging is a way to make money, but I know you have a slightly different take on the function of pricing and then also the distribution of what's hard between pricing and packaging. So, maybe just talk a little bit about how you think about like setting price levels and also kind of what is the role of pricing in terms of driving your business forward? 

[00:21:08] Justin: Yeah, totally. Maybe credit to my product upbringing and background, but I absolutely hate it when people think of pricing as a revenue lever. I see it as core to the product experience. You want the pricing to be, and it is, it's like a feature in a way. You want the pricing to be so great that the customer wants to pay you. It's like no brainer, right? You want it to seem frictionless and fluid and you get to this, whether, you know, this isn't necessarily price level thing, but you know, where is the packaging? Where is the monetization point you want them to feel it's like an organic thing. Well of course I'm gonna start paying for that now, right? And you have to think of it through that lens because when you think of it purely through as a revenue lever, you end up making really bad decisions that's gonna look really good on a financial model.

You can model a price increase and say, 'Oh my gosh. Look at how rich we'll be if we do this change'. But if you don't think of it through the lens of the customer, through the lens of the product experience, you're probably gonna get yourself into a situation where you do, in the near term, have a really great outcome revenue-wise, but you create a lot of friction and pain on your customers that makes it harder for them to buy, harder decision for them to make around when to, you know, up tier or when to transact. And the more friction you add, it might feel small in the moment, but the more you add actually the slower your growth, the slower your monetization engine actually becomes. 

And that's a really hard thing to do well. And usually the right solution to that when you're having to make those changes is not a price level problem. It's a packaging problem. And that's usually where people make the mistake at the beginning is like, 'Oh, this product has become more valuable. Let's do price increase, or let's change pricing in this way. Or maybe we're off unwillingness to pay, let's lower prices. What you probably should be doing is thinking about packaging and trying to solve the packaging problem so that you have the right packages that customers can organically grow through. Instead of forcing a price level change to sort of meet the market where it needs to be. 

[00:23:02] Scott: That makes sense. I'm actually curious, like on the packaging side you know, there's obviously for the past 20 years honestly, there's been good, better, best price or packaging where it's like, each tier kind of is a super set of the prior tier.

I'm actually curious, do you think it's like, always linear like that? Or is it like, you know... obviously in a Salesforce context, you can have very complex, super bespoke packages, right? You can buy revenue cloud and this thing and that thing and this thing. It's kind of almost like a shopping cart of like random stuff. 

How do you think about packaging for GitLab, and how do you think about designing great packaging that it sounds like one key thing is that different packages in some sense have very different buyers. Like, it's kind of they're targeted at different buyers, but how else do you think about clever ways of using packaging to kind of facilitate business growth and not just kind of thinking about how do I juice this number from $9 per month to $10, right?

[00:23:52] Justin: Right. Yeah, your correct observation, like, good, better, or best is sort of the default. I mean, we have a good bit or best, you know, packaging model. But that pendulum swings and I think you have to adapt to that pendulum as the market evolves. And so our solution to that has been through these add-ons. We've had a couple add-ons that we've launched over the past couple years.

Obviously the AI ones make a lot of sense. We also have an enterprise agile planning add-on that we've launched, and I can tell you the story on that one briefly. You know, we identified, 'Hey, there's actually this carve out of the product that might not be the natural sort of tier evolution that a customer might need'.

The concept of this is, you know, GitLab is a developer tool. It's a dev DevOps platform, DevSecOps platform. And it has everything you need to write code, secure software, build and verify, and deploy that into production and monitor it. It also has planning capabilities, but the industry leader in planning capabilities is Atlassian and Jira.

But some customers absolutely loathe Jira and love GitLab, but they might not want to sort of pay that full freight. For they want our ultimate tier, but they might not be comfortable paying that full freight for someone like me who's never gonna really contribute code. So how do we solve that problem?

The way we have solved that problem is you need to blend a discounting. You can create incentives for that customer in that simplified, good, better, or best pricing structure. But what if we actually carved out an add-on that let that customer go and say, Hey, I actually have a thousand non-developer users in my organization. I would love for them to also use GitLab. Let's go create a package for that. 

And so that's a tactic there to solve that problem. But you have to be careful because there's obviously the technical risk. If you start to modularize things too much, you create cannibalization risk because if customers have that Salesforce like menu, it's like, well, great, I only need this. And then all of a sudden, you know, their total contribution on revenue goes way down. And then you have a big cannibalization problem on your hands. So you have to be careful there. You have to sort of do it when you think the product market price fit is right. And you can actually capture that market. The worst outcome is like a Cheesecake Factory menu of options, right? You need to have really good offerings, and logical modules or add-ons that you pull out. 

AI has been the easiest one because everyone understands it. It's incremental GPU infrastructure is way more expensive to drive inference. Everyone's doing the same thing. They're all copying each other right now. But you have to be really intentional when you're thinking about doing that for part of your core product. 

[00:26:22] Scott: Yeah. One of the things that I've observed is that, especially as companies get bigger, older, kind of have more product features. It's this inevitable tendency to just have more configurability, more options. And the best companies kind of go through this like, I think you used the word pendulum. It's like, cool, you let the complexity proliferate and then there's this like thermostatic reaction. It's like actually, okay, let's simplify again.

And it's kinda like this cycle of flare and then simplify, flare and then simplify. How do you think about that? Like, what is the external signal or internal signal that you're like, actually things are, we're going a little too crazy. We have too many add-ons. It's like confusing. And what's the antibody to that or the kind of thing that tells you actually, let's like, think about this again. Maybe we should do a simplification phase. 

[00:27:08] Justin: Yeah. The best way I like to do this, I've done this in other places is through understanding the maturity of the part of the product that you're considering modularizing or creating it add on for. 

So I'll run a study through some pricing research where we'll say, you know, GitLab's a platforms, we have a lot of different capabilities, and we'll say, 'Hey, for all our customers, what are you currently using GitLab for? And we'll create logical categories with the product leadership team and the product managers.

And they'll say, here are a bunch of other tools that do similar things. Are you also using them, and what are you using them for? And so you have this matrix diagram that'll tell you, 'Hey, you know, some percent of GitLab customers are also using Jira and using Atlassian tools. What do they use, Atlassian tools or they use it for enterprise agile planning? Great. Can we create enough depth of value? 

And then you actually go back with like a UX research study and you say, 'Hey, how good are we at this? Are we good enough where we can command a price and get a customer to dump that other tool and move over to us wholly? Or are we not quite good enough yet?' And actually, the sell there, the value, is the fact that you have this bundle of offerings under a single price that's ostensibly cheaper than buying each of those things in piecemeal. And so you might, as a business leader, as a technical leader, you might make a trade off and say, 'Hey, GitLab's a little worse at this thing than the best in class bespoke, single feature competitor. But I'm willing to make that trade off because I'm getting this bundled price that's just way more affordable for me at scale than buying each individual tool'. 

But if you, if it can't stand on its own, maybe a way to simplify it is. Could you spin out that product as a separate business, and truly spin it outta the company? And if you can, then it might make sense to make it a module. You gotta do some more research. You gotta understand your cannibalization risk, you gotta do all those things. But that's a pretty good signal versus just sort of picking and choosing. My belief here is the pendulum swinging for me as a leader, I need to make sure that's as minimal as possible. 

Swinging that pendulum hard one way or another is a really bad outcome because you're just thrashing the market. You're probably making your investors grumpy. And your customers are getting confused because three years ago they signed a deal that gave them a bunch of functionality for one price, and then three years later they're gup for renewal. And, they want the same functionality, but now they gotta go figure out this complex pricing model to do it right. So you have to sort of narrow how much that pendulum will swing and then use those levers, like I said, understand the depth of the product, understand the quality of the product, before you start making those decisions.

[00:29:35] Scott: Okay. There's a bunch of things I would want to dive in. Actually, one thing you said, which I think is interesting is, it sounds like you might be using the packaging to kind of almost like... it is like you're designing the theoretical packaging, and then lensing through what is our current product capability like, would it even support this kind of concept of a packaging?

Like, is this feature strong enough to kind of be either a separate add-on or module or is it have to be packaged in this way and would a customer set buy that? How do you feed that back or how do the product teams that are building those individual capabilities, how do they consume that information and then use it to make, I would hope that they're using that information to kind of go back, 'Okay, let's go make this product roadmap like different, because actually we want to be standalone, so we need to go beef this up. Or actually we're totally cool with this being like kind of a supplementary product as part of this major package'. Like, how do you or your team feed that information back to the product org in a way that they can hear and then take action on? 

[00:30:32] Justin: Yeah, totally. Yeah. And you're picking up on an insight here that's something I'm really proud of. You know, they are part of that process and we make it. It's almost like, packaging research. Like we don't change packaging that often, right? We do a lot of research, we test a lot of things. But we don't actually put out a GA product all that often, right? But we do that hand in hand with them.

So, they're sitting there, you know, helping contribute to a conjoint study or helping build out a leader killer filler analysis, right? Sitting with customer, my pricing team is going on customer calls, talking to customers about product capabilities and understanding more deeply how a product works and what motivates that customer.

And it's very much a loop that that packaging research feeds back into product strategy. And you know, 'cause we might get an insight, 'Hey, there actually is a willingness to pay for this thing if it was more mature. But right now our customers are using this as a competing offering. What could we do on the product side to mature that capability? So like a year from now, we might make a different decision on packaging', right? So we do a ton of that.

The other thing I'm a big fan of is testing into it. Credit to the Datadog team who I think, well, at least they made this, they do this a lot and maybe made it the most popular or most successful.

But you know, we'll take a thing where, 'Hey, we have an insight that a customer would be willing to pay, you know. This is an add-on, pay for this as an add-on, or, you know, we pull this out and maybe we can try, you know, a consumptive metric for it or something like the, you know, usage-based pricing metric for it or whatever.

And we'll go for a new product, particularly. We won't launch it GA, we'll hold it back for a little bit. Make it limited availability, make it, you know, beta or something like that. And we'll go test into it and we'll ask a customer, 'Hey, what do you think about this? You know, would you pay this? Like do the live willingness to pay research with that customer and the account team on the call and walk through it 'and explain it to them.

Or we'll carve out a cohort on the part that growth side and say, 'Hey, here's this offering for you as a promo or as a one-off thing'. And that's plays two roles. One, it's to validate some pricing assumptions we've had, and two, it gives really good feedback back to the product team that's building the thing to understand, 'Hey, are they actually there yet? Like, is the depth or maturity of this offering good enough yet, or do they need to keep going?' 

[00:32:49] Scott: That's cool. I'm actually... I'm struck because I feel like at Dropbox we never quite nailed this interaction between the pricing growth team and the rest of the product organization.

So, one of the things I'm curious about, like in my head, in theory, it's like everyone's aligned. The business wants to grow. We all want to maximize, you know, revenue growth or whatever the right growth metric is. But in practice, when we would go talk to these product teams, they would have different... They weren't as engaged in this like, 'Here, let's tear apart this conjoin and understand why exactly is this feature not enough to be a killer or whatever it is. How do you align? Like is it... is it like a selection of people thing? Is it a leadership thing? Like, how do you think about the actual ultimate alignment between those things? Or do they also have a revenue target as well? Like, I'm curious actually...

[00:33:37] Justin: Yeah. Not as much, I don't think. 

[00:33:39] Scott:Yeah. 

[00:33:40] No, it is a leadership thing. So you know, in any pricing study we do. We sort of treat one of the peers on the product leadership team of me. So this is, you know, VPs that are own vertical slices of the product portfolio as sort of a GM of sorts, right? So we'll have them, you know, join end-to-end the whole study and be directly responsible for it and contribute directly to it. And they'll choose to bring their individual PMs or their directors or leaders along with them.

But it really starts there. So I have someone that's a peer of mine reports to the same boss, Chief Product Officer along with me and my pricing team in doing that analysis. And then what's great about that is, you ,know, we'll do a readout where we say, 'Hey, we ran a conjoin and here's what we learned'. And I'll have, you know, Sean, the guy that leads pricing for me do that. 

But, you know, one call, one recording, like that's gonna go over the head of a lot of PMs. And so having their leader as well-versed in that data really helps solidify that message and help them make good decisions down the road.

So it's not, I'm not a bottleneck or my team's on a bottleneck every time they wanna make a decision, right? And so I think that's what's made the most difference there in helping that be successful. 

[00:34:49] Scott: That's cool. Yeah. This idea of product VPs, leaders of these different product lines being more GM, so they're forced to understand the financial implications of the work that they're doing. And then kind of having them be deeply involved in the analysis- the packaging analysis- is smart. 

I suspect all VPs wish they could think like that. It's like no one joins a company like this and it's like, I don't really care if we make money. But I do find that a lot of companies, they kind of struggle on this front.

[00:35:19] Scott: Maybe it kind of resolves down to what you just said way earlier, but pricing is product. Packaging is product. It isn't a separate function. It is the same function. It's just a different part of it. It's like a bit more mathematical in certain ways, et cetera. But if you own the product, you own the pricing, you own the packaging, like you are an owner over that, you have to be. And then having it all roll to the same CPO, that's also smart. That person's now accountable for revenue. 

[00:35:44] Justin: This is a thing for me in my career I struggled with a lot earlier where I was a, you know, a decent, I guess like future PM where like I knew the product really well. It was technical, I could build good customer experiences, but, the business of the product was just foreign to me. It's just a different language. And I struggled with it, so I had to like, really invest time to understand these things and ask questions. 

I find that these product leaders that do this, it actually makes them more successful with their go-to-market counterparts too. 'Cause every go-to-market leader will come to them and say, 'I need you to build this because it's gonna make me millions of dollars'.

And they're gonna have to say like, well, what is it? And they, if you only look at it through the lens of the technical or product or user experience capabilities of the thing they're asking for, you're not gonna be able to either push back on them and say, 'You're wrong. It's not gonna make you millions of dollars.' Or, 'You're right. And here's an actual model that can help me articulate if this thing is a good investment or not'. Because a good VPs have really good ROI on what they choose to spend their time on, and the ones that aren't versed in that language struggle right at the end of the day. 

[00:36:49] Scott: Yeah, I feel very similar early in my career.

You know, I was an end manager. I always struggled when I was working on teams where it was like, the work we were doing was too decoupled from the ultimate. Like, how do I tie this to the business value? How do I tie this to how this helps us grow faster, et cetera?

And, as you grow on your level, you kind of like are expected to understand the business more. But I think it's like, what I have definitely found is the most effective product leaders, it's like they understand that the product exists in a market. And for better or worse markets transact on money, and so you really do have to understand that. I mean, I guess if you're in pure consumer, it's slightly different. 

But it's like, the point of it is that in B2B software, it's actually the best product leaders are actually highly commercial. They really understand this stuff, and they understand that how your product is purchased, bought, you know, consumed the value of it.

It is a mix of product and it is a mix of commercial, and those two things are actually the same thing at the end of the day. And it sounds like you guys have done a good job of inculcating that into the culture and building that up. I will say that in my experience, it is increasingly common, but you cannot rely on that always being the case, maybe. 

[00:38:03] Justin: It's not. Yeah, but you know what though? It's there, right? 

[00:38:05] Scott: It is.

[00:38:07] Justin: The data is there, like every, if you're listening to this and you're like, I don't know, my organization's not right... Go ask your UX research team how many times a customer brings up pricing when they're asking them about a given feature and if that feature works for them. They always do. It's one of like the top five things that show up in our UX research studies. 

And that might be, they like it, it might be they hate it, but that data is there. And so if you start to look at those signals, you can probably build, build up that vernacular and build up that knowledge pretty well. Because people are gonna tell you, everyone has an opinion about pricing. Everyone has an opinion about the sort of unit economics of the business. 

[00:38:43] Scott: Yeah. And then the other thing I would say is, if you're in a part of the org where it seems to not care about this stuff, I can guarantee you at the highest levels of that business, at some point, someone gets it, you know. It may not have been translated down through every part of the organization. But, I can guarantee you that, especially any successful business, like the C-level execs and all those people, they understand that at the end of the day, our job is to build a great product and exchange that for money. And that is the lifeblood of every commercial entity. And if you're not hearing it, it might be that you're in a part of the org that hasn't quite heard the message, but it exists and like, you know, I do encourage you to go seek out those other kindred spirits 'cause they definitely exist inside of that business if you're at all successful. 

One thing I would love to like, kind of maybe tail off on is you mentioned AI and I think the biggest thing that everyone is thinking about right now is AI- how it affects the product, but also how it affects commercials. And you know, I think maybe two years ago it was all about co-pilots. It was all like, everything's gonna be a co-pilot, so it's just like an expensive seat or something like that. 

And I think I would observe the past year, things are starting to get weirder or maybe different and like kind of realizing that the co-pilot is not some like universal solve. I would love to hear your thoughts as someone who's in the market who's like pushing this stuff forward. GitLab has a lot of AI-based features. Like, what are you seeing? What are you most interested in? What are the areas that are most exciting to you in this now period and also in the near future?

[00:40:11] Justin: Totally. Yeah. And your insight's, right? I mean, everyone just sort of followed the leader, right? As soon as the first person, you know, made a tool and then, 'Oh, it's an incremental 20 bucks on top of your base subscription' and everyone followed suit. And then what you've seen is, you know, companies pulled back on that. They integrated those core capabilities back in with their product and behind the scenes they're driving ASP through less discounting, right? Or something like that. 

But yeah, it's evolving fast. Well, the first time for me too, in my career where I've seen the underlying unit economics also evolving really quickly. So, you know, this isn't a DeepSeek podcast, but like, you know, that is definitely driving a lot of conversations right now around, 'Hey, we price this intentionally because we had a pretty good understanding of our cogs', but now that's changing. And the usage patterns are changing and so on.

So, I think that things are interesting to me in the long run. You know, right now a lot of the tools are, you know, assistance to your... I jokingly call it... you sprinkled AI over your existing product, right? And so it'll sit next to you and help you do a thing. And for us, that's code completion. That's code generation. That's helping you understand why a pipeline fails, right? These are all really great tools and our customers love them. But that's what everyone's built so far. 

Where it's going, I think, are kind of two similar directions. One is, 'Hey, I wanna define a workflow and let AI...' It's like Mad Libs, right? 'I'm gonna write the Mad Libs and I'm gonna let AI fill in all the blanks for me'. Whereas before, you would go line by line and now you're gonna give it the whole thing and it's gonna fill in the blanks for you. And that's more of a... that's not agents, that's the term everyone use. It's not an agent .That is I'm codifying a workflow and I'm gonna give AI a lot more autonomy to go execute that workflow for me.

But it's still similar in that it's an assistant helping you along the way, but you have a lot of control over it. So, I think that's a thing that's interesting and I think that's a thing that opens the question to, should there be different pricing models, price metrics, structures for that? Things I've seen in the market that are interesting to me, I think it's Intercom if I'm not mistaken, companies like this where they're actually paying the price metric is upon completion or resolved case. So, it's a pay for success. It's a pay for outcome basis thing. And so you set a price mark for the outcome. You're abstracting the complexity of how many tokens and the, you know, compute and the consumption and the infrastructure cost from the customer. But it's not a per head subscription. It's an outcome-based metric, right? 

And so, if they resolve a case for you and it's a, you know, customer support-based SKU, awesome. And here's the price for it. I think that's really interesting. And so is it a price per workflow completion kind of metric, right? It's kind of an interesting way to think of it. 

Or is there a hybrid model where you say, 'Hey, you get a bunch of workflow runs, you know, as part of your base subscription of this product' and then incremental costs X, right? And so the customer can get value out of that new offering without having to make that complicated purchasing decision. I think a lot of customers, unless you have a really great massive scale, absolutely hate really complex consumption-based pricing models. And that's why SaaS was so successful because you could pay 20 bucks, 30 bucks, whatever it is, and you could access everything you need.

And so the pendulum swings. The harder the pendulum swings towards that I think you'll get some reaction in the market to it. And so creating a nice hybrid balance where the customer gets a lot of value for what they're already doing and already paying for, but then you're still capturing the upside of that value if that product is really doing a great thing.

And then the other thing that I don't know what we're gonna, what's gonna happen, and I read a lot and try and sort of think through this, but when it is truly agentic where an agent is doing everything, and it's not madlibs anymore. They're writing the madlibs and filling out the madlibs.

What does that look like? Is that purely consumption? Is that the right model there? Because it is, you know, at the end of the day it's tokens, it's GPU workloads, it's H100s running in someone's data center. And you do that or is there a more, you know, closer to a value-based pricing price metric you can put on that, whether it's outcome-based or something else? And how do you structure that? 

So, I don't know if I have a good insight there yet on what that should be, but I'm really interested to see where that goes, because I'm seeing a lot more of those agentic tools from smaller companies start to come into the market and they're very cool. And I think there's something there.

[00:44:30] Scott: Yeah. Everything you said is stuff that we're seeing too. I think a couple things that actually are really interesting given what you said about your buyer-based segmentation. One thing we found is that. Who your buyer is matters a lot. If your buyer is an engineer, they're kind of conditioned to think in terms of resource spend and pure consumption or usage base. It's like they've been trained by AWS for 10 years at this point. 

[00:44:56] Justin: Right. Do you have an EC2 instance running still? You gotta shut it down or not, right? Like that's exactly right. Yeah, yeah, yeah.

[00:45:00] Scott: Exactly. And so then, as you move up the stack or you change, you move around like pure consumers, you know, there was a time where cell phones were closer to pure consumption, but like, consumers hate that.

[00:45:12] I'm like, how I'm supposed to predict exactly how many minutes I'm gonna call my mom this month. What the heck am I supposed to do with that? And then you get to these like kind of interesting simplifying abstractions now where it's like, you know, a cell phone plan is like a flat fee, but then there's this data pack overage and all this stuff and the simplicity is really what drives the value or matters a lot for consumers.

I think one thing you said earlier, which I wanted to pull out here is that ultimately, most consumers, no matter who they are, you want them to think in terms of value of your product, not price, not dollars. It's like, what is the value I'm getting and think about that all day, every day, that yes, more value, more value, more value, and then eventually you turn it into money. 

But in a pure consumption model for a consumer, you're forcing, especially in something that's like if you are metering minutes on a cell phone, that means that every call, they're like thinking, 'Oh my gosh, am I gonna run down the clock? Like, let me end it. It's 59 seconds, turn it off', you know? And that leads to these really perverse, terrible behaviors. And so a more all you can eat makes sense. We're seeing a lot, I mean, ChatGPT is the most famous subscription on Earth right now. It's this hybrid, it's simple, but it also does have metered limits in it because there's real costs underneath it.

So I think it's like buyer based thing is kind of like really understanding your buyer and both like how do they see the value and how do they translate that into your pricing? But then what are they comfortable with buying now? Because senior executives, I think are pretty comfortable with, you know, outcome-based pricing or even usage like in the form of EDPs that are, you know, like million dollars. Spend it down. They've been...

[00:46:38] Justin: Yeah, yeah, yeah. Volume commitments and they're... 

[00:46:40] Scott: Exactly. And so…

[00:46:40] Justin: Right. Commitment-based, draw down. You're good. Yeah. You get that model. 

[00:46:43] Scott: Yeah, exactly. But I think these little, these startups are doing some fascinating things. Like I was talking with one who... they're like a customer support agent, so like an Intercom, but like fully auto, it does everything. And their pricing, they sell to enterprise. What they do is they do like a one month case study with you and they basically mathematically prove the resolution improvement rate. And then they just charge you like per percentage of improvement. They just charge you like 100k. So it's like, if we improve by 5%, we charge you 500k. If we improve you by 10%, we charge you a million.

And, is that outcome-based? Is that usage-based? How do you do it? Because it's these large deals, they can do this one month case study and have it be like, you know, cashflow positive, et cetera. And I'm like that's fricking cool. That would never work for a consumer. Like how would you even do that? It wouldn't make any sense. 

But, it's like you're seeing this really interesting exotic stuff that's kind of like blurring the lines. I wanna tie that back to a question for you. 'cause you run a large business. You have, you know, tons of revenue flowing through the system. How do you think about these exotic stuff? Are you watching it, are you testing it? Are you gonna wait for something to emerge? Strategically, how does someone who has a large business that's already running kind of think about this new exotic stuff?

[00:47:54] Justin: Yeah. I love buying those, like startup founder's lunch and just talking to them about what they're doing 'cause it's just, it's fascinating to me. And what I've seen typically happens is they figure it out and then the larger companies follow the models, right? And so for me, yeah, it's definitely watching. It's definitely learning. You know, yeah, we're a large publicly traded company. You know, I can't even tell you what we're considering doing, right? And when we make a change, it requires a lot of resources, requires a lot of intentionality, it requires public statements, it requires a lot of that. And so, we have to spend a lot of time learning you know, talking to customers, running research, and then learning from what these, you know, innovative startups are doing, you know, commercially, with pricing. And then sort of folding into the plans, right? But we end up moving slower on that because of the nature of the size of our business.

And that's unfortunately a thing that every business has to deal with, right? Unless you're, you know, a unit within a much larger organization, you have, you know, you're not material and you can kind of hack around things and do whatever you want to. But for me, yeah, it's learning from those companies, you know, it's talking to a lot of them. You know, building good relationships with folks that spend a lot of time with those companies in the market. You know, the big firms that help with pricing studies and stuff, like, they actually see a lot of this firsthand and have really great insights. So, you know, picking their brain, talking to them, you know, it's all about that.

[00:49:14] Scott: That’s cool. Yeah, I think, I think especially given what you said earlier around pricing and product being deeply intertwined, it's like studying what they're doing and then how does that change the product, you know? 'Cause it's not just about pricing model. Like, in that case of that company I was talking about with this ROA thing, they have to build essentially auditable data flows for proving that it's better, you know? And so, there's not a feature that you necessarily would think about. You're like, I'm supposed to build a bot that does this thing. And it's like, well, the audit is the key to the case study landing and actually getting that check signed.

And so, suddenly that's a core part of your product. And then also, over time, if your bot gets better, that number's gonna get better, right? Your resolution, you know, it's like you're gonna need to rerun that case study. Okay, how are you gonna do that? How are you gonna think about this? 

And I think what you just find is that especially with this AI stuff, I think it's kind of feels like mad science land, and it's just kind of really cool to talk to these earlier stage companies who are doing stuff that like, frankly, three years ago, you'd be like, no one will ever charge that way. That makes no sense. No one's gonna buy into that. And now with AI, it's just kind of opening up this huge horizon of like the art of the possible. Sweet. 

Well, Justin, this was awesome. It's rare that I talk to someone who has actually assembled the Avengers. It's like, I have the pricing, I have the product, I have it all. And also, it sounds like you have the leadership team that kind of appreciates all of the pieces of it. So I personally learned a ton. I think you guys are doing some really incredible stuff and you're doing a lot of things right. 

Like, I think, you know, GitLab is an incredible company on many dimensions and honestly now, I'm just even more impressed about how you guys are thinking about pricing and packaging. Clearly super thorough. Wanna say thank you and yeah, thank you so much for joining us. 

[00:50:58] Justin: Yeah, thanks. Thanks Scott for having me. I love [00:51:00] talking about this stuff, so it's great to compare notes. Appreciate it.

[00:51:03] Scott: Awesome. 

[00:51:03] OUTRO: Thanks for tuning into this episode of Unpack 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.