Monetizing SaaS: Episode 35 with David Caughman, Docker's Director of Pricing & Monetization

David, thank you so much for being on our podcast. You have had just an incredible career in monetization. You started your personal journey consulting for revenue analytics. You spent 4 years at Simon-Kucher, which is an incredible firm that has played an obviously immense role in pricing and packaging, especially in B2B SaaS. And that was really just the beginning. You then worked on pricing and monetization strategy at Stripe for 2 years. You mentored A16Z companies, you started your own consultancy, and now you're running pricing and packaging for Docker, which is, you know, everybody knows Docker. But that's sort of what I can kind of piece together from LinkedIn. Tell us about your career journey in your own words. How did you get to now?

Yeah, spot on. Lots of pricing. You know, I, so My, my intention was not ever to get into pricing, as I think it is the case with most people, which kind of happens by chance. But once we get into it, it becomes something that actually is quite fascinating. But for me, like, my main goal was to do consulting. I love the idea of working on large, you know, complex strategic problems for C-level executives and delivering those recommendations. I love the variety. That consulting offers in terms of the different industries and companies that you get to work with and you get exposed to. And really pricing was my foot in the door in the consulting world. And so, yeah, Revenue Analytics was the first firm I started at. They are a very small consultancy headquartered in Atlanta, Georgia. They focus mostly on revenue management and dynamic pricing. So if you think about the revenue management and dynamic pricing techniques that airlines use to price seats, you know, they're taking that same discipline to other companies and industries that have a similar kind of similar company dynamics. So that's, you know, that was my entry into consulting and through pricing. And it just so happened that while I was there, Simon-Kucher was opening up an Atlanta office for the very first time. And so I, you know, I reached out to the partner who was leading that. One thing led to another. And yeah, so that was, and so I started at Simon-Kucher. And as you mentioned, you know, Simon-Kucher, it's a great place for someone who's in pricing to really learn, you know, the strategic foundations of pricing. And I think like what I learned the most there is, you know, while we're giving recommendations again that are focused on pricing strategies, so pricing, product packaging, pricing models, price levels, things like that, you have to have a very comprehensive sort of strategic context that the company is operating in. Because everything like customer strategy, their segmentation, their user personas, their go-to-market strategy, whether they're PLG or SLG, you know, what type of sales motions they do, all of these different facets of company strategy play a major role in the pricing strategy that works is the best fit for a certain company. And so that was a great experience at Simon-Kucher. I didn't want to, I had no eyes on being a partner in a large consulting company like that. Just the lifestyle didn't appeal to me. And so yeah, when Stripe reached out to me, you know, I took that call and yeah, it was an offer that I couldn't turn down. And so I left consulting to— I was the second hire on the monetization team at Stripe. They were a very— not very late stage, but this was 2019. So they'd already been around for a while and they were certainly a SaaS unicorn. And I think like $5 to $15 billion valuation company. So certainly not a small company, but they had waited a while to set up a pricing function. And so, right, I was hired by the guy that was building that. And yeah, I was at Stripe for 2 years. So at Stripe, I was focused on a— I had responsibility for a single product line. And that product line was their Radar software that they layer into this fraud prevention software that is packaged in some cases and not packaged in other cases with the payments, with their payments software. So yeah, that was an amazing experience. It was my first, you know, my first foray into like working in-house at a— doing pricing in-house. But as I was saying, like Stripe was so big that a lot of the, a lot of the implementation, like I was kind of shielded from a lot of the implementation and operational aspects of pricing and just mainly focused still on the pricing strategy. Yeah, so I ended up leaving after a couple of years. I started my own pricing consultancy over COVID. And, you know, my value proposition was, hey, like if you're a startup, seed, Series A company, and you don't have the budget to hire a company like Simon-Kucher Partners, you know, come reach out to me. You know, we'll have a conversation, we'll get you on the right path. And maybe you don't have to hire Simon-Kucher Partners one day and spend that kind of money. And have to rework so many things because changing pricing, as you know, is extremely disruptive to an organization. So that was the pitch there. Yeah. You know, again, like they— I love doing that. I had no— I wanted to keep doing that, but Docker reached out. I didn't know who Docker was at the time. And then I started digging more into it. I started noticing a lot of the similarities with Stripe. I mean, it's a company that has a ton of brand recognition., but they have a unique pricing challenge. And that's that their products, their core products are fundamentally open source. And so it poses a unique monetization challenge that I thought was really interesting and cool. Um, and yeah, so like, yeah, so, and that's, so I started there a couple of years ago and I've been leading pricing at Docker since then.

Yeah. Like I said, I mean, it's just a remarkable career because of, I think what's remarkable about it is the degree to which you have been on the consulting side and the operating side. You've both been in-house and out-of-house, and I'm curious to kind of get your perspective on like, what have the differences been for you between, you know, helping executive teams at a place like Simon-Kucher or helping startup founders in your own consultancy versus working on monetization at the type of scale you must have seen at both Stripe and Docker?

