Usage-Based SaaS Pricing Strategies That Work | Ft. Joe Ryan from Launch Darkly (EP# 34)

Joe, thank you so much for being on our podcast. I've gotten to know you over the last year and you've just had this incredible first row seat to the building of LaunchDarkly, which is obviously one of the most impressive SaaS companies of the last decade. You've worked there for almost 8 years. You've worn a bunch of hats. You've been an account executive, a sales engineer, a sales manager, a revenue leader, a chief of staff, a VP of product and revenue strategy. Prior to that, you worked for Intercom for nearly 3 years, again with a bent towards both go-to-market and product. Tell us how this all happened. What's your career journey in your own words?

Yeah, it's been an interesting journey that I would say has been entirely driven by one word, which is curiosity. The draw for me into software was a curious one. I actually started before Intercom at a tiny little startup, 9 people. I think it was like $300,000 of ARR, and I got brought in to basically figure out how to go to market. It was like a business development manager role. They're like, yeah, we don't know what kind of companies we gotta sell to, so can you figure that out? So I built out an ICP. I didn't even know what an ICP was at that time. Then I was like, wait, how do we actually get into these companies? So I started doing email campaigns, cold calling, and randomly closed the biggest deal ever for the company. This company called me back. It's like, yeah, we have $350,000 we wanna spend with you. I was like, that's a lot of money.

Are you sure?

And So I ended up in sales like that. That's literally how I started in sales. From that point, I got the chance to go to Intercom. It was such a hot startup at the time. And the thing that I always remember about Intercom is they always talked about the things that they did, the challenges they solved, and what they learned from it. And so that kind of set my mind of like, ooh, I wonder what all these interesting companies are doing. What are the challenges they're solving? And that just led me to be so curious about product. I got to go over to Dublin to work at the product team at Intercom, which I do believe is truly first class. The work they do is exceptional. And then was introduced to LaunchDarkly where I came in to be one of the first salespeople. I led a team for 2 years and then got a chance to be chief of staff where we worked on everything under the sun in revenue, scaling up teams, professional services, success, CSEs, building out a media revenue. And along that journey, one of the things I did was run all the go-to-market planning for the exec team and Fynn, every conversation for about a year and a half came down to pricing and packaging. It was this burning problem we had and it was like our growth is restricted, our adoption motion is restricted, our activation is restricted, it's all because of seats. And we started to try to solve that problem. And ultimately the, I was tapped to take it on because I understood the business, I understood the customer and the value the customer derived from the LaunchDarkly product, and everyone knew who I was. So they kind of need someone in that role who can do a whole bunch of things really awkwardly, break everything, and trust that they're going to do the right things for the business. So I kind of followed these challenges across Intercom and LaunchDarkly, uh, just out of curiosity, and that, that has led me to where I am today, which is really focused on bringing LaunchDarkly's new products to market.

It's a fantastic story. So one thing that stands out to me, right, is the uniqueness of sales, sales engineering, product leadership. And there are a lot of people that are really good at running a deal process. There are a lot of people that are really good at getting on a demo and delivering an excellent technical demo. I don't think that there are a lot of people that are really great at both and then further good at like actually starting to lead a product org. And so tell us a little bit about actually how you became good at these things, literally how you became good beyond a natural curiosity, which is obvious.

I would answer this question first by making the statement that this is what a product manager does. Product manager is a salesperson. We have this thing at LaunchDarkly called PM is GM. A product manager is responsible for the product success, end-to-end everything. You got to go support the product, you do it. You need to go sell it, you need to demo it, everything end-to-end. It's a GM mindset. Mentality. And one of the things that I care deeply about as a salesperson, the actual product, the product craft, the reasoning behind why something was done the way it was done, because that's the way I sold. I was never a negotiator. I was not a good salesperson. I just really cared about how software solved customers' problems. And then I ended up just started demoing it myself and I was like, ooh, I can do that. So I learned how to talk about product and the decisions in the product itself. And then that's kind of where I got pulled into product. So I've been in revenue for the most part for the last 2 years. I moved into the product organization and started to think more about the monetization of these products and the pricing of these products. So it's like there's been a battle in my own career of should I just be a product manager at some point? Should I not? I'm not going to be, I don't think yet, but that's always been a thing driven by curiosity and just really Caring deeply about customer problems.

It's a really tangible answer. And, and, and some of the, some of the best sellers and product people I know, you often watch them say they'll demo like a certain piece of functionality in a product and they'll say, yeah, let me explain the reason why we designed it this way.

Exactly.

And it, it's just so compelling to the person being sold to because it really demonstrates a choice was made. And that choice can be, you know, something that they may not kind of find utility in, but at least they understand the choice.

Yeah, exactly. Storytelling around the product. Yeah, I think that was the most exciting thing for me about selling software is like I get to work with product teams solving really cool problems and I get to talk about that. That was always really exciting. Could I go sell like AWS? Not a chance. Not a chance. It's just a different like relationship building and commodity selling. And I am like, I want to solve cool new problems and talk about that. Is there—

we're going to talk all about monetization, but is there one moment that stands out to you over the last 8 years at LaunchDarkly about sort of for what it taught you about building a good company? Like one specific moment? I mean, I'm sure there are many stories, but is there one moment that really resonates, really rings out?

You know, LaunchDarkly's gone through a lot of transition in the last couple years, and I think one of the things that mattered the most in that transition and change is having customers on speed dial, something that we call it. Our CEO, Dan Rogers, talks about this all the time. So does Claire, Bo, our CPO, my boss. And no matter what happens in an organization, there's going to be change, there's going to be strife. If you lose sight of the customer, you don't really have a business. And I think that's something that these moments that happen over time is when there is a hard problem, the customers tend to have the answers and the culture around the customer, I think, matters so much to be, you a cool product, a cool company, versus something that can be generational. And that is something that we've really anchored ourselves to. So it's not necessarily this moment, but are these little moments over time that we've been able to call these customers who absolutely love the LaunchDarkly product. They appreciate it because it has solved so many problems for them. And to be able to call them and ask them for advice on a hard thing is, uh, The thing that I always think about with LaunchDarkly.

Customers on speed dial is such a competitive advantage. And a lot of companies don't actually talk about culture of the customer. They talk about internal culture. Right. That's so interesting. Exactly. So you're launching new products today. Tell us more about like, what does your day-to-day look like? Where are you really focused?

Yeah, we are as a company trying to become the platform. For all of release management. And if you think about what LaunchDarkly is, we are a control point in your code. You can do so much with that once you deploy that feature flag in production. You can decouple deployments or releases, you can mitigate all of your risk, you can keep your application as stable as possible, you can find incidents before they actually cause impact to users, you can run experiments, you can have analytics. Like, there's just so much to do. And so what we're focused on is building a lot of these new products and then taking them to market. And taking them to market, there's key steps we have to think about. One is, is it— is the product commercially viable? So can we sell it? In what form should we sell it? Should it be an add-on? Should it be part of a package? Should it be its own product? And then can we teach the sales team to sell it? And this is a step that's often missed in go-to-market, especially with new products. There's a really good article from Harvard Business Review about the sales learning curve. You can have the best product in the world, but if the sales team doesn't buy into selling it, it will fall flat. And so we have to make sure that we can teach the sales team how to sell it, the playbooks, give them the objections, get them excited about why this is really important. So a lot of my focus right now is our product experimentation, um, which has been a, uh, a really great product for us, and we are doubling down on all things within experimentation. And then we have 3 new products that are coming out in the next 18 months as well.

We're working on one of the things that you're kind of obviously describing is the alignment between product roadmap and pricing roadmap.

Yeah.

What have you learned about aligning those 2 roadmaps?

I'll give you, I'll give you my funny answer first, which I actually think is really kind of telling. You can set your price and then build your roadmap into that price. And so what I mean by that is you can literally say, this is the type of customer that we want to sell to, this is the price point we want to sell at. Okay, then what are the things, the bits of functionality that would make up the value that you would declare with that customer? And so that has been a really interesting way for us to think about pricing products. Hey, you want to get a sales team excited about selling something? It's not $10K, it's got to be $150K, it's got to be $500K, it's got to be $1 million. Okay, so what are the bits that would make up that value proposition to a customer? That's how we would price it and that's how we would build that value. And then fundamentally under that hood is you have to be able to teach the sellers how to exchange value the right way. And you have to be able to declare to a C-level person at a customer's, uh, an account that we can deliver that value. So I think those two things are so important and are often missed when you're actually pricing your product. It's like value-based pricing as opposed to cost-based or usage-based or anything like that. That is key.

So where do we want our value to eventually be and how do we train sales reps to actually basically sell value?

Exactly. And you do have to take, uh, competition into account too, like What is the market selling something at? What is the market declaring value at and why are they doing those things? How do you differentiate? How can you establish that if a competitor is $100 and you're at $120, how do we declare the difference? So I think that kind of thinking early on is really important.

I was recently sitting with a customer, we were doing an offsite and I said, we want, we want you to pay, we want to earn $100,000 from you. Every year. Today we're at 20. What would it take for us to get to 100? And it was such an enlightening conversation. And then we actually flipped it. We did kind of an inversion mechanism and we said, why do we fail? Why do you churn from us in 12 months? And it's so fascinating.

Fynn Glover, those are like the best conversations I have with customers. If you can build that relationship and trust and ask that question, there is a really good relationship and That customer wants you to deliver that value and they want to pay for that value. Like, no, in no world in software, in any pricing, like, is everyone going to be happy about pricing. But the customers that truly, truly get that value out of it are always going to be willing to pay for it. I like to frame a similar question too, is like, is this small value, medium value, large value? And then I'll put a number and assign a number to each of those. Like, guide me to what you think. And then the customer is kind of telling you the value too, and it's a good input into what you think you can charge for a product.

On that note, say a little bit more if you can on like, what have you learned about literally how to talk to customers about pricing and packaging and value? Because it's, it's not easy to do.

Yeah, I find a lot of value asking customers how they would pitch this to their CFO. And in today's world and economy, that is the thing that's happening behind the scenes. And asking them, how would you do this? What would your approach be? Their answer will tell you a lot. Have they thought about it? How would they approach this? Have they done this before? Are they thinking about it the way you're thinking about it? And that'll give you a lot of tell. And then you'll get information from the customers who have built those business cases naturally, because they may have solved this problem already and want to solve it with your software. So that's also very interesting. But also just asking them, what do you think it's worth? You know, would you pay this? But you got to give them you have to lead them into that discussion instead of saying, what would you pay? It's too open-ended. You kind of need to lead them into a couple answers to see what they would say.

Yeah. Let's dig into everything monetization and maybe a good jumping off point here is you've been at LaunchDarkly from nearly the beginning. I mean, the company's been around for about 10 years, right? It, it, it creates the category, the feature management category, the feature flagging category. You join a couple years later. And what feels true, tell me if this is wrong, is the business goes on this journey of a relatively simple product towards a multi-product offering where the go-to-market evolves. There are kind of multiple go-to-market motions. The product evolves. There are multiple products. I'm not sure, but maybe you can kind of tell, are we also kind of moving into a world where there are multiple billing models or billable metrics? All of that to say, there's a lot of complexity that falls on product engineering in particular to support that evolution. Talk about what you've learned about supporting that evolution and tell us as much as you can about like literally how it happened.

Yeah. I think it's been an interesting journey for LaunchDarkly with monetization because we started with monthly active users. That was the pricing when I started. It was, it was pretty simple. But the challenge we found was that we had large B2B organizations with small numbers of users getting so much value. So we were like, hey, how do we realign value? Oh, well, seats is this like very common enterprise pricing model, easy to understand, simple to sell. So we shifted everything to seats and it worked so well initially because we could land really quick. We were landing bigger deals, but within about 2 years, that's when we noticed that we were not expanding. So we monetized client-side applications, and so that helped a little bit. Then we brought experimentation to market, we started to monetize that. We have a data product, we started to monetize that. So each of those had its own meter. So right in a year, we had like 4 things, 4 meters we were charging by, core being seats. Then we introduced like a platform fee, right? There was that whole thing happening in the 2010s. Then there was this moment where like, hey, seats might not be the thing. And as we started to do our research and talk to customers, we recognized that customers weren't deriving value via seats. They didn't think about via seats. They thought about it via risk. So we had to go figure out another meter. And as we were thinking about how are we going to shift our business to this new meter, I realized that we have to rebuild our entire billing infrastructure. And I was like, wow, this is going to be hard, like really, really hard. And it became this whole project. We did it in 6 months, most of it. And we had to make sure that the whole system was structured in a way that a customer could purchase products separately, individually, and/or as one, and that we had the ability to add new products and monetize them in any way for the future. So there's some key decisions we had to make early on. To allow that system to be adaptable and flexible enough for the future state that we kind of plan for.

Can you speak to some of those components, or I mean, are these like internal services, like a metering service, product catalog service? Like, help us understand the architecture that you built this against.

So there is a— I'll name a couple tools that we used and, uh, integrated all together, but then we also have a homegrown solution that a, a guy, Nate Graff, built everything. He's truly exceptional. Could not have done this without him. Like, his mind is all this detailed map of all these systems interacting. He's like, you kind of need that person. So let me just call out the human side of it. You're laughing, Fynn, because you know, because you've done it. We have Stripe, so we use Stripe for all of our self-serve billing and credit card billing. We have NetSuite, it's all our invoicing, enterprise, like everything's got to be in NetSuite. We have Salesforce, which tells NetSuite what to charge. Then we have LaunchDarkly, that's actually serving the feature to the customer. And then we have this homegrown system that kind of wraps that all together. And then all our metering is done in a product called Amberflow. Perfect.

So we've got like basically tools across, across 3 stacks. We've got tools in the sales stack, we've got tools in the finance stack, and we've got tools in the product stack. And then we've got a bunch of effectively like homegrown glue in between it all.

You got it, you got it.

Keep going.

So the, the hard part about that too is that it wasn't like one person and one team owned that whole stack. So we had to have a very clear owner from each org— finance, revenue, which ended up being DealDesk and RevOps— and then, uh, this guy Nate, who was internal tools and systems, and myself leading like the whole end-to-end program. But And we had to make it all go together and make it all talk together, which was very hard. And the, one of the things that I knew going into this was that the trust of our data as it came to what we were actually going to bill a customer, especially for anything truly usage-based, was going to be critical. If we got that wrong and we charged someone's credit card for the wrong amount, that is going to burn our credibility. So we needed to have 110% confidence in our data. So we hammered that in the initial 6 months. So we had a lot of effort and engineering time put into ensuring the collection of that data was really sound. Data going into Amberflow is really sound. Data going into our internal analytics like Looker was perfect, and that matched the data that we were sending the customer in their usage dashboard. And that was all wrapped together via Stripe and NetSuite because we would ultimately invoice customers based on a specific amount used on usage-based. Enterprise is a little easier because we could say like, you're going to buy an allotment of usage. And we kind of abstracted away from true usage. It was more annual commits and then true forwards that we worked on.

Yeah. Say a little bit more. Are you, are you saying that kind of like the hardest thing to build technically was the metering system because of how reliable it had to be?

Yeah, it was. I would say it was fitting the metering system into all the other systems and The, the Amberflow product was, was pretty good. It did most of everything that we needed to do, but we ended up building a lot of stuff around that that we didn't expect to build because it could only do so much. And we needed to talk to all these other products, all these other systems, and integrate directly into Stripe and do all this fancy stuff that we wanted to do. And so that was Nate's team, and Nate's team figured all that out and built all that in that homegrown solution. So that was the complex part.

So how do, how do things, so one, one sort of object I'm curious about in this architecture is like the product catalog. So like, is the product catalog living in multiple places within the system? Or is there kind of like a designated source of truth for the product catalog and either the quoting tool or the billing system, or maybe even the application stack?

That's a tool I didn't, Salesforce CPQ was a big piece of this too. So this is a little bit of what the homegrown tool does. And the challenge that we have today is that it is like a backend tool that the engineers know. There's no UI, there's no interface that like we have a new pricing PM. They're like, how many SKUs do we have? Who has what SKU? And like, gotta pull it via spreadsheet and hand that to her so she can understand all that stuff. So like, there is not a good way for us to say, this is exactly who has what, these are the SKUs. It's a hodgepodge of like, I go look at Salesforce, I go look in some of our backend systems. So it's still a bit sporadic on how we actually present that back to the business right now. Yeah.

Yeah. And then maybe one other kind of object here that I'm really curious about, because I mean, LaunchDarkly talks a lot about this, like something like 53% of LaunchDarkly's customers use LaunchDarkly for entitlements. But entitlements is this really important concept that sits between kind of the application and what the customer should have access to based, or yeah, based on a contract or based on kind of like a subscription object in the billing system. So can you talk a little bit about entitlements?

Yeah, absolutely. Like the way LaunchDarkly would serve an entitlement is basically I have 3 versions of the feature that might be aligned to a good, better, best. And I actually would use LaunchDarkly to deliver that variation of code or that feature. Through LaunchDarkly's product. What LaunchDarkly does not have with entitlements is first-class objects and a system that wraps all that together to say this set of functionality is assigned to our good package, this set of functionality is, you know, the better package, this set of functionality is best, and have good insight or overviews into those specific things. That's kind of what we built internally a little bit, and I think that's a huge need in the market is to simplify and synthesize all those things together because I can't even tell you like who has what easily at this moment. And you know, we use our own product for all this. So it's, it's a hard challenge to solve for.

At your scale, it's just so complex. I mean, you have thousands of customers with thousands of permutations with multiple stacks governing all this, all these relationships. Not to mention like the human dynamic of all this, which is how do you collaborate across cross-functionally, right? This is like a massive cross-functional communication and collaboration challenge too.

100%. It was fascinating. We also support seats and our whole new model right now. And we had to make a decision to do that. It was an intentional decision with the business. And at some point we want to go public. We want to get all that stuff ready. We knew we wanted to get there, but we also knew that we didn't want to put, uh, customer relationships at risk forcing them over to a new pricing. And we thought that was more valuable, holding the customer contract to what it was instead of forcing a new pricing model on people. Like, let them opt in. And we have had so many customers opt into the new model because it's just better for them, it's more valuable, it's a better exchange of value. And so we'll, we'll ease our whole install base over to that world. And so like, all of that meant that Every single organization, every exec in the company had to be so deeply aligned to every single thing that we were doing. So there's a lot of updates, a lot of decks. I've seen a couple of the pricing folks on LinkedIn talk about this. It was constantly making sure that everyone knew exactly what was happening. We learned this thing, we got to make sure the team knows. We kind of changed our go-to-market motion a little bit too. So we had to retrain the sellers on how to sell the product. Because Fynn, I could say right now, like, how many seats do you have? 550 developers. Cool. That's X dollars, right? We changed it to be what we call service connections, which is really infrastructure. How much infrastructure do you have? So a rep needs to know, like, Kubernetes, is it virtual machines? Are they on bare metal? What are the implications of pricing because of that? So it's a little harder, but we could do bigger, better, deals that way. And so that's what mattered a lot to us. But that was the hardest part, training the go-to-market team in the field.

How did you preserve organizational commitment to this type of change? I mean, because, yeah, maybe also one could argue you were retiring a lot of technical or commercial debt.

Yes.

And it's really hard to prioritize for an extended period of time retiring debt.

Yeah.

How did you actually make this happen?

First, I would shout out the team that was working with me on this one. Like, I have 3 partners, 4 partners really that we all knew that we came together and made that happen. And I don't need to say much on this, but there's a lot of change at LaunchDarkly. We had a new CEO. So every time that new CEO hired a new exec, we had to go train that person on everything that we were doing, making sure they knew exactly what was going on and why we were doing it. So that was really hard, but The thing again I referred to earlier was that customer's on speed dial. I knew from so many conversations that I had personally with customers, I got cussed out a few times, Fynn. People were like, I fucking hate seats. Like that was the conversation over and over again. And I just had this mission to fix this for LaunchDarkly, fix this for the company, but really fix it for the customer. And I could sell that to the organization and people would get behind it pretty quickly because they knew and they saw the deals that we were doing on the new model. They're like, ooh, that's really interesting, I want to do that, and that's a better way for us to do business. So it was just constantly sharing those, uh, those wins with everyone. The other thing was that I actually did get our CFO bought in really early, and I spent a lot of time with our CFO because we needed to know if we made all these shifts, what would the business look like? If we did it this way, what would the business look like? What is our best case, worst case? What do we think is the realistic scenario? So we're like constantly modeling out these scenarios and it was always positive. So our CFO was a really good champion of making these changes, albeit highly risk-averse. So we had to really prove over a year's time that this was the right thing to do for the business, because to finalize that shift from just a seat-based model to what was, what would really be like a usage-based model was such a tremendous amount of organizational lift and shift, retraining. Rethinking, lots of change. So it took a lot of resilience to make that happen.

When, when you look back to the very beginning, did you realize this change needed to happen because, you know, basically expansion was plateauing and you could see that in the, the data? Or did you hear it from customers first? Or did you just have an intuition, we've got to move towards a new metric?

It was a lot of noise. And we had to sift through that noise to find the signal. We initially thought it was an adoption problem. We thought at a certain point it was a TAM problem. Like, does every developer really need LaunchDarkly? The answer is yes, absolutely. So we had pretty strong belief that that was the case. And what we ended up seeing was that customers were sharing seats and making it harder for themselves to get the true value because they didn't want to pay X amount of dollars per seat. They just thought that that was not the right exchange of value. They didn't think about the value realization in a linear way, like, oh, I'm going to buy 5 more seats, I'm getting more value. Oh wait, I have to get QA team and support team in there. Well, they're not flipping flags or features or doing kill switches, but they need to see things. So it's creating administrative burden on the customer too. When we really start to see that that was the case, like democratizing access to our product was like the main thing we anchored on as the customer problem. And for us, that was NDR, net dollar retention. It was definitely hurting that expansion motion at a certain point in time when the customer deployed to like 25% of their total seat population or their developer population. So those are the things. The kicker too was that we were trying to sell new products. And if like a product manager wanted to use LaunchDarkly's experimentation product, they had to buy a seat. So you had to buy a seat and then you had to buy a new product. And that just didn't make sense. We just had to simplify all that friction, reduce it, remove it, and make it so much easier for a customer to get value first and then say, yes, we want to pay for that. So we really focused on reducing friction in the buying motion as well as in the product itself.

Yeah, super interesting. I'm going to go a little bit tactical here for a second, but you alluded to it earlier, which was a migration. Migrations are really painful, notoriously, but it sounds like you guys did a really excellent job at running the migration. What have, what has that taught you? What would you say to people who are having to figure out how to deal with legacy pricing and move towards a new model or a new package model?

Anytime you're migrating pricing, I think it's worth going really, really slow. I actually wanted to move faster initially, and this was, this was a good friction point in the organization between myself and the CFO because the CFO is like, you need to be 150% confident in this shift, not 99%. It has to be solid because you put the, you put the whole business at risk. Like pricing is a huge lever on the business and you got to get it right. And we were shifting everything from the start. So we, I actually went and sold the first 25 deals on the new model. So I was like, can I do it, right? Can I go figure that out? So we did it. I was like, oh, this is exciting. These customers really like it. Here's how they're growing. We tracked NDR through that beta cohort. We were looking at all their usage patterns. Then I was like, whoa, we need to go prove sales can do this. So we attached ourselves to our Enterprise Central team and worked with that org and said, hey, let me, let me just deploy in the field with you and I'll sell this with you. And so that was our second way of saying we're not migrating, we're We're just trying to see where opportunistically customers will jump on board. So then we had a bigger cohort coming out of that and a lot more learnings. But in that moment, like if we didn't go slow, we would've pushed harder for usage-based. We would've said, let's go be like Datadog. Let's just do everything Datadog did. Let's, let's copy. But what our customers really wanted was predictability and usage-based is inherently not predictable. So we pivoted actually. About 6 months in. And we did this thing called platform subscriptions where a seller could actually sell an allotment of usage based on an outcome a customer was looking to achieve, as opposed to like, here's the meter, you use it, you pay us. And that was a big shift in the original thinking. And that was a huge, if not the most important pivot in the whole like monetization strategy in that 18-month timeframe. Wow.

What have you learned about where pricing and packaging should sit and live in an organization?

This is a good question. I think there's, there's a tendency to put it in product. And one of the things I was saying to my product counterparts, the product leadership, is like, you're actually responsible for monetizing your product. I'm responsible for making it happen across the organization. And there's like a slight difference in what those things mean. It's like, The product leader sets the value of the product, and then your pricing person should be thinking about what is the price, what is the value, how do we actually teach the team to sell it, how do we market it, what are the comps, all that kind of stuff I think is super important. I think that person probably should live in product, but having someone who is deeply cross-functional has the skills to go get in the field and talk to customers like that. If you have a pricing person who is not talking to customers, I would be a little worried because they don't understand. The true value exchange there. It's not an analyst role. It's not like sit back and crunch numbers kind of role. It's like you really got to get into the field to see what they're doing, how they negotiate, how the customer thinks about it. So you could have pricing and revenue, but like, I just think you, you have to have that CEO, GM-like mindset from a pricing person who can work with all the cross-functional teams so, so deeply to be effective. Otherwise it becomes like the feature, like pricing becomes a feature as opposed to a lever for the business.

Yeah. Um, what about the— we haven't talked much about the CRO and all of this. What's the relationship that the CRO has with all of this, or at least at LaunchDarkly?

So critical. So critical. From, from my perspective, we did— we had— we went through two CROs in this time frame. So the first CRO, I actually worked for initially as his chief of staff, and he kind of was like, go solve this because this is one of the most important things for the business. And that's how I ended up moving to product where we were working we're building that whole monetization engine. And then the, the second CRO, I needed to go spend the time with him to say, here's why we got to this place. And that was really key. And, uh, he had a great leader on his team too. He's like, I've done this before, I know exactly what you're trying to do, how can I help? And that was a really key piece to making sure that that revenue leadership team knew why we were doing those things. Because like, it's his quota, it's his number. And I quickly said, I am your customer effectively. You are my customer effectively, right? I need to make sure you can do the deals that you want to do, sell LaunchDarkly the way that you want to sell it, and make sure we can exchange value the way that we wanted. And one of the key things, Fynn, in that thinking was like, we need to do big deals. And it wasn't just like big deals because of big deals' sake. It's like we fundamentally believed we could go wall to wall with a lot of our organizations and that we could deliver a significant amount more value than we were if we did it with them. And so pricing was the unlock to be able to have those conversations and truly value sell. So that was really important from his perspective for enablement, for unlocking those big deal conversations and executing on the number.

Can you say just a little bit about the CTO's role in all of this and also the CEO's? I know there, there was a CEO change during this time too.

Yeah, uh, the CEO is probably the most important person. Like, and I think about it this way, uh, when I was, when I was prepping for this, what I see at a lot of earlier startups is the CEO is really the pricing person. Like, they're, they're setting the pricing, they're setting the packaging, and they do it with their product leadership team and their revenue team. But the reason they do it is they are sitting in the middle of the business and they see everything holistically, and they're talking to the customer. So what I had to do is, uh, Dan, our new CEO, was coming on board, was like, give him all that insight, try to help him understand like the customer's perspective. And he, when he was doing his customer tours, he would ask, and he quickly saw like, okay, this is actually a problem. So how do we make sure that this happens? Because the CEO can unblock anything that you need. So that was really key. CTO or CPO, CPTO might be the way to say it. They support all the product monetization. And so what Claire really cared about here was like, hey, how are we going to monetize new products the right way? How are we going to make sure this is super simple? How are we going to make sure we, we can bring products to market with the velocity that we want without slowing things down, having to go through the whole go-to-market motion? We can test and iterate on price and then bring it out and deploy it to the team. And then within the CTO's office was also the team building a lot of the billing infrastructure. So that team was absolutely critical to deliver the whole program to the business.

If you were talking to 20 or 30 people that are a lot like you in terms of skill set, but they're sitting in $10 million ARR businesses, maybe $20 million ARR businesses, maybe $5 million, what do you want to leave them with? What's the most important message that they should walk away with as it relates to how they need to support the evolution of all of this as their businesses continue to grow?

There are, I think there are two things that come to mind as it relates to like monetization and thinking about those things. One is stay very close to the customer. I think that's really important. I would, I put a sub-bullet on that, stay close to the customer and competition because competition can change your pricing game really quickly. If someone's selling low, like they're going to put a lot of price pressure on you. And if you want to sell high and at a premium, you have to defend that. So that's really important. I think the second thing is don't set it and forget it. Like price is something that should absolutely be dynamic. You should be thinking constantly about what are you delivering to your customer? How does that change the value they derive? What is your packaging? Is it the right thing the customer needs? I think we lost sight of that a little bit in LaunchDarkly, like 4 years into my journey here. And it was, it's so important somebody is thinking about that every step of the way. So that might be you, that might be that person listening to this podcast. You should be thinking about Can you deliver more value to the customer? Can you maximize the value you capture from that every step of the way? And I do tend to think that that's that $10 million ARR company tends to be the product manager thinking that way.

Yeah, I think what's so compelling about that is it is not be close to the customer so you can kind of effectively establish the extent to which you can lift price. And there's always board pressure to go lift price. Yeah, it's be close to the customer so you understand how to earn more money from them, and they, they want you to earn more money for them as long as you're earning it.

Deliver more value to the customer. Thank you. Can you rightfully do so? Do you have the right to deliver more value and then capture that value? I think that's such a great way to approach the customer relationship in the business is what are, what are those bits that make up that value and how can you do more? How can you, um, take budget from other places is like a really good question to ask that customer. Hey, if you were to, to move some budget around, would you take, would you create new? And then it's a really good way to think about how you actually create value in that organization.

Yeah, I really like that question. But, um, a little bit about the feature management category, because 10 years ago there wasn't a category called feature management. Now there's a big category and you guys have created it. How is the category evolving and how do you see the category evolving over the next 5 years?

I think every single organization in the entire world that's building software has to mitigate risk. You just saw this with CrowdStrike. They pushed out a bad config and didn't think about if that went wrong, how do you actually roll that back with no manual work that they went through? So I think a lot of CEOs now are thinking about, hey, is my software process putting me at risk? Because ultimately, if you're down, then your customers can't use your software and they can't get value. And that is something that I think every single leader at the CEO level should be thinking about. And that's what feature management delivers. It delivers application stability and it delivers the peace of mind knowing that you can roll something back really quickly without taking down your whole application. So that to me is like set in stone. Every organization should do that. LaunchDarkly will be the best at delivering that. I think other companies are starting to try to deliver that in their own way. You're also having a convergence around the concept of this control point in your code. Like, what can you do with that? Well, I need to run an experiment. I need to gather analytics. I need to observe if that thing is working. So you have a lot of other organizations thinking about this problem too. And I think feature management starting this way in the market, we're uniquely positioned to own it. Because we have been developer-first, we thought about that experience for developer-first. So feature management will ultimately become the root of all these other use cases across the market. And being close to the developer will be the most important thing for any organization who's trying to do this to be able to build a sustainable business.

The idea of the control point is so compelling, but, and for me, what it draws is this idea that we're actually really still in the early innings of feature management. And in fact, I was talking to a former LaunchDarkly developer evangelist, Brian Rinaldi, and he said something to the effect of like, there's so much we can do with feature management and feature flags specifically. And if you take it back just to the entitlements use case and monetization, the feature flag as a primitive is something that now every developer is familiar with. But if you extended it into entitlements, the company doesn't run into a lot of the debt, the monetization debt, the commercial debt that you described you had to go through.

I think the more control and insight you have around features, how they're delivered, is going to put your business in a position where you can optimize and maximize pretty quickly and build more, you know, build more value for your customers. Because you might find a feature sitting there, it's actually not used ever. People can give you that insight. Like, or you, you know, in your packaging, hey, it's time to move that from the best package down to the better or good package. It's commoditized, or everyone uses it, you know. Getting that insight and thinking, uh, helps you create a product that is alive. And what I mean by alive is that it is responding to the market, it is responding to new technology and systems, and it's responding to your company culture too. That's going to change over time. And so If you have something that's more static, it's harder to innovate. It's harder to like actually build really interesting things that customers care about. So the more that you can have software become a heartbeat within your organization, delivering software specifically, I think the more you can actually continue to innovate at a consistent pace, which I think that's always the hard thing. Like every organization has this moment of innovation or like this amazing product that they built. How do you keep that going constantly? And truly the greats are the only ones that do that.

I love that idea of create a product that's alive. That could be the title of this episode, maybe.

I like it.

So a couple more questions, but maybe kind of outside of work, could be work, but when you're thinking about the next kind of 5 or 10 years, what are the big changes going on in the world that attract a lot of your curiosity, a lot of your personal curiosity?

There's two things on my mind. I have a little Claire Vaux sitting on my shoulder right now that's saying, "AI, AI, AI." I know she'll listen to this, so she'll chuckle. I do think AI is going to be a thing. I call it practical AI, AI that's going to help me do my job better, not the promise that you'll hear from a lot of companies that are building AI things. I actually think that's really interesting. I got to use Claire's side product. It's called ChatGPT.

I've used it, yeah.

It's amazing. I actually made a PRD. I'm not a product manager. And I was like, wow, I got 90% there. I knew what I needed to do. It saved me so much time. So stuff like that is just going to make it simpler. But I am hearing from a lot of founders like you, Fynn Glover, that you don't need to hire as many people to deliver the product and software that you needed to 10 years ago. Interesting for founders. I think you'll see more founders go build really cool stuff. I think it's harder for folks who are really early in their career and trying to get into an organization. It's like my career advice for folks who are 21, 22, go work at a startup. You'll learn the whole business. It's gonna be a little harder for folks to find that role. Like, Finn, for you to take a bet on someone earlier in their career, can probably solve a lot of that with AI. So it's gonna be an interesting challenge for society to think about. It's like, how do you build the next Finn? How do you create these people who are really curious and wanna solve challenges? Well, you probably need to do it earlier. You need to do it in high school. So equipping those folks with those tools, I think that's really cool. That's the positive part of it.

I love the second-order effects of what AI means. That's one that I hadn't thought of, but it makes a ton of sense. I love it.

Yeah. I think it's the other part of that is just like me who, I mean, I took a shot at building software and it's hard. Writing code is hard. And I just found myself like, oh, what does this mean? How does this thing work? And I was in a rabbit hole in 30 seconds and I was like, I don't know if I can go do this. But I feel like I could actually go create an AI app pretty quickly. A guy I work with, Cody Darkland, like, was just doing the whole cursor demo for me. He's like, oh, look what I built. You remember when you mentioned that idea? I literally built it in 5 minutes. And it was so cool to see what he spun up. And I was like, what's really interesting about that is that you can have folks who aren't software engineers go solve interesting problems. And I have this beautiful idealistic vision of the US and this country just becoming a country of entrepreneurs solving really cool problems with software. Like, that is a future I think anyone could get really excited about.

Well, maybe on our next episode we can talk all about, like, the future of the United States and how it preserves everything that's so good about it. What is the most— what is the most informative and important moment for you professionally? Is there a moment that really, like, that was the inflection.

I have been thinking about this quite a bit, uh, as I am thinking about what I want to do next in my career, my life. And, you know, do I want to go start a company? Do I want to be a revenue leader? And working in pricing, I think, has been one of the most profound experiences because I had to understand— I had to go learn every single aspect of the business, and I had to learn how customers really derive value. And I think it's something that a lot of salespeople actually miss. They don't think about this a lot. They should be thinking about that business case, how customers think about, uh, extracting value, how procurement teams think about extracting value. And working in pricing actually helped me complete that picture where I can confidently get in front of a C-level person at JP Morgan and have an actual conversation with them, as opposed to being more of pitching you something. Well, I actually can relate to you in a certain way because now I know how you think. And that has progressed my ability to solve business challenges before. Like, I, I think the pricing thing is such a fascinating, uh, uh, world for anyone to go explore, and, uh, you'll learn a lot.

It's awesome. I totally agree. Where can people reach out to you, learn more about LaunchDarkly, ask you questions about monetization and anything else?

Yeah, anybody's welcome to reach out via LinkedIn. I generally Answer most LinkedIn messages, I think. I'm trying to do Twitter/X, uh, joe.ryan, and, uh, otherwise email at joe@monstrarkly.com. Would be great.

Joe, this has been such a pleasure. Thank you so much.

Yeah, super fun. Thank you, Fynn.