Monetizing SaaS: Episode 15 with Justin Gagnon of Calendly

Justin, it is so good to have you on the podcast. You played a really, I think, instrumental role for Schematic when we were first getting started, just helping us kind of understand and appreciate the complexity around monetization as a company scales. So I'm really grateful to have this conversation with you. Your background, you've been an engineer, you've been an engineering leader at some amazing companies, UPS, Cox Enterprises, Calendly. Can you tell us about your journey and how you got to now?

Yeah. And thank you for taking time and having me on. And I really appreciate that first, very first conversation we had a long time ago. And to see how far it's come since then is awesome. So, yeah, a little history about me. I actually— technology was not my first career choice. I spent a lot of time in the music industry doing some, you know, it was one of those you come out of high school and you're like, should I do computer science or should I do music? Well, computer science will probably always be there. So let me attempt the music side of things. And I loved my time there, but I found even then I was still drawn to the technology side of things, right? And my goal and what I really wanted to do was, you know, go back to school and like, I wanted to write like software synthesizers or something when the music industry, right? Maybe I could get a job at like Pro Tools or something. Ultimately decided that, you know, working with audio is hard and I didn't want to do that. So I kind of went into the more businessy sector of things, which is where I actually ended up at UPS as my first job. I was on the team that kind of like redid their entire website, which was an incredibly difficult problem to solve because the amount of pages we had to rebuild and all that stuff, it was, it was crazy, but it was such a good learning piece for me. After that, I decided to kind of like, okay, I did the Fortune 50 stuff. Let me do the exact opposite. Went to a smaller startup called Experience that was a Cox Enterprises company that did live entertainment technology. Oh, what a dream job. Going back to that music thing, right? I found that it was the perfect mixture for me. Unfortunately, when COVID hit, there was no live entertainment, but there was no technology to support it. So I found myself, that company shut down, unfortunately.

Well, by the way, just that was, I knew of that. So Greg Foster had been the CEO there.

That's exactly right.

Had Sandeep been there too?

Yep.

Yeah. Yeah. Yeah.

It was, it was awesome. It was such a fun product to get reselling and upgrades and swag shops for, you know, we were pretty much like a, you know, we were working with the teams and the venues to make the actual customer experience better on game day or during the event. It was, it was really, really, really cool. Really fun. Fun. I got to attend a lot of really cool stuff. Um, love that job. It was— and the people were amazing, super smart. Um, love my time there. Um, but the opportunity arose, uh, when, when we shut down to try something different, right? I went from that really large company to the really small company, and I said, let me try something in the middle. And I actually had a recruiter reach out to me with a Calendly link. I was like— it was my first time. Now you gotta remember, this was several years ago. It didn't hit the exponential growth that it's at right now, but it was my first time actually utilizing it. And I was looking for a new job and I was like, okay, well, what is this tool? This is cool. Oh, they're based in Atlanta. Oh, they're based 5 minutes from my house. This is interesting. Let me, let me reach out and ended up not doing anything with the recruiter because ended up here. So yeah, I mean, I've been here now for almost 4 years. I run the growth department from an engineering perspective. Growth for us is pretty much the standard capital G growth teams. You know, we have our onboarding, activation, retention, and obviously monetization. When I came in, there wasn't a monetization team, which I always found so interesting. Like they were already in that kind of not quite unicorn status, but getting there. And I'm like, how did you get here without a monetization team? That's shocking. Let's pour some time and resources into it. So they were very good to me and we helped build like a, I believe the best monetization team out there. With for sure. So, um, yeah, now I'm here talking with you.

Awesome. Well, um, so tell us more about where you're spending your time these days with Calendly. Like, just break down growth for us a bit more.

Yeah, so what we're— it's really about devoting time and resources to continue the exponential growth that we've seen over the past few years. Calendly is such an interesting story about how it got to where it came from for like, you know, it's, it's, it's simplicity and its virality is the most beautiful part of the product. Right. Most people think of it as just like, oh, you send me your booking link and then I book with you. That was easy. That's so great. The amount of things behind the scenes that go into that are obviously quite intense. And then there's a lot of other, you know, products and offerings that, you know, unless you're maybe in like the sales ICP or recruiting ICP that you're probably not going to see as much. So, so really just like rolling out those new products and moving from a simple booking page to exponential growth to where we are now to continue that exponential growth in the future. That's really, really, really difficult. When I say exponential growth, you know, it really is one of those things. You got to maintain that curve. No matter where you are, you always need to be increasing that curve. And that's what growth is, right? That's our whole purpose. Our whole purpose is to retain people and onboard people, activate them, activate them meaningfully. People have signed up for a reason. There's a reason they want to utilize your tool. Help them utilize your tool because let's be frank and honest, Calendly, when you land, can probably be an overwhelming experience for a few people. So figuring that out and then the monetization aspect of that is well. As we do that exponential growth, one of the best ways to support that is new products, new features, new functionalities. And you have to change that pricing and packaging model. You have to change how you support your business while also being fair to the customer. Um, so everyone kind of wins together type of thing. So that's kind of where, what I'm working on. I know it's a big abstract thought, but it's a big abstract idea and problem to solve.