Yeah, I think the biggest difference, like when you're working in-house is that you rely, you're relying on a large cross-functional cross-section of the company to really, to really get things done. You know, consulting is done in small groups of, you know, maybe a manager, a couple of consultants and a partner. And it's data analysis. It's using best practices to deliver, you know, a recommendation. You know, what's completely different about running pricing in-house is that you're also responsible for overseeing the implementation and the operationalization of the pricing. And so that's been by far the biggest eye-opener for me coming from consulting to working in-house. And it's really started just in the last couple of years at Docker. Like I was saying, Stripe was big enough that a lot of that was abstracted away from my position. But yeah, just, you know, you're still doing the same stuff at Docker that I was doing before, focusing mostly focused on pricing strategy.. But, you know, when it comes to implementation, you're talking about billing systems, CRM systems, CPQ systems, customer support systems, you know, all of these things, product design, UX, all of these things have to be working together to really, to really land a good pricing recommendation. And, you know, a lot of, you know, these stakeholders for these systems kind of live at different parts in the company and they've got their own day-to-day jobs, right? They have, they have their own things they have to do. And so really, you know, galvanizing a group like that, I think is super critical to being successful in-house, doing pricing and packaging in-house at a smaller company like Docker.

Makes complete sense. And just as a short playback, I mean, I feel like what you're saying is on the consulting side, you know, you do this great work to sort of like wrangle customer information and do cohort analysis and interview customers and kind of like piece together a recommendation. And that's largely where it stops. Whereas in-house, now you have to go implement the recommendation. And now that means you've got to like deal with what changes happen in billing, what changes happen in the quoting tool, what changes happen in the application itself, who all needs to be a part of that. And we haven't even touched customer comms yet.

Exactly. Yeah, exactly. Yeah.

I once had a guy that was running sort of pricing and packaging center of excellence for a large private equity fund tell me that 70 to 80% of their pricing recommendations were never implemented by their companies, which is kind of staggering. It is.

It is. I'm almost curious if like, if pricing recommendations are even less frequently adopted by companies because of some of the challenges that we mentioned being being, you know, um, but that is, that is, I'd never heard that statistic. That does seem high, uh, and unfortunate.

Uh, yeah. Well, so you've, you've learned from so many different places, and I wonder if we can kind of try to pull some of the learnings from the different places out for folks listening to this. Maybe just going back in time a little bit to Simon Kucher. I mean, Simon Kucher has produced people like you, people like James Wood at Meter, people like Kyle Poirier. Like Simon Kucher has produced an alumni that I think has just been massively influential to the world of B2B SaaS pricing and packaging. Are there 1, 2, or 3 things that Simon Kucher taught you from a foundational perspective that you could package into a bite-sized takeaway for operators today?

Yeah, definitely. I think it just goes back to you cannot, you can't decouple pricing strategy from other components of a company's just business strategy. You know, like I was saying before, um, customer marketing strategy, like understanding customer segmentation, who the target customers are, understanding the buyer personas, the ideal customer profiles, all of the foundational, like, marketing strategy elements are crucial to, to understand when you're putting together a pricing recommendation. Same thing for for go-to-market strategy. You know, is this a PLG or an SLG company? You know, if it's an S, if you have any component, any part of the company is sales-led, like the pricing model has to work for sales because if it doesn't work for sales, they're not going to do it. They're not going to, it's, they're not going to sell it, especially in a multi-product company where they have a whole suite of products that they can pitch customers. You know, salespeople want deal velocity and deal size. So if your pricing isn't giving them those two things, you know, the product is dead on arrival. So understanding kind of the sales component to pricing is crucial. I mean, some of the other like strategic components, of course, like market and financial strategy. You know, if you're a Series A, Series B startup, you're probably not too concerned about profitability at this point. Your focus is on adoption. So like you have to make sure that your pricing just does not get in the way of adoption, is not slowing adoption. And that's a really fine balance to try to make. So yeah, it's definitely the fact that pricing strategy is so much more than pricing. It touches all parts of a company's strategy.

It's almost as if you're saying like pricing is the business's strategy in a way.

Yeah, it's especially in software too. It is a fundamental pillar of a company strategy. Yes.

Do you still think, well, I don't want to put words in your mouth, but let's assume that's true. Pricing is effectively a strategy in B2B SaaS. To what extent do you think most B2B SaaS companies appreciate that or maybe don't appreciate that? Where do you think we are in sort of the sort of the evolution of the market's kind of respect for that idea, appreciation for that idea, or adoption of that idea?

I think so many companies have a pricing— is, it's weird, like pricing is acknowledged as a huge growth driver, but it doesn't get the same attention that even I think, you know, operators, executives acknowledge that it needs. So it's a little bit of a, you know, a little bit of an enigma in that case.

But why do you think that is?

Yeah, I think a lot of people think they can do pricing. I think a lot of people think that it's something that, hey, I can like, you know, spend a couple of weeks, look at a couple of competitors, see what they're doing, and then just do that. Whereas, you know, there's so much more that goes into a company's pricing strategy.