Well, monetization is huge, and maybe that's, maybe that's a place we dig into, like, what is monetization? How should other people think about monetization as, as a practice? Like, is there a framework that you've kind of come to, this is how to think about it? But before we get into that, maybe help us understand why monetization at Calendly at this point is complex. Like, I assume it has something to do with you're trying to support multiple go-to-market motions, a bunch of new products. Maybe, I don't know, maybe kind of tell us about the billing model. Is it like seat-based? Is it usage-based? Is it hybrid? Maybe kind of paint a picture on that front before we get into what monetization is.

Yeah, sure. Absolutely. So that's part of that kind of growth that I was talking about earlier, changing the complexity and why there's a team. Very talented team solely dedicated to this problem in this space is because you go from way back when, way, way, way back when in our pricing structure, way, way, way back when. Okay. And then you change that pricing structure. But you, as I mentioned, you need to be fair to your legacy customers. They are. And when I say legacy, I mean legacy pricing customers. Like there's a, they are the people that got you where you are right now. And there's nothing wrong, I believe, with the standard Netflix. Everyone gets the email, hey, we're increasing our pricing. There's nothing inherently wrong with that, but you'd need to do it in a smart way that is equitable to everyone, right? When you go through several iterations on that, you now have people who have kind of historically strange pricing models supporting that. One takes a little bit of time and a little bit of historical knowledge on how they got to where they are right now. And you want to make sure that as new features and functionalities are released, their pricing models that are keeping them with you, not the only thing keeping them with you, but one of the reasons that they still have a seat at the table for the new functionalities that are coming. Then you pile on top of that, we've always been subscription-based. I mean, that's the SaaS product, right? X amount of dollars per month, per year, X amount of dollars per year per seat type of thing.

Model.

As you expand and as companies kind of push past the $150 million ARR, like one of the things they have to do is build additional products, not features and functionalities. Now you need additional products. Some of those will be usage-based, some of them won't be. How do you get access to all these different products and how do you support the ability to do usage metering? So essentially, to answer your question, we are in kind of like a hybrid mode right now. There's add-ons, there's going to be usage metering, there's the standard fees, you know, and then you also have to support enterprise. And enterprise is its own thing, right? Like you should never stop an enterprise customer from not coming to your product because they have an intricate pricing model, right? Because their needs are different than the standard person, the yoga instructor that's coming in and needs a single booking link. Supporting the yoga instructor In the enterprise company that has, you know, 10,000 seats that they want to purchase for a 3-year process, you need to be able to support all of that and everything in between. It's really complex, actually.

You know, it's— I'm always looking for ways to like categorize and bucket complexity to try to package it into something that people can understand. And when I hear you speak, like one of the things I hear you saying is, hey, look, if you're going to be a really successful company, you're going to go through this inevitable evolution from like single product to multi-product to enterprise selling. Along the way, you're going to release a bunch of new product or new features, and some of those might be billed in different ways. And by the way, you're going to have a bunch of new customers that kind of want different things, but you're also going to have all your legacy customers that got you there. How do you deal with that? And so now you're, you're talking about like an immensely complex surface area with tons of permutation around what someone might have access to or what an offering to a new customer might be or some bespoke enterprise plan or something like that.

And then to add another layer, you're building more stuff. You're always building more stuff. It's like the analysis with biology. Like if you stop evolving, you die. And that is true as a company as well. You always have to be evolving. So while you're still maintaining all that stuff and you're still maintaining all of your, you know, legacy pricing and the customers that you've had for years and your enterprise offerings, everyone in between, your 2 to 10 seat buckets, your 100 seat buckets, your 10,000 seat buckets. Now I'm adding something really cool that everyone is going to want. How do I then support that too?

Yeah. I've talked to companies that, you know, get really big and they end up with like hundreds of cohorts of one. Meaning this customer's on this like legacy SKU.

Yeah.

And it's just, it's a morass, right? Because then it's like very difficult to understand who has access to what, how you optimize monetization, how you kind of deliver a great customer experience to these, to kind of these, these random customers on these old plans. It's really, it's really crazy.

And the best thing you can do and what we've kind of done from a technical perspective, um, is not everything can be solved with a layer of abstraction, but that's how you support this, right? Like you really need to have. Because I've seen the same thing. Companies go like, well, we have this one iteration of this one customer's on this one SKU with this one add-on. And like, it essentially turns into, you know, historical knowledge from someone on the team that's been here for 5 years. And so-and-so X, Y, and Z knows why this happened. And make sure though, that every time you do a release, you support that person because they've been here for a long time and they're an important customer of ours. It doesn't have to be that way. Yeah, it really doesn't. The least amount of SKUs and offerings that you have that you can add abstraction on top of, I think, is the cleanest model, at least for us going forward, because we did have the conversation of, well, every single time that we want to iterate on our pricing and packaging or we want to do an experimentation on our pricing and packaging, is that a new SKU? Probably not, because then we're going to end up with 3,000 SKUs. I don't know.

It's like a tweak to a SKU. So it's more like a version of a SKU.

Yeah. It's like a V and yeah, you see that you'll see standard V1, standard V2, standard V2.3. Well, what does that mean? Right? Like what does that person get? Because when you're looking at your subscription management software or if you're building it internally, knowing that context is usually built in the code somewhere. Or in some Confluence doc or in some README file. And knowing where that's located, especially for like net new people that are coming into the organization is it's impossible to get up to speed and be meaningful at any, any reasonable timeframe.

Yeah, totally. So I want to talk more about like the abstraction that you described and kind of get into how you've thought about building this infrastructure at Calendly. But before we do, just for the broader world of B2B SaaS businesses who have product and engineering leaders working on monetization, what is a good definition of monetization? In other words, what does it encompass?

It's going to mean something different depending on your size, I believe. I firmly believe that. So my suggestion would be for net new companies, you know, take this with a grain of salt. Every company is going to be very different, but having a monetization sector, even for a very small startup, is incredibly important because monetization at that is also about kind of the growth motions. All right. It's, it's not only about the payment structures. It's also about kind of the activation flows. You can swing that at a smaller company. But as you grow and you grow and you grow, monetization then starts narrowing and narrowing and narrowing. It's kind of that like black hole comparison, right? Like as the star gets bigger, your monetization needs to get deeper, right? Like in the, in the, the knowledge that you have has to be like, your team is then like a center of excellence for what monetization is for that group. I think every company, it will look slightly different, but it needs to encapsulate like your pricing and packaging. It needs to encapsulate your various flows of how you accept money. And I know that sounds simple, but also again, it's not. What about internationalization? Wallets, Apple Pay, in-app purchases, Google Store, credit cards. Are you accepting all credit cards? What's your payment processor look like? Do you want to experiment with your payment processor? There's a lot of good payment processors out there. Maybe you want to do a different payment processor for Europe because the approval rates are higher. Maybe you want a wallet in China that obviously doesn't exist in the United States. How do you support all that while also like not causing churn problems or like confusion in the signup flow? Ultimately, like my motto when I was just on monetization is we cannot hinder people at this step because they are ready to give us money. Don't stop people from paying you. That simple, right? I say it's that simple. It's really not. It's actually very complex. But that's the key, right? Like, don't stop people from giving you money when they're at that step. That's the step.

Yeah. I mean, a lot of people would say, like, it's all about reducing friction around the path to payment, right?

Yeah, of course.

Yeah.

It could be something so small as, like, I've run experiments before at previous places where you go, okay, well, we have our credit card entry flow. Do we ask for an address right now? Yeah. Well, it's extra stuff and it would increase our validation rates, but it does also increase— now this was before everything auto-populates, to be fair.

Okay.

So it's, it's, um, today that problem is a little bit more simple, I think. But, you know, it really was like, you have to think about that. Like it really was, especially a few, only a few a few years ago, I feel like I'm dating myself now, but like, you know, you really had to think about like the level of clicks and the amount of input that people were giving you for signups and for payments. Like I mentioned, it's a little easier now with, you know, built-in, you know, wallet providers and whatnot, but still something you got to think about. Reducing the friction while again making sure that you have as much information as humanly possible and the customer has as much information as possible. You can also do the reverse. You can reduce the friction too much where then the customer doesn't know what they paid for and what they have features to. I've seen that at other companies as well. You pay and you're like, well, I thought I had this, but now I don't. And now I'm getting paywalled again. Now I'm upset.

And it feels like that's true in both consumer apps, but also increasingly in B2B software where usage-based billing is coming, is kind of growing so quickly. Why am I getting this bill?

Exactly.

Yeah.