Yeah. Let's come back to that because I think there's a ton that we can pull out for people, but take us to Stripe a little bit. So it sounds like you were in some ways shepherded or, excuse me, shielded from how do we figure out implementation and more, I've got to focus on a specific product that is in some instances bundled and some instances not bundled. Tell us what you learned from that experience. It was a 2-year experience. What were the 2 or 3 most important things that you learned?

Yeah, so let's think about, you know, again, Stripe is a payments provider. You're paying for, you know, 2.9% per transaction on a credit card transaction. Fraud prevention software initially was coming bundled, you know, with payments. But if you really think about it, like I had to ask myself the question, why? Like, does everybody who signs up for payments infrastructure value fraud prevention the same way? And the answer is no. They don't. I mean, so let's say, for example, you've got a retailer who's sending out something that with low margins, a piece of software, like a piece of hardware, you know, that's got maybe, you know, 50% operating margin. If you ship that out fraudulently and the credit card company comes back and says that was a fraudulent transaction, we now need to reimburse that customer whose credit card that came from, like you're kind of screwed. Like you can't get that inventory back. Like that's a big problem, you know, for you. You know, whereas on the other hand, if you're a B2B SaaS company, and, you know, a fraudulent transaction occurred, it's a little bit, you know, it's kind of a pain in the ass to back the revenue out. But at the end of the day, like, it hasn't really had the same impact. And so when you think about the key characteristics of what makes a good add-on, as opposed to something that's being bundled in a product, it's, it's two things like how widely valued is the, is the thing, you know, that you're bundling, Radar in this case. And then among those who value it, how deeply do they value it? And so when you have, when you have something, you know, that you're bundling and it doesn't have the same broad appeal that payments does, but it still has a tremendous value for those who do want it, like they're going to pay for it. And that's a great way to really make up some incremental ARR. And so That was a really important thing that we did at Stripe.

Yeah, that's a phenomenal example. And I think what I'm seeing in my mind right now is that like that two-up of the leader, filler, killer.

Yeah.

You know, where you're kind of looking at the proportion of customers who perceive a ton of value in this versus kind of the average usage in the product. And then you're trying to decide, should this be bundled or should this not be bundled?

Right, right. Yeah. Yeah. Leader, filler, killer. It's, you know, That's, that's a great framework.

What, anything else from Stripe, or is that, does that stand out as like the paramount learning from that, from those 2 years?

Um, you know, another cool thing about Stripe was, so again, so back to Radar, because I was focused on Radar, like they had launched, launched that product very early on in the company's evolution, maybe like 2012, 2013. So when I arrived in 2019, they still have like the initial customers who signed up for Radar back in 2011, 2012, 2013 were still paying and sometimes nothing for the software. Stripe had grown so quickly that it had needed to try to extract that revenue from those initial customers, which is a great position to be in if you can do it. So going through implementing an ungrandfathering process. So basically getting all these people that were on preferential pricing or initial pricing onto the $0.06 per transaction pricing, which was list price at the time. And, you know, when you go from free to paid, like that's, that's, you know, that can cause a significant amount of disruption among customers. And so, I mean, the biggest thing that SaaS companies want to avoid is being on the front page of Hacker News. And so going from free to paid is a great way to get yourself on the front page of Hacker news. So we had to, we had to de-risk that decision as much as possible to try to avoid that situation. And so really starting small and testing and experimenting with the approach. And we found like within our initial test cohorts, like 94% of people accepted going from free to paid, which is kind of crazy to think about. When you're paying nothing to paying something, we were able to still retain 94% of customers. We weren't getting a lot of pushback. So that gave us the confidence to start again, still slowly incrementally roll this thing out over time.

Migrations are so painful generally and figuring out how to deal with legacy customer cohorts and graduating them into packaging or pricing that sort of makes sense for the the value accretion of the product over what is often many years is so difficult to do. How did you literally do that? Were you going to those customers in small cohorts and saying, hey, we intend to lift prices? We're going to like, how did you think about the comms there? I think that might be something to kind of pull out for listeners because this gets really, really tricky.

Yeah. You know, to be honest, we, we didn't do any like qualitative conversations with customers.

Interesting.

So what it was was just sending email communications. You know, I worked closely with our product marketing team to craft, you know, an email to go out to these customers. Of course, the email highlighted the huge value that they were getting from Radar. And it was a ton of value in terms of the percentage of fraudulent transactions that were being reversed and the ROI. Even with paying for it. So, you know, the, the comms were really just that email and making sure that customers clearly understood the value proposition they were getting. We made clear that they, you know, they'd been paying nothing for a long time and, and, you know, that was, they'd really benefited from that. And so being able to, to outline the value proposition, you know, like that is huge. I mean, if you, if you can't If you can't tell somebody how much more value the product has had since that last price increase, you shouldn't try to even raise prices. Like you have to lead with value. You can't lead with anything else. And so that's just, I think, you know, a critical part of the comms.