Like the, I've seen some B2B SaaS products starting to implement. And again, I'm going to do a little tech speak here, but like the GCP model, the AWS model, where at the end of the day, you kind of don't know exactly what your bill is going to be. You're just kind of hoping that you planned correctly. And then you're going to see when you get your first bill and you hope you're not surprised. That sucks. That's terrible.

It's a big problem when you've got like very empowered customers who like very obviously demand a lot of transparency and like what they're going to be paying for and what they're going to have access to.

Exactly.

Yeah, exactly. So, you know, one thing that's been kind of interesting to me over the course of the last couple of years is I've thought about this problem and talked to people like you is it seems like monetization, pricing, packaging, it's all really complex. And a lot of that complexity falls on product and engineering to support over time as the business goes through these, these kind of evolution paths. And many, in many companies, you see pricing and packaging, a lot of this business monetization logic gets in some ways hardcoded into the application, like it lives in the application. And that has led me to sort of kind of wonder if there's a big problem in the world around there not being some standard or some pattern that product and engineering can leverage to build and maintain monetization infrastructure that maximizes flexibility. And I wanted to pose that to you. Do you think that that's valid? Is there a lack of a standard or a pattern, or is that invalid? There actually is a pattern and there is a standard, but companies just kind of like don't know about it yet.

No, I agree with you 100%. And Every place I've been has done it differently, which kind of proves your point. Um, every company that I've kind of even come in and assisted a little bit and kind of worked with them on some of their monetization strategies approaches it in a very different way. And sometimes you're like, okay, this is an entire ball of string that needs to be completely undone and redone in a very different way. But you can't really do that to your point when it's all in the code. Monetization is not really one of those things that even the most adept developer— I'm trying to figure out how to phrase this correctly, but like, by themselves in a vacuum is probably not going to build a good strategy unless they've done it before and seen the pitfalls and has the historical knowledge on how to build it in the future. But even then, they're stuck into one monetization structure and they're just going to apply that everywhere.

Well, so why is that? Because I think that's a really important point.

It goes back to my original thought of even smaller startups need to invest in their monetization structures and the pricing of packaging and growth as a whole. If you don't get it right early, you're paying down your bad decisions late. And when you're paying down bad monetization decisions, it's way more expensive than paying down other bad decisions. A lot of bad product decisions can usually be rolled back, can usually be iterated upon, can usually, you know, okay, well, that didn't really work. Let's turn it off for these customers and build like a different version of that. You can't do that with monetization. You cannot turn off your monetization structure. If you do that, your product will die and your business will go out of business.

It had—

and you can't really fail forward on it either. If you roll something out and it doesn't work well, what do you do?

Which creates this very high bar for iteration and experimentation.

Exactly.

Which slows businesses down, right?

Exactly.

Yep. Yeah. Often I hear engineers talk about this problem and they'll say there's a lot of tech debt. And it's interesting because it's kind of tech debt, right? But it's not like truly like traditional tech debt. It's more like billing debt or commercial debt. Like, what do we mean when we say tech debt in sort of this surface area, in this monetization surface area infrastructure?

Tech debt, for me, when I hear that, is really going back to monetization as a, you know, last class citizen. So what a lot of companies will do, especially when they're Building their product. Well, we need someone to pay. I don't know, throw Stripe payment component on it and we'll figure it out later. Okay. But then you have implementing Stripe is, I mean, they've done a pretty good job, right? But like there's, it's pretty intricate to do that. And if it's the very last step and we need to support this or whatever the payment component, I don't care what it is. Whatever it is that you use, it's usually one of the last things because so much at smaller startups is spent on making the product monetizable, but no one cares about the monetization strategy. That's a huge problem, right? It goes back to my— I'm going to keep saying it. Monetization should be a first-class citizen as early as humanly possible. You need to be thinking about this from day one. And I don't mean from a perspective of, well, let's try to like forward map what our costs are going to be and do like a I don't know, like add 20% to that. And that's what our price is going to be for the monthly users. I don't mean that level. That is naive. That is what like I would expect someone in like elementary school to figure out. Right. I mean, like you really got to dive deep and figure out how you want to monetize this, how you're going to structure your application that should be built into it. And that's what all that bad tech debt is. It's not necessarily tech debt. It's just bad decisions made because it's not treated seriously until it's a problem. And then it's the biggest problem in the entire world. And then you want to iterate on it, but you can't.

What's the role of entitlements in this problem space? And if there's a different word for it, I'd love to know the word you use because many engineers use different words for the concept of entitlements. Yeah.