Super interesting. And maybe one other question there is, as you reflect on that migration work, At the time, did you feel like Stripe could have lifted pricing for Radar earlier? And if so, would that have been material revenue that was left on the table or would it have been immaterial given the company's growth trajectory?

It's, it would not have been immaterial.

So Stripe, so effectively Stripe was in the good position where it kind of didn't matter to leave immaterial revenue on the table, but they left immaterial revenue on the table.

Yeah, yeah, absolutely. And I mean, even, even when I got there, if you looked at the value, I mean, you could pretty precisely estimate the value of Radar based on the number of chargebacks that a customer was being shielded from, an average value of the transaction. So you can pretty well quantify the value of a product like that. And and Stripe was still giving away. So when you look at the price paid versus the value provided, Stripe was only capturing 5 to 10% of the value of the product. And so, you know, it was a product that was undermonetized. And so, yeah, we were able to really drive some meaningful incremental revenue. And when you have a company that's growing like Stripe, like that change, like when you talk about like a 5-year timeframe for incremental margin, incremental revenue, like that's huge. That adds up a lot really quickly when you can, you know, start in year 1 and show what it's going to look like over a 5-year period.

Well, especially in the context of like all of the engineering investment in that product over those 5 years too.

Yeah. Yeah.

Yeah. Definitely huge R&D costs. It's true. Super. Okay, so take us into Docker. So 2 years ago you joined Docker. Maybe, maybe can you kind of start by telling us just Docker's size, scale, what the company does, and why they wanted to bring you in to build this practice?

Yeah, so Docker, for people who don't know, Docker revolutionized software development about a little over 10 years ago, excuse me, with containerization technology. And so You know, the technology is fundamentally open source, but Docker has two, two products that add value to the open source components to make it much more easy to write, to use. So there's Docker Desktop, which is a locally installed GUI that allows you to run Docker containers in a much more seamless and user-friendly way than just going and kind of doing it on your own. With the open source components. So there's that, there's Docker Desktop, and there's Docker Hub. Docker Hub is where you can find the container images to use in your software development. You can pull them down locally and then use Docker Desktop to kind of build them, run them, and so forth. And so those two products kind of work together. What's really unique and interesting about, about Docker is that Docker Desktop can be downloaded from our website. By, from anybody without even having to provide an email address. And so as you can imagine, that provides some serious challenges to monetization. The way that Docker kind of has overcome that is through licensing terms. So if you're a commercial organization, you know, we trust you to pay for a license. And so with this sort of buy to comply compliance-led motion, Docker scaled revenue from zero to well over $100 million in a very short time span, like 2 to 3 years, because the product is so widely adopted. I think almost 4 million software developers use Docker Desktop every month and something like 30 million IP addresses ping Docker Hub to pull content every month. So it's, you know, it's a massive audience and yeah, so that's kind of initially how we've done pricing. The Docker Desktop and Docker Hub are bundled together into the Docker subscription. And so that's kind of the way the structure at this stage. It's a good, better, best, you know, you're going to get parts of Desktop and Hub in each product tier, the value of which increases, you know, as you go up, of course. And it's a per-seat pricing model. So $24 per seat for the highest tier of the business plan.

2 years ago, they bring you in. What was the mandate and mission and charter as you saw it and as they saw it?

Yeah, that's interesting. I think sometimes people, you know, monetization was such a buzzword for a while that, you know, you've got VCs saying you got to hire a monetization guy, a pricing guy. You got to do this, got to do that. And, you know, as we were kind of talking to you before, pricing is often, it's kind of like an afterthought in a way in the eyes of executives. And so like when I was brought into Docker, like pricing was actually a very small part of my mandate at Docker. And so I had to convince them that if we really want to move this needle and grow ARR and do some things with pricing, like this has has to be my full-time job. I have to make this my full-time job. And so, so that was something that as a conversation I had to have. And so, yeah, to answer your question, like my mandate was part pricing, part other stuff, but I had to evolve it into full-time focus on pricing. Let's get here. Let's, let's build a proper pricing function. We got to have a pricing committee. We got to have, you know, different stakeholder groups. Like the pricing committee is more of an executive stakeholder group. The implementation, the implementation stakeholders group is focused on implementing the pricing changes and then just going through product by product and delivering recommendations and going through and implementing them. So, so that was like the initial things that I had to do at Docker. The first 6 months was really focused on that core product, looking at it, making recommendations, implementing those. The next iteration of Docker's growth is going to come from multi-product. So Docker has this great product that's used by millions of people today. You know, the next, the next $100 million or $200 million in ARR is going to come from attaching other great revolutionary groundbreaking technologies and software to Docker Desktop, to Docker Hub. And so very quickly, like my job has become developing pricing models for brand new products, which is fascinating, which is a really cool thing. It's very, very fun to do. So I mean, Docker's launched 2 new products in the last 2 years. So that was a large part of my— sorry, in the last 10 months. So that's been a large part of my job. You know, there's going to be 2 new products in the next 10 months. So, but then also like the other pillar here, it's been a lot of my focus this year is making sure that when we're releasing new products and the new products pricing, we aren't putting ourselves into a situation that's going to be really messy and hard to untangle. And so I've had to take a step back and think about, okay, like, what's— how are, how are people going to consume Docker and purchase Docker? And how can we package Docker in a way that makes it very easy for sales to sell and for people to adopt? And so, and less of a kind of a one-off, you know, purchase for each individual product. So that's been a huge part of my focus this year.

Maybe to put it slightly differently, but back to what we were talking about at the beginning, like it sounds like implementation is becoming a huge part of your practice and your job. Definitely. Yeah. Yeah. So, okay. I want to kind of piece together or kind of piece apart a couple of things, but the first thing is it's super, super interesting. Like you came to Docker and it sounds like there's in some ways like a little bit of a broad sort of ambiguous mandate from Docker's executive team, which is we need a growth guy or we need a monetization guy, we need a price guy. They're all kind of inflated, right? And you get into the business and you're like, all right, if you want to be serious about pricing, like pricing has to be taken seriously. It has to be a discipline that requires full-time focus.

Yeah.

Is that a good playback of sort of what happened in the first 6 months?

Yeah, absolutely. You know, they want to bring in a monetization guy. I'm sure one of their VC, you know, investors like, you need a monetization guy, go hire one. They went and hired me. And Yeah. And I don't think it's uncommon for pricing experts to really have to chart their own path and define, you know, what that role is going to look like in an organization because it is a bit of a unique role that not very many people are exposed to or companies are exposed to and know, you know, how it should work or how it needs to work.

Yeah. And just a quick little interlude on like, what does a pricing person need to be good at? And do you think that it's— is it too reductionist to say a pricing person needs to be good at obviously like data analysis so that you're assessing things like, you know, recency of usage, frequency of usage, monetary value, but you're also good at communicating with customers. You're also good at influencing across an organization. Like it's a pretty multidisciplinary skill set. How would you sort of add to the characteristics of somebody who's good at leading pricing within an organization, especially when it's going really quickly?

Pricing is multidisciplinary. And that's one of the things I love most about it. It's hardcore data analysis, analyzing transactional data, customer data, survey data. But at the same time, there's a very strategic qualitative component to it. So you've got to understand data analysis. You've got to know how to crunch numbers. You've got to know how to put those numbers in context. You've got to know how to come up with a recommendation that's going to make sense. You have to be able to effectively communicate that recommendation. And then, you know, if you get acceptance or buy-in, you have to be able to galvanize a group of implementation individuals to work towards a common goal of implementing the pricing. And, you know, being able to rally that group, remove hurdles from that group, because, you know, as a pricing guy, like, I'm not actually doing the work in that phase. All my work is done up to the recommendation phase. So my job quickly becomes, let's let's galvanize people, let's remove hurdles from their work so they can— so this is as easy as possible for them to do. And so, yeah, the skill set runs the full gamut.

It's a really amazing skill set. And two questions. One is, who do you report to at Docker? Who did you report to at Stripe? What have you learned about where pricing should live?

Yeah. So at Stripe, we reported up through finance. Um, and at Docker I report up through the product, the CPO, product management. And I definitely wholeheartedly believe that pricing belongs in product. Um, that's, you know, that's something that I look for. Uh, I make— yeah, I think that that is definitely where pricing belongs, even because I like pricing leaders should treat pricing as a product. The same way that product managers treat their products as a product. And that means doing everything, you know, following a lot of the same routines and procedures that they do, having a Jira board, having a roadmap, you know, taking part in these different company routines like monthly business reviews, quarterly business reviews, product priority reviews. That way you're getting visibility into your function, like what you're doing, Because that's a great way to get buy-in. People can see the work that you're doing and like what you're doing, what you're not able to do. That really helps people understand, okay, how can I, what can I do to help enable David to do these things he can't get to right now? They're kind of on his backlog. So yeah, so treating pricing like product, following those same product management routines, I think is really important and something that should be like standard practice., you know, at companies, software companies.

So I think that that's an A, it's a take that I think I lean towards and agree with. It's also a really interesting take because I think you could debate it in a variety of different ways. What do you think is the best argument for why pricing should roll to finance?

Well, the best argument for finance, you know, like with pricing, you're obviously going to be impacting financial projections. So the work that you do in pricing is going to have a material impact on, you know, the company's finances. And finance is where, you know, that lives. So, you know, when you're working with finance, you're able to provide the company with much more accurate financial forecasts, you know, which is a great, a good thing. But you do lose that, the product, you know, kind of the product component to it. So, you know, finance is a little bit further down on the list of where I would put pricing. I think PMM is an interesting, is an interesting place for pricing that can work, that can work as well. But, but really, you know, I would encourage, I would encourage all software companies to treat pricing like a product management function.

To what extent do you think the average B2B SaaS company that has raised venture capital is doing a good job of aligning their product roadmap with pricing roadmap?

Wow.

Um, asking you to speculate a little bit here.