So I think that is the best place to start. Like if you start with who is entitled to what features and functionalities and how you're going to make that easy to digest from the customer side, you're already ahead of the curve for what you need to do, I think. Because then your monetization strategy and how you roll these things out and how you build these things get much more clear. So, you know, if you're saying I have zero, I have a free plan that has like almost nothing or one plan that has everything, you're doing it wrong. You need versions of it. And it's okay to like make your free plan much, much, much, much, much smaller and have an iterative step. And then like another one, maybe for your first time SaaS companies as they're rolling out from like their zero to $1 million ARR, maybe you only do one, maybe two, probably two. But then as you hit like $1 mil, you like, you need to then iterate on that and change that model a little bit. You need to be a little bit more flexible. And at that point, you should have already built some more products, features, and functionalities that'll get you to that $10 mil. And once you get to that $10 mil, you're probably in a really good spot, right? Probably very sustainable. You're good to go. But if you're not thinking about entitlements early on, then again, you're not setting yourself up for success.

Yeah. And it's like, if you end up in a place where you've thought about it early and then you have like a robust entitlements engine or system as you scale, you're going to enable a lot of agility. Very few companies do that for whatever reason. There are lots of ways to implement entitlements.

Sure.

Like what are, I mean, what are some of the ways you've seen companies implement entitlements and how that kind of creates problem? And then I want to kind of move towards like how you guys have built monetization and the abstractions you've talked about.

Yeah. So I've seen it pretty much every way that any tech person would think to build it. And that again is the problem. When you ask, you know, a dev, a senior dev, whomever to build your entitlements engine or how they're going to build it again at businesses, smaller businesses, you are moving towards the MVP to get it out to people as quick as humanly possible. So if I'm on a small startup and we're at our zero phase and we're about to release my, I'm not worried about type inference. So I'm pretty much putting everything behind an if-else, which is terrible, but that's what I'm going to do because we need to get out there. They're either a paid customer or they're not. You build some, obviously you build some abstraction, build some, you know, helper function, all that stuff. Right. But like, it's so built into the code. You see that all the time because that's, that's that last step. As companies have progressed and as, and you're very aware of this, like there's now software to help with that and to track it much better. There's pros and cons to that as well. But I think the pros are like you kind of remove it from the development. I think of entitlements very similar to how I think about feature flagging.

Yeah.

Like it should be fairly dynamic and you should be able to change your rollout strategy based off of the flag that you have. And people are so familiar with feature flags in the industry, but they're not as familiar with like entitlements, but they're pretty much the exact same thing. I want to have a central point where I say, does this person have access to this feature? Yes or no? Or give me all the features that this person has access to. That's it. And it needs to be a central point of truth. That's it. That every calls. And I think that's the level of abstraction that we've built.

Yeah, that's super interesting. And the other day I was talking to a CTO of a company and he said, like, people really should think about feature flags and entitlements sort of in the same conversation, because if you extend feature flags into entitlements, you create so much agility because like the way he kind of described it, I thought was cool. He was like, look, when using feature flags as interface, you'll get a Boolean flag back. There's no reason to care whether that Boolean flag is the result of whether the user is in a rollout group, an A/B test group, what plan the user on, what their usage has been. So using flags allows you to not have any plan-related logic or data in your app.

That's exactly correct. The last thing I want my dev team to worry about is why this user does or does not have access to this feature. I just want them to know—

The engineer should be thinking about new features, not like— the business should think about how to package and sell and price a feature. The engineer should not have to think about that.

Exactly. Yep.

Yeah. So, so tell us about the, the monetization infrastructure at Calendly. Like, how have you built it? And maybe it's like, take us anywhere you want to, but like, have you thought about it in components, and these are the components and how they must work together? Like, how should people think about building monetization infrastructure at the scale that Calendly has realized and achieved?

Yeah, good question. So for us, building the correct services on the correct technology with the correct third-party integrations. It's really how it kind of boils down, right? So like service extraction and building the correct services, I think is the number one thing. For monetization, as we talked about, you want it to be as agile as humanly possible. So how do you build a standalone thing that can be as agile as humanly possible? That means something different for every company. I'm not talking about the languages necessarily. I'm talking about what the service needs to accomplish, what the API structure looks like. We put our entitlements in that service because that for us is how we move agile because we add a lot of features. We experiment with a lot of features. We have a large R&D operation that is constantly monetizing features and putting them in different buckets and wants to experiment with different things. So that's that central point of truth that I was talking about. So that's kind of how we've done it. We've extracted every single thing from an entitlements perspective and really like, you know, the actual, the traditional, like, you know, payment processing stuff into like one thing. There's also like a metering thing. Like you really, that should be separate. Like, how do I meter? That, that should probably be a different technology, right? How do I track metering? How do I know this person in this org used this feature this many times on this date? Like that's a basic service. It's very basic, but it should be a standalone service because you don't want your central source of failure to be that. Ultimately, you don't want to gate people from utilizing a feature. So if that goes down, just let people pass through because you want people to be utilizing stuff. It doesn't go down though, because it's pretty much an incredibly simple, you know, Fynn Glover 2 API, you know, service that has incredibly high reliability. So thinking about it in that way, you're going to have different monetization needs for your, for your tech stack and making sure that you're utilizing the right architectural decisions on how to build those services, I think goes a really long way. And a lot of people miss that because they go, well, I'm so used to writing in Java, so I'm just going to write a Java service to do this. Probably not the right choice. Probably not the right choice because a lot of monetization is not necessarily like just like throughput API calls to third-party integrations. A lot of monetization is iteration on what you currently have. And just make sure you're utilizing something that works for what your needs are. And that's what we did. And I think we have a pretty robust engine right now.

Are there other services? It sounds like entitlements, metering are two discrete services. Are there other services that are core to the monetization infrastructure at Cal?

Standard billing stuff that every single company has, right? I think between those three, if they're built robustly and good enough, you're going to solve 95%, if not higher percentage of your use cases very early on into your very exponential growth stages. Other companies have different needs, like I mentioned, and how they build those out, they, you know, that's up to them. But for that, again, simple is best so the team can move fast. So as we roll out new stuff, we're not bogged down by anything. That's the thing. Like agile is a word that we overuse a lot in this industry, but like you really do need to be agile in the monetization space. Yeah. Need to be able to move very quickly because you're dealing with people's money. Right. And there's a few things that have to be like perfect. I heard a colleague say this earlier, right? Things that need to be put, we were talking about AI. I'm sure that'll be a pop. I'm sure that's going to come up at some point in this conversation, but like AI and places that it's not going to be it's going to be hard to implement. And one of them was monetization because you're messing with people's money. One is healthcare because if you screw that up, people will die. Right? Like, and that's pretty much it. Like in healthcare, it's going to be hard to like utilize an AI engine for those because they have to be specific. They have to be purposeful. They have to be perfect. And you have to iterate on them fast.

Yeah. These are just like incredibly high stakes moments. Between a business and a customer.

Exactly.

Requiring a ton of precision around this infrastructure and the services that are built on top of it. I've been, we at Schematic have been on the hunt for like, well, what would that standard look like? That pattern look like if it were to exist? And you've already identified like, I think, 3 kind of core components or services within a potential standard metering. Entitlements, maybe entitlements or flags. Subscriptions. A couple others that we've thought about, I wonder what your thoughts are, like product catalog and company profiles. And you end up with sort of like all of these sort of interact together in crucial ways. And if they're well designed together, you can eliminate a lot of that debt and realize a lot of the agility that it sounds like you guys have found a way to achieve.

Yeah, you're right on. The product catalog is an interesting One. Yeah, that is an interesting— if you were to extract that out, then you have even more— like we've essentially kind of built in— now we use a subscription provider that does our PC. So they handle a lot of that, but the implementations and the iteration phases as like a separate service that would wrap over that would be very interesting. We've had conversations about that. We're not quite ready to pull the trigger because we don't know exactly what the future looks like for our services and how we want to implement a monetization strategy this time next year. Well, we know how we want to do it, but getting there is going to be difficult as it always is. But yeah, it's interesting. And I really like that model of like if you extract out and you have your own standalone component for a catalog, It can be much more dynamic.

Well, the product catalog is a really interesting concept, I think, because at least in a lot of the businesses that I've seen, a really common problem is you end up with multiple fragmented product catalogs in the CRM and the CPQ and the billing tool, maybe in the ERP. And all of that is disconnected from the product, right? And so what if you could, like, what if you could imagine like a product catalog that served as like a unified policy file describing all products and entitlements, and it could coordinate and reconcile changes across all the other product catalogs in the business systems, but it sort of became the source of truth for the product.

Yeah, no, I mean, it makes perfect sense and it deals with the issue that so many companies have of you should always be looking at your pricing and packaging. Once a year. If you change it, you choose not to, that's fine, but you should maybe even more frequently. And it solves that problem of like, well, we do want to iterate on it, but the cost is going to be too high. That's a problem that so many people have. Well, you know, with changing, you know, we got inflation coming up and we're seeing kind of some of our, you know, conversion rates for this SKU go down a little bit, but we're seeing conversion rates for this SKU go up a little bit. Is there a way that we could maybe change our pricing and packaging to level out the loss that we're getting for this SKU. Engineering, how long is that going to take? Oh, it's going to take a quarter. Oh, we're not going to do that then.

That's a lot of work.

Right. It's like, it's what the conversation is.