Not very well. You know, it's especially in the early stages because like I was saying, like these founders and early operators are putting a price tag on something and then kind of forgetting about pricing. And so the roadmap is evolving and everyone's very focused on the product roadmap, which is great. But, um, the pricing roadmap is not is not being sort of brought along at the same pace. And so what'll happen is, you know, a couple of years later, we'll realize we need new pricing because X, Y, and Z has changed with the product. Well, we knew about— we've known about that because it's been on the roadmap for a while. And so, you know, part of my job and pricing leaders' role should be to think about, to see, anticipate these things that are coming down the roadmap and understanding the impact on pricing and where they need to go within the within the product packaging, how it fits into the pricing model and all these things. You know, it's definitely something that is probably very overlooked in the vast majority of venture-funded software companies.

You know, as I sort of think about, I've thought about where I would recommend pricing live as well. And I think I've also landed for the most part, product is ideal because I think you've said it, but I'll just kind of restate. Most companies don't seem like they are aligning their pricing roadmaps with their product roadmaps. And what that has always— the reason that's always, I think, been somewhat confusing and baffling to me is because the implication is I'm going to go spend millions of dollars on releasing new product, but I'm not actually going to monetize that new product in an intentional way. And that is sort of a baffling trade to make.

Yep. And if you're building a business case for a product or a feature or something, and you're not thinking about the pricing model that that product's going to have, you might come to see that you need a new pricing model. What you thought was going to work is not going to work. And now, like, your business case has completely changed. Hopefully, you know, you still have a favorable revenue expectation for the products, but maybe not. If you're not thinking about that pricing from the very beginning, there's a good chance that when, when things go to market, you know, you're not going to realize that ARR because, because you, you, you, your, your, um, assumptions were wrong from, from the get-go.

Yeah, yeah. Um, somebody said, you know, the only thing that you know to be true is that pricing and packaging will change.

Yeah.

Um, so going back to— so really interesting context about when you joined Docker, what the mandate was, what it became. You mentioned that a big part of the last year has been how are we going to price and package as the company evolves into a multi-product offering. And so to step back, tell me if I heard you correctly. It sounds like today or historically, the offering, the pricing, the packaging has largely been kind of like there's this, effectively, there's this free tier for personal and learning use. There's sort of a developer tier for individual developers. There is a tier for teams, and then there's sort of custom pricing for businesses. Did I capture that correctly?

Yeah, the business tier is also product-led, so it's not really customized. You can go and self-serve that business plan. But yeah, that's exactly how it works.

And so, kind of the price metric is basically seats or developers. Is that right? Right. Yeah. And so, as you launch new products, I'm curious if you can kind of just paint a picture for us on what that might mean. Does that mean a change to the pricing metric potentially? So now you have new multiple pricing metrics that you have to figure out how to price and package, or does the price metric remain developers and you'll think about pricing and packaging sort of mostly through kind of the lens of bundling or unbundling or things like that?

Yeah, to the extent it's possible, we're going to try to stick with per seat and have that be the primary focus metric for, for, for the Docker suite or Dockers and additional products. That's not going to work in all cases. And so what we'll have to do in that case is think about what's a good consumption layer to include per seat. So if you're a developer and you need a certain amount, you need build minutes, you need to build, you know, build these containers, right? We can't give away all these build minutes for free. That's costly for us. And so, you know, we need a consumption layer to sit on top of or be in addition to the per-seat component. And so really, that's what we're lying around is seat plus consumption. And, you know, and with consumption, you can do a lot of cool things like sort of create your own token or currency so that you're not having people buy all sorts of different metrics and measures for that consumption layer. There's ways to really abstract that complexity away and make it sort of its own its own currency, its own system.

So super interesting and feel like it's very much on trend, which is companies moving towards hybrid billing where it's a seat-based model plus some consumption-based model. That obviously adds a lot of operational complexity. Maybe can you speak a little bit to like how you have personally thought about the operational complexity that that will create for the business and just sort of a framework for these are the 3 things or 4 things or whatever that I think we're going to have to figure out how to solve for.

Yeah, you know, to be honest, I'm kind of learning about these operational complexities of hybrid billing, but it's definitely true that having this quote unquote double trigger pricing does create a lot more, many more operational and logistical challenges in billing infrastructure and everything else. To implement. And so that has to be considered. You know, the effort required to put in and maintain that kind of system has to be considered as part of this launch. But, you know, my personal philosophy is, you know, implementation complexity should be a part of the decision-making process, but it by no means can or should lead the decision-making process to have a pricing model. You know, I think that can get companies into problems sometimes because as I know you're aware and I'm now aware too, the implementation of pricing models is very challenging, especially these hybrid billing models. And so having a billing infrastructure that is flexible, that isn't so hard-coded, that can make changes very quickly. That can adapt is crucial for any company that really wants to experiment with pricing or to really make sure that they've got the best pricing model for their business.

One of the things that I've been sort of on a listening tour asking as many people as possible, what is hard about supporting this hybrid billing model? And I'll just try to relay some of what I've heard and see kind of what stands out to you based on what you've learned so far from Docker. I think I often hear from CROs, you know, the real issue here is like forecasting, like, how am I going to forecast usage-based on top of, you know, what have traditionally been like booked contracted revenue? What I often hear from, you know, folks in FP&A, finance, RevOps is, you know, how are we going to calculate the usage-based invoice in a way that we can trust and how are we going to set up the right sort of safeguards and systems so that, you know, if somebody gets like, if somebody spikes, we know that we know why that spike occurred. We can kind of quickly reconcile or validate that it was like real increase in revenue versus maybe like something with an API connector changed and we have to like reimburse the customer, like really sensitive customer stuff. And then on the product engineering side, I feel like what I often hear is like, you know, this touches the code. So like, how are we actually enforcing limits in our application? Things like that. I think that's sort of largely what I've heard so far. What— anything you'd add to that or anything that stands out to you based on what you've so far learned at Docker?

Yeah, that definitely resonates. I'm less keyed into like how, you know, how the code and all that works. I think that's one of the biggest hurdles. Honestly, predictability, as you mentioned initially, is a concern, especially for customers with consumption-based billing and for companies that have it. You know, I think one interesting thing that we're thinking about doing with Docker is have an unlimited use plan. So if you want to have this, if you don't want to have these different consumption layers, you know, built in or in addition to the C price, We'll give you a, we'll give you a C price if you want that. If you want the benefit of predictability, you know, there's a price for that. And we're, I think, you know, we need to be flexible to, to give that or offer that.

That's super interesting because, yeah, I was, I was kind of headed down like it's hard for the business to forecast, but actually customers want predictability in their bill too. So, you know, they might be willing to pay for that. Yeah, totally.

Yeah.

Super interesting. Okay, so maybe kind of going Looking back over the last 2 years, you really established a charter for pricing. You're kind of supporting the business's evolution into multi-product. Maybe can you take us into the nitty-gritty on how you've actually done this work? Have you built pricing committees? How does the sausage get made? How have you helped it get made at Docker? Get a picture of that.

So a pricing committee was one of the first things that I put into place once I kind of focused my work just on pricing. That was one of the very first things I did. Over time, what I learned was so many people wanted to be involved in or just know about what was going on. So initially, the pricing committee started off as just basically an executive level, C-level committee to approve pricing strategy. And so What I quickly learned was that, you know, our implementation partners, you know, they wanted more of a say. They wanted to have a seat at the table.

And maybe, who are the implementation partners?

Okay, so implementation stakeholders would be billing engineering, billing product managers. There's a RevOps, so someone who's in charge of CRM, CPQ. Sometimes there are different roles. FP&A, marketing, or PMM, legal. I'm trying to think.

You got like nearly 8 people who care a lot.

Yeah. Yeah. Um, who, who care a lot. And so my first attempt was to just put them in the pricing committee meeting and that, that didn't really work very well.

Uh, why not? Why not?

You know, um, there's, there's the, the 2 different stakeholder groups have 2 different objectives, right? They're, they're trying to solve for different things. So the executives are trying to solve for ARR, right? How are we going to maximize profitability, growth? Engineers are trying to optimize for complexity of build or complexity of installation. And so there was just kind of a tug of war between these groups when it came to the pricing committee. And so I ultimately split it into two different groups. So we still have the pricing committee and we still have— and we created a pricing working group for these implementation stakeholders. And so before I take any pricing recommendation to the pricing committee, they see it first. They see it first, they comment on it, and those comments are kept into the proposal that then goes to the executive team. And so in that way, you know, their voice is still being heard, especially when it, you know, when the decisions are being made, but they're kind of being made in isolation of one another.

So basically you've kind of shifted it towards before we get into anything I'm going to recommend to like an executive level group, I understand feasibility. And the trade-offs around some of these recommendations from a technical implementation operational perspective.

Yes. So, there's a— yes, we have a system, a green, yellow, red, you know, to kind of assess the implementation feasibility. So, obviously, if something is a red, that means, you know, I cannot— my state, my implementation stakeholder cannot do this without additional resources or systems or something. And so, You know, in that way we're kind of able to surface that information and find what those red flags are before this strategy is approved.

I assume, but tell me if I'm wrong, that that shift was really important to your ability to galvanize and build trust.

Definitely, definitely. You know, showing up to an implementation stakeholder meeting with a recommendation and, you know, giving it to people for the first time, like my first time doing that did not go well at all. Did not go well. Yeah.

I've been in that meeting before.

I've seen that. I was playing defense for like 45 minutes to an hour, you know, trying to like backtrack things or walk things back. Okay. Well, we don't have to do this. Yeah. So, um, yeah, so that was, that didn't go well. And that was, you know, a big part of the reason why we've kind of transitioned into this dual approach.