And it's so much missed opportunity across. 100%. You know, A, I would have to invest engineering resources in something that's not new features. And B, the business doesn't involve monetization in a way that probably is like really important for maximizing the value of the business and all the investment that's going into the product. Exactly. Yeah. This has been fantastic. I could probably talk to you for another couple hours about all this stuff, but I won't. Maybe we do another conversation at some point. But maybe a couple closing questions. Imagine you're talking to a bunch of product and engineering leaders at companies ranging from, you know, $1 to $10 million in ARR and they've got, you know, what, what seems to be kind of the type of product market fit that could put them on a Calendly type journey. Um, what would you say to them as these are best practices or these are recommendations that I highly recommend you guys think about so that you achieve the type of agility that you will need to move really quickly around monetization as the business gets more complex. Wow.

Yeah, I would love to be in a meeting like that. Sounds awesome. My suggestion would be to embrace uncertainty. One of the things Calendly has done well, and I will give them lots of props because I have not been a part of this mindset previously, and coming here, it's been very refreshing, is understanding monetization is not necessarily a science. There's a little bit of gut feeling that goes into it. And you have to be okay with, yes, we're going to experiment. Okay. We're going to do pricing and packaging modeling. We're going to look at our churn analysis. We're going to look at everything, right? Like you should, it's important. It's scientific. You can get a lot of good indication and indicators on where you need to go. But at the end of the day, there is a little bit of art to it and feel free to embrace being uncomfortable in this space. Because it's inherently an uncomfortable space to be in. You know, when I was back just doing monetization, I was hiring ICs. There were a few times where I had to like, when I was in the interview process, like, no, monetization is not like we're just trying to make the company more money. Monetization is making sure that we can support our product in a meaningfully impactful way that doesn't like harm our customer. And there's still a conversation where people think monetization is like the big, big bad boogeyman, maybe because it is an uncomfortable space, but like realizing it shouldn't be and diving into that uncomfortableness a little bit, I think would be really big for a lot of companies that size. Like it's, oh, and it allows them. Yeah. And I saw at previous places that I've worked that were much smaller where it's like, yeah, but this is It's a big customer for us. It's like, yeah, but if it's 1 out of 600 of your customers and you benefit the other 599, that's a better move. You have to be okay with pissing off a customer or two when it makes the 99% in a better space. You have to be okay with that. That's what I would suggest.

And if you are okay with that, if you embrace that, you have a much better shot of making monetization a first-class citizen of the product. There you go. Exactly. Yeah. You've been building for 4 years at Calendly. You've seen immense scale. What are the big changes or inflections in B2B software that grab your curiosity and kind of energize you?

I think the fintech space for me has been really interesting. Now, obviously, I have a monetization background. You're probably in the exact, you know, you're preaching to the choir at this point, but that whole area has just unbelievably blossomed to be much more. I think we're seeing it now, right? Like we're seeing what we were talking about with, you just mentioned monetization as a first-class citizen. We're seeing it now with the fintech offerings that we're getting. And there's a lot of people pouring a lot of time and resources into various versions of this. And I've seen it from everywhere from taxation, entitlements, like we were talking about earlier. There's companies that are doing a lot more with everything, like what you all are doing, which is fabulous. There's companies that are really narrowing their focus on one area of it. Being able to see it and have so many people in the space will make it more competitive, but also make it more successful and make it easier to deal with. You all are helping lead that charge. And I think you guys are doing a fabulous job. I really like the product. So like, that's, that's it though. But like this product would not have existed 6 years ago because no one really cared about it. It was like we mentioned, just we'll figure it out later. It's like, no, this is the most important part. Like it should be a part of every product decision you make.

Yeah. It feels like the reason this stuff is like matters to companies always comes back to the end customer. And the end customer is super empowered at this point and demands a ton of flexibility and a ton of transparency. And if the business can't deliver that, like they're going to go to another vendor.

We're talking about those GCP model, AWS. It works for cloud computing. It doesn't work for SaaS. Please don't do that because they will just not use your product and they will just go somewhere else, even if it's not as good. That's what I think a lot of people miss as well. Like people will embrace a cost saving and an easier onboarding, even if the product isn't quite as good. They really will. If they're confused about how to utilize your product or how to pay for your thing, or like, why do I keep getting charged this way? Or how do I add people? But that doesn't seem like what I expected. They'll just leave. Like monetization is the number one.

Yeah, it's amazing the power of that. It's got to be.

I mean, I have the numbers somewhere. I saw them recently, but like, It's a big churn risk. If you screw that up, you got a big churn risk.