Well, just to lament for a second, I mean, like I've been in that meeting before, but it's sort of like, it's a problem to me that like, well, I guess the way I think about it is like, think about all the go-to-market pricing conversations that just can't be had because of how complex it is to go implement the recognitions. Like the creativity killed on the go-to-market and pricing side is to me immeasurable. And Immense.

Yeah, yeah, yeah. And my look, I mean, my— I have a creative brain when it comes to these things. So I love like, I love like coming up with like, you know, innovative or nuanced or non-traditional or just different approaches to things. And yeah, that can definitely get me in trouble when it comes to like, you know, the reality, the reality of things.

This has been a fantastic conversation. I'm really grateful to you for doing it. I've got 2 more questions. The first is Zooming out and looking forward into the future over the next 5 or so years, are there trends or inflections or things in the world of B2B software that have attracted a lot of your energy and your curiosity, you think about a lot?

Yeah, I mean, I think this won't be a surprise, but AI I think is a really interesting thing to think about. Not just from a product perspective, but also from a pricing perspective. Like you've got 3, you can kind of categorize AI software products into 3, 3 different areas. So one are these, these sort of human-assisted copilots or assistants. The second are essentially bots, which are completely replacing a human. Need no human sort of interaction. And the third are these API-based embedded services like ChatGPT APIs and so on and so forth. And like the pricing models today for these three are on the one— on the, on the assistant side, per seat. I think that makes a lot of sense, you know, to have a per-seat model for these tools that extend a developer's ability to be more productive. I mean, productivity tools are historically per seat. So I think that's, that's interesting and probably okay for now. What I really take issue with is how these embedded API services are being priced today, because if you're aware— so basically what happens, like, for you to use ChatGPT as an example, um, it's a token-based system which is determined based on the amount of input, like the prompt that you're putting into the, the system, and then also the output, like the number of words that come out to it. And the tokens are loosely based around the number of words that are required to input and then output in the system. And when you have a pricing model like that, like, the customer is really not in control over over it. They can somewhat control the input and how and, you know, make their, you know, minimize the, you know, the input into the system. But the customer has no control over the output and how long the output is or how complex or how long it's going to take for the, you know, for the output to, to come out. And so that's, I mean, that's, that's always a problem. A problem like whenever I'm developing pricing models for new products, like the customer has to be in control. And so I'm interested to see where that goes, how these AI embedded services make the pricing more customer friendly. Like right now it's like no one's questioning it because it's, it's, it's new, it's great, but someone's going to come along and figure out a smarter way to price this in a way that customers can control and is more aligned to the value they're getting and not just the volume of the output.

Uh, that's super fascinating. You know, to— is the reason you take issue with it because the lack of control means ultimately more cost than I could potentially foresee, predict? And so I'm not controlling maybe cost of goods sold all that effectively, or is that a bad way to interpret sort of like why you would take—

actually, yeah, you're not in control of your spend.

Um, so Yeah, that's, that's, that's seemed like one of like the major second order effects of AI from a pricing perspective is like software companies are far less profitable, right?

Yeah. It's, it's, I mean, but I understand the situation, like AI is expensive to run AI, to run these large language models is tremendously expensive. And so you like, you have to have some sort of cost component baked into it. I'll use a great, so a great example, I think of someone who's doing it really well is Intercom. So Intercom, as people know, they're kind of like a service desk, but they've got now an AI embedded feature, which is just say a bot. So the bot's replaced a human. You're interacting just with a bot for the customer service request. So they're not charging customers on inputs and outputs and all of that. It's just per resolution. So every time the bot resolves a customer question, that's what counts and that's what matters.

Ah, yeah, yeah. So it really is getting to like you're realizing performance-based pricing in that world, right? Yeah, exactly. Super interesting. David, one of the questions I always like to end with is what was the professional experience that was most formative for you? And if you could drill down to like a very specific moment that was most formative.

So hard to— it's so hard to find one.

Maybe it's this podcast given you're about to go. Yeah, you're about to go have a baby. So people don't know that. That you're right.

This, yeah, this podcast, the baby that is following is going to be hugely, hugely formative. We can use that. No, I think like just maybe this isn't going to be as specific, but I've always learned through failure and like that's always been the number one learning moment for me. And so there's been no shortages of those. So, so really to, to be able to identify and admit when something went wrong or didn't go as didn't go as well as you wanted it to be, you've really been able to diagnose that and understand what happened and learn how you can do it better the next time. So yeah, so I guess my— it's more of an incremental approach to learning. I can't really— I wish I could give you some great story, but I don't have one. But there's been a lot of little things that have kind of just added up over the years and just being able to learn from those, I think, has been really valuable.

Yeah, resonates a lot. Where can people learn more about Docker and reach out to you if they've got questions about pricing and packaging?

Sure, LinkedIn. David Kaufman on LinkedIn. That's a great place to reach out to me. I've got a website for my consultancy, which is axiaconsulting.co, A-X-I-A consulting.co. So you can go there and learn more about my, you know, my consulting practice there. But yeah, that's really it.

David, thank you so much for doing this. It's been a pleasure.

Yeah, you bet. Thanks, Fynn.