It is amazing the power of convenience. And just the other day, one of my favorite products I use all the time, I needed to add another one of our team members to the product. Turns out I'm on an individual plan, not a team plan, so I can't add them to the software. Took me 10 minutes to figure out I'm not on the team plan, not on the enterprise, put them on the team plan. You know, and you start to say like, this, this is a huge distraction. And it's just like one of those micro moments happen all the time. It feels somebody else has said to me recently, that's like, you have a whole generation of people who have been brought up on like these incredible consumer experiences of B2C applications. And they expect that of B2B software.

100%. That's why like the capital G growth motion is so big right now. It's, it's, is it new? Not really, but you're seeing positions and teams being built all the time now because that's it. I mean, you need to be able to onboard people. Let's be frank, like people's ability to maintain focus on stuff has gone down a little bit. Nothing wrong with that. I'm glad it's gone down, right? Like we should focus on making that as easy and streamless as humanly possible. Monetization is the last step usually in that flow. So that's why you got to get it right, because if you get them all the way through, you screw up that spot, you're done.

One of the closing questions, questions that I like to ask is, what's been one of the most formative or influential moments in your professional career? And I'm really looking for a moment.

Oh man. A moment. So I think for everyone, I'm going to be really transparent and honest with this one. I remember one time I was working on, I'll share the experience because it doesn't involve my current company or a previous company, but just like realizing that like a company doesn't need you and you don't need the company. Okay, so I had a moment, uh, with a previous employer. We only listed it like 4, um, so you could probably figure out who it was. But I had a moment at a previous employer where, you know, it was just like, I wish I would have saw the writing on the wall that I needed to change a little earlier, right? And I had a few things pop up personally where it was like just compounding the issue where I was unhappy with my current position and I wanted to move on to something else. Just realizing that like they, they don't need me and that's okay. There's nothing wrong with that. And taking a step back, I wish I would have made this decision 6 months ago because where I ended up was one of my favorite places to ever work. And that led me to where I am now. I'm trying to like thread the needle in a veil, but I think if everyone watched this entire thing, they can know exactly what I'm talking about. But like making that decision and realizing that has gone a long way for me. Because make yourself important in, you know, at your company. Make yourself not extensible. Like, like, you should be— like, when you leave a company, it— the company should feel it. And, you know, that's okay. Um, but realizing that at the end of the day, that's okay. If you need to move on somewhere else, that's a good problem to have. A lot of people stay at a place for way too long and just kind simmer in, you know, a culture they're not happy in, and that's not good for anyone. Yeah, so I know that I answer your direct question because you're probably looking for something else, but I think it's more of like a career growth thing for me. Like, it's okay.

I think it's a great answer to it.

And try something else because you might find—

I think it's a great answer. It's such a good lesson. I mean, and I think you're right, like, people are so afraid of change that they often end up allowing themselves to wallow, or in your words, simmer in places that have, are kind of losing their ability to deliver value to that person and vice versa. That person is losing the ability to deliver value to that organization or entity.

I mentioned that uncomfortability. I don't even know if that's a word earlier where like from that $1 mil to $10 mil monetization is difficult, lean into it. It's going to be uncomfortable. Be okay with that. I think people need to do that in their careers as well. You know, sometimes the grass is not greener. Let's not suggest that. Also, that is not always the case, but sometimes it is. And make an educated decision. People's, like, personal work-life balance should be the thing that they are solely focused on, should be the thing that they are maybe not most focused on, but it is incredibly important and you got to take care of yourself. And like, I spend more time with my coworkers than I do with my wife. There's nothing— it's true though, right? I'm on calls with them for 40 hours a week.

Yeah.

I should enjoy my time there.

Yeah.

I think it's that simple. And I do. I love my time here. And that's why I've been here for 4 years and why I continue to think I'm going to— hopefully they'll keep me long term because I love working here and I do like working with my team and we are working on interesting stuff that is moving the needle. And I love the team. I love the environment. I love the product. I love it all. Like, Go find a place like that for yourself. That's it. That's my spiel.

Great, great reminders. Yeah. Time, time is the precious resource. The only, the only, the precious, the most precious resource. If anybody, engineering leader, any product leader wants to reach out to you with a question around monetization, can they do that? And where could they reach you?

Yeah, absolutely. I'm an open book. I will, I will preface that I'm not a big social media guy. I do have a LinkedIn because I don't think anyone doesn't. Pretty certain it comes with like a, your, your birth certificate at this point. So feel free to reach out to me on LinkedIn. I'm an open book and happy to answer any questions that you might have or just start a conversation. And I, I want to learn from other people as well. This is, you know, this is a journey. I'm not at the destination yet. So I don't have all the answers and there's nothing wrong with that. I'd like to learn from other people.

Awesome. Justin, thank you again.

Thank you.