How Naveen Mohan drives pricing, packaging, and monetization at Otter.ai

Yavin, it is so good to have you on the podcast. Thank you for being with us. I'm really excited to talk to you today. You are a product leader focused on monetization at Otter AI. You have a deep background in data analytics, which is, I imagine, translating quite well to monetization. But, you know, what I know about you is that you studied information systems in college, you cut your teeth in data engineering at Oracle for a few years, then Adobe as a data scientist for a few more years. Then Loom for nearly 3 years, where again you were focused on data science. But I think you also began to really push into product while at Loom. And then in July of 2023, you moved to Otter AI, which is an incredibly quickly growing company, well known by many, where you're now leading monetization. How did all this happen? What's the story in your own words?

Thank you, Fynn, for the kind words and also for having me here. Um, definitely feel old after hearing all that. So started with computer science and studying computer science because I was really interested in building things. But I also slowly realized that I wanted not just to learn how to build things, but also why, when to build them, and what to build, and working with the team of people to be able to decide that. And that's kind of shaped my journey in a way which led me to balancing my engineering studies with a little bit of business and management. And hence I ended up in the information systems course, during which I got into machine learning and AI. So that's also helped me explore and understand a few things on that side as well. So eventually got me to join Oracle right after I finished my course. It was a good opportunity to join a new data science team for the public cloud they were setting up. And there was a lot of pipeline building and data engineering work to be done, but quickly realized that I wanted to be much closer to the business decisions. So I ended up joining Adobe, learned a ton. They're one of the OGs in the SaaS business. So that was— I got to grow up quite a bit there and learn about how to operate a business at that scale and also continuing to focus on growth and the small wins, but not letting go of the bigger picture and strategy. That was a great education, but then I slowly wanted to go back closer to my roots, in a way, my roots, because back in undergrad I had my own agency working a lot with clients, building apps, building websites, and wanted to have my own startup. So wanted to gain that experience and wanted to learn from some of the best here in Silicon Valley. So joined Loom, a great company, phenomenal people, got to be part of the growth. And then I joined Otter similar to, in a similar stage to when Loom was at when I joined. So it's been amazing to see Otter grow and also grow with Otter and the people here. So yeah.

It's a terrific story. When you, when you look back, even like pre-college, was the desire to build things there for you, or did that desire sort of emerge in college?

It was more in college. Before that, I wanted to build games. So that was my reason for getting into computer science. But yeah, so it was mainly during college that I Got more into it and I also wanted to monetize it. No surprises where I landed now, but I was also interested in making sure we're thinking about that and talking customers about how much we charge.

One thing that's, I think, quite interesting about your career is, I mean, Oracle and Adobe are two very large companies. They are the OGs in some ways. And then Loom, when you joined, I mean, it was, it was a very popular company, but it was very much like on an order of magnitude smaller than where you had been. What was that like? What was that transition for you like?

It took a bit of getting used to initially, but even at Adobe, there was some elements of a startup culture in some of the teams. I know companies claim that and it's not always the case, but some teams within Adobe do do that, especially some of the GTM and growth teams I've worked with. Where they're working on a lot more things. And my role at Adobe, luckily, got to focus across the suite of Creative Cloud and Document Cloud products and thinking about insights and how do we grow the mobile app business as well as the web business. So that kind of prepared me a bit for— but it was still some getting used to in terms of all the things you could do and being very deliberate about choosing what to do and what not to do, letting some fires burn while you focus on the most important things. So that was the switch. But I also got to start off working and thinking about cool things to build for Loom in terms of recommendation engines and how do we think about incorporating AI. But then I also focused some of my time on monetization because I had quite a bit of experience from Adobe and they needed someone on the growth side as the company was growing and thinking about how do we monetize better, retain users better.

Very cool. When you look back on Loom, is there an experience there, like a specific story that you feel has been really applicable to Otter?

A few different things, actually. So one was around pricing. And as with all companies, pricing and thinking about pricing is always— pricing and packaging, essentially. Companies are always thinking about it. They're very curious about what are potential optimizations we can do on that front, because pricing had not been touched in a while. And there's a lot of opportunity there. Although I think one of the learnings was at times we were a bit slow. We did end up changing prices at that point of time, but it was a bit slower to go. And sometimes it's good to be cautious, but I think sometimes you get stuck in analysis paralysis. So that's. Also helped inform. Of course, it takes a whole team and a whole village, uh, align on pricing and packaging, and also to be willing to put things in market and let the market speak, because you can use data to gain more confidence, but you're not going to know until it hits, you know, you put the prices out and, uh, you launch your new pricing or bundles that you actually do find out what the market's reaction is. So that was a good learning. And another huge learning was around the timelines for general experimentation on the monetization side. There's always an eagerness when you ship experiments to immediately get results. But if you're shipping something for churn, reducing churn, for example, it's going to take much longer. You'll have to wait for users to convert first or the converted users to actually come and churn. And you're looking at different cohorts. So usually that's another learning, just being able to set the expectations with the leadership and everybody on how long it could take to arrive at a good result and a decision.

You know, one thing that I was, I was going to think, I was thinking about digging into a bit later, but maybe we tackle it now is this idea of monetization. Would you say that kind of your definition of monetization largely reflects or mirrors kind of what a lot of people would describe as growth. Are these one and the same? Are these materially different? How do you think about that?

I've seen it being used and defined in multiple ways across companies. In my mind, at least, monetization is more associated with growth and is also more associated with the go-to-market strategy and motion and being able to help with that sometimes directly. Sometimes you have a product marketing organization and counterpart to help you with that aspect and you have a sales team depending on the product and the market you're tackling. Yeah. So usually I keep the more infrastructure and the payments related aspects, encapsulate that in billing. So that's more the billing function. Usually you see billing and monetization combined into one pod or one team. But in my mind, monetization usually is more the growth-focused function where you're supporting the pricing and packaging efforts and also more experimentation around tackling churn, how do you get more people to convert trials, such.

Makes complete sense. I like the separation between the sort of growth and monetization, and then there's billing and payments and, and how we actually transact. You, you spend almost 3 years at Loom. It's this incredible ride. I imagine there's tons of learning. It sounds like one of the, maybe the kind of other learnings that you picked up there was maybe kind of just like the criticality of cross-functional communication in the context of pricing and packaging, and how to do that well in an environment that was I imagine moving so, so quickly. That's, that's a value in and of itself and something that I think a lot of people that are thinking about pricing and packaging have to recognize as like a core strength and sort of the practice of monetization. Take us into Otter. Why did you leave Loom? Why did you go to Otter? What's the insight behind this company that got you excited?

Uh, few different things actually. My amazing experience at Loom. And being with them during amazing growth. And I think the main reason for moving to Otter was more to be able to focus more fully on the product side of things. At Loom, towards the end, I was also doing some on the product side, helping with the pricing, helping with some of the more monetization-related experiments. But I had this good opportunity to work with some of the people here at Otter was also another thing that convinced me with leaders like Darius and Sam were exceptional at, uh, they have an amazing record in the past, so to be able to work more closely with them was another pull. Yeah, and, uh, there's a gap of also needing someone on the insights and data side for monetization, but also the product side. So it was an amazing opportunity which allowed me to leverage my strengths and data insights and monetization especially, I think, or at least the way I've experienced it is heavily data and insights focused. Growth in general as a function is, so that's really benefited me. And yeah.

When you joined the company, I'll share a little personal story here. I ran growth for a cybersecurity company that was at growth stage. They'd raised a lot of money and What was notable to me about the experience was how important it was once I had gotten into the company to define growth's mandate or charter so that there was clarity and alignment across the business. Growth monetization, I mean, it's in some ways, it can be challenging for an organization to absorb really effectively, certainly if there's not alignment across teams. But even if there is alignment, I mean, you still have to put in the work to like really make sure that this function knows where it stops and starts. Can you talk a little bit about that side of this for you when you joined Otter? Was there a clear mandate from leadership or did you have to define that charter yourself once you got into the business and realized where the constraints were? Talk us through that a little bit.

I think it's been a bit of a journey as from when I started. I am benefited, uh, I did benefit from having a more slightly more established growth team when I joined, but then the lines were blurred, slightly less blurred now because, uh, we're still a fairly small team here. So a lot of the core product aspects still do fall under some of the growth team. So monetization, also billing and being able to support some of our other payment-related activities. And so it's not purely growth, but that was a challenge. And that's something that continues to be, especially as you think about what do you want to invest in and what numbers do you want to sign up for? That's something that we're learning as an organization, I feel, and being able to say, can we purely operate as a growth team and sign up just for experiments and hitting revenue targets? Or should we also balance it with some of the more core platform and infrastructure-related objectives, for example, and projects. So I don't have a great answer for this, but it's something that we're trying to figure out.

Well, maybe you could speak a little bit to like, how do you think about monetization or growth mandate or charter today at Otter? And maybe you can help us understand that through the lens of like, how does it fit into the organization? To what organization does it report to? Roles to you, where do you, where does your team allocate all of their energy? Talk us through that a little bit.

Yeah. And again, this is going to tie with what I just mentioned around there being a few different pillars that the monetization and billing team focuses on here, at least at Otter, and I've seen it done very differently at very like other companies. But yeah, so. We have the core infrastructure piece of it, the billing piece of it, making sure we're able to charge the customers. And we work with Stripe, just being able to integrate and ensure people can pay us and when they want us to, and making sure they get billed regularly and invoices are accessible and such. So that's a core area of focus. The second being more what I call subscription lifecycle management. So right from them joining as a free user Understanding when they're ready to pay, or at least nudging them towards getting them to pay. This could be through paywalls, etc. How do we get them to convert from free to paid? And then after they convert, just making sure they're onboarded well, and then going into more of the retention and churn piece of it where you're thinking about voluntary churn. How do you tackle that involuntary churn? Just making sure, you know, billing failure or payment failures and such are handle. And then finally, once they do churn, trying to make sure they have a really good offboarding experience and you're able to get them back on the product in the future and reactivate them. That's another big area of focus. The third, again, all of these are related. Third one, more around just go-to-market support and being able to think about pricing and packaging and also how do we work closely with the sales organization and supporting them. Be it through helping identify PQLs, etc., and also crafting a product experience to make it easier for people or for the sales team to get leads and for people to talk to the sales team if they're interested. So also enabling that. So these have been some of the, our key focus areas, and that's how we think about it. So it's a mix of revenue targets, for example, and more metric-focused goals. But also some more infrastructure-focused goals around just making sure the reliability of the payment platform is there.

Yeah. Yeah. It aligns, I think, very well with how a lot of people end up thinking about growth. And it's easy to see why. It's like, it's a relatively, I mean, it's like an incredibly interesting charter to get to execute against. It's also kind of like difficult to like figure out where the lines start and stop and like make sure it's like high functioning in the company. And it sounds like if I'm hearing you correctly, like you're thinking a lot about like billing infrastructure, like how do we reduce and basically friction for customers there? How do we assure we're getting paid on time? Like how are we maximizing sort of, um, you know, effectively like how we transact. You're thinking a lot about lifecycle. So how do we not only reduce friction from activation, but also how are we highly considered in the context of like upgrade and downgrade and different paths that customers might take? And then the third thing I think I heard you say is like, how do we make pricing and packaging a real extension of the product experience? Because if it's not considered or viewed as product, it's easy for that to become extremely misaligned and drive all kinds of issues into the customer experience itself.

Yes. And I know there are different views about which organization the pricing and packaging efforts should roll up into. I've seen it work both ways or a few different ways, actually, just being part of the product organization. And also like product marketing and marketing in general sometimes have owned it. I've seen it work both ways. Yeah, here it's more, at least more recently it's been in the product side of things and the product organization. I feel like that gives a better, at least I'm biased obviously, but I think that gives better control over being able to define the entire product experience and all the journeys leading up to it and keeping that in mind. While we think about our packaging and pricing.

Makes a lot of sense. And just to be clear, monetization at Otter rolls to product, right? Yeah. I wonder if you think that, you know, I agree, like it's like, where should pricing and packaging live? Like this question is asked everywhere. And, you know, to me, I think what I've started to notice is maybe it depends on the actual business's product and go-to-market strategy. And how you'd answer that question. If you're a high-velocity software product constantly shipping new innovation with a product-led motion and a sales-led motion, it feels far more intuitive to me that pricing and packaging lives in product. Whereas if you're a maybe kind of like entirely sales-led business closing big enterprise deals, there's very little volume in terms of customer count. You could argue it makes more sense for pricing to roll to finance, where kind of the traditional FP&A skills around discounting, governance, and deal desk, and maybe even like, you know, to varying extents cohort analysis live. So I wonder if that distinction makes sense to you, because I've been kind of thinking through that question a lot over the last year myself.

Potentially, yeah. So there's quite a bit of difference in, uh, like across the companies and how their setup as well, if they're more sales-led versus if they're more product-led, and also depending on the market and industry they serve. It's interesting, I haven't seen a ton of companies where pricing rolls up into just finance or the finance teams, but yeah, but that could also be more because of my limited exposure to enterprise and how things— yeah, so, but it does make sense to given the scale of the enterprise products and companies and how they operate.

And I should add, like, wherever it lives or whoever sort of quasi-owns it, of course it must be cross-functional. Like, if you're not establishing a cross-functional feedback loop across pricing and packaging, I mean, you're setting yourself up for failure.

Yeah, there's a, yeah, so there's a few key things to like keep in like take into account, no matter who owns it, just to make sure we are taking into account all perspectives and views and also leveraging the expertise of these different teams in a good way to come at a decision that works for everyone.

Well, let's, let's talk a little bit about, well, one more question on growth and monetization. You know, I imagine when you started in the role, there were like some very kind of clear constraints on the business that were, I mean, it was evident, like this is where we should go focus. Maybe that was top of funnel, maybe that was churn. How has the focus evolved in the last year and a half and where do you feel like you're applying sort of most of your own kind of intellectual resources right now towards growing the business? Is it more top of funnel? Is it more bottom of funnel? Is it more kind of post-purchase? Talk about where you're kind of finding yourself most interested these days.

Again, like there's always appetite for focus on both. Top of funnel as well, making sure we're able to retain people. I mean, it's cycles and the way I've seen it is to be able to dedicate a bit of focus time on each one. And again, that's informed by how we've been doing our recent data and the recent metrics, but also the longer-term strategy. I think right now, or more recently, we've been thinking a lot more about, at least personally, I've been thinking a lot more about retention, churn, and how do we think about boosting the business by retaining more users. And, but then again, before that, just focusing, I was focusing more on how do we get more users to pay us, bouncing between the two. And also I think one informs the other. You look at churn, you see, you talk to customers, you understand that maybe you're acquiring the wrong set of users. So that's going to inform the conversion. Practices and things we put in motion as well. And maybe we are acquiring the wrong kind of customers and we're going to update our paywalls and limits to suit some of our, you know, the right kind of customers.

Yeah, makes complete sense. For me, that's been my experience too. It's like it is always cyclical. You try to kind of balance kind of both sides of this, but like various kind of seasons in the business, one is the place to focus on and the other takes a little bit of a back seat. Let's talk about pricing and packaging more specifically. So I know you've been at the business for about 18 months. Maybe you have a decent understanding of prior to you joining the company, the company's evolution with pricing and packaging, maybe not. But can you speak a little bit about how you've observed Otter's journey with pricing and packaging? Pricing and packaging is a journey. It is always evolving. How would you describe the journey so far?

I think there's been quite a few instances just before I joined when there's been more major changes. After that, it's been slower, but then we're constantly thinking about pricing and packaging, as you know. And it's also, I think personally, ever so often, maybe depending on the business itself, having regular check-ins with respect to where you're at with respect to the market, looking at internal usage, et cetera, to see, are you giving away too much for free, et cetera, has always been helpful. So that's continued. Like you mentioned, it's a journey and you continuing to do that over the course of, I think. It's also helpful to track Otter's journey from being a more transcription-focused business when it was initially started and pricing was more suited to that use case, pricing and packaging. And then it's evolved more as the company has evolved to like a more meeting-focused and a meeting assistant-focused business. We've also had the opportunity to evolved most recently, just thinking about having autonomous bots join the meetings. That's also changed the way we package. That was just before I joined. And after that, we've been thinking about how do we make it more helpful and get people's minds away from minutes, which was more a focus of the transcription business. These are some of the things that we've learned and adapted, just keeping in mind who do we want to attract and thinking about the audience that we want to focus on as well.

So.

Customer base.

Um, yeah, that's great. And so today, today, how would you describe the pricing model? I mean, you know, in my review of the pricing page ahead of this, it seems like there's a freemium model here, there's subscription-based pricing, um, there's feature gating. Clearly there are some limits. How would you paint a picture of the pricing model today?

So, um, a couple of different things, and we have some general guidelines around how we think about pricing and packaging, which makes it easier for any new feature. And it's always helpful to start thinking about what we charge and how do we monetize features as we start building them out. I think more companies are following this, but still there's a lot of room for improvement on that. So it starts from there. Whenever we start to talk to users to try and do some discovery around new features and gaining more confidence, we also talk and think about pricing and monetization. It starts really from there, but we also have a few general guidelines and it's not always a binary framework, but it's very helpful around, do we give a taste of most of the features to all users or do we want to just restrict certain features to certain tiers? So that's been a decision. We've generally been on the side of more what some of our leaders like to call a slice of cake approach. Where you get a slice of everything, all the layers, as opposed to just certain layers. And we want people to be able to experience that right from the free product. And we've also evolved our pricing to suit more the team use case while not alienating the individual use case. So earlier free plans were more restricted to just a single user. We made it multi-user. That's been a decision that a lot of teams In the past as well, I've seen a lot of back and forth about the benefits of potentially doing that. I think one of the main concerns that have come up has been around cannibalizing potentially team upgrades and not— but I think it's been very beneficial. And yeah, we've also been thinking about how do we— again, it goes back to the slice of cake model where how do we give a taste of all our features without giving away too much for free? So that's been a common theme and we've also been increasingly experimenting and thinking about trials and do we allow credit card trials, no credit card trials, and weighing the pros and cons of each one. So that's how we've been thinking about it.

I think that's really instructive. Would you say that the guidelines that you're referencing, are these more like pricing principles that the organization kind of has committed to?

Wouldn't say just pricing, but packaging in general. And in terms of pricing as well, it's helpful to think about, do we want to be a luxury product or towards the higher end of the market or the lower end? And do we want to play the longer game and attract more users or optimize for ARR right now? And each one shapes the decisions. So that's what I meant with general guidelines and helps to align where in the market. And do we want to index too much on the competition and be reactionary? So these are some things that we think about and use as guidelines.

I think that that is a really important point. And I think the reason I think that is because when you don't have those guidelines and/or principles in place, it's easy for pricing and packaging to evolve in a way that is scattershot or emotional or sort of misinformed from sort of like the market's willingness to pay. I think it's quite impressive that you guys have adopted that. I don't know how commonplace it is. I've certainly been at businesses where it's not common, certainly in my first startup. We were, we didn't have anywhere near that type of maturity. And it's something that we have focused on a lot at Schematic is do we have principles associated with our own pricing? We do. For us, it's, it's kind of the kind of 3 simple ideas. It's simple is better. Even the smallest companies should be able to afford our product. And we shouldn't get paid more until our customers are getting paid more, which informs a lot of how we think about our own price metric and value metric. So I love that you all are doing that. And I think it's, again, I do think it's rare. I wonder what you think. Do you think that that's really commonplace that companies have adopted pricing principles?

For most part, yes, but I don't think usually it's been agreed upon or codified. So there's not a common understanding. It ends up being something similar, but you're right. I have seen instances where every feature you introduce, or every time you think about pricing, it's a whole new discussion and starting from scratch, which I think is not very helpful and also doesn't— yeah. So there's a lot of mistakes and room for mistakes by not having that. And also frankly ends up with a lot of wasted time, I feel. So I didn't realize it was not as common as I thought it would be.

Maybe it's becoming more common, hopefully so. Let's talk a little bit about— I want to see if we can help listeners sort of understand how you have learned to approach pricing and packaging, both through sort of like an organizational lens, a systems lens, and then maybe some more discrete use cases, like how you think through, you know, how do we handle when a user has exceeded a limit, things like that. So let's start on the organizational side. How, if pricing and packaging is rolling to monetization and monetization is rolling to product, how does Otter as a broader company operate on pricing and packaging together from an organizational standpoint? Are you having quarterly meetings? Are you having monthly meetings? Like, give us a sense of how the sausage is made from the stem.

I don't think we have any set meetings. It's more, we tend to try and check in every half or twice every year, at least in the time and trying to make this a bit more frequent. But sometimes you don't have a lot changing and you're not shipping or, you know, so you don't have to meet as often, but roughly kept to twice a year. Or if there's a big launch, try and have discussions closer to that or just prior to that. And usually I've approached it starting with the principles, of course, and making sure everyone's on board aligned with the principles and then diving more into the specifics, thinking, looking at things like our current usage. Just to give you an example, if you're thinking about adding a particular feature to our existing plans, or do we create a new plan, we start by looking at the different models that are— but say you aligned on that— looking into usage, the market, then looking at potentially the cannibalization that it can drive. How do you maintain differentiation whenever you add a feature to a plan between plans? And also not cannibalizing the sales side of things, the sales contracts, how do you address that, have been some of the things that we've tried to pay close attention to and think about as we introduce any feature. Again, it changes from feature to feature. So I found this really helpful because sometimes, uh, people end up indexing too much on just the market, uh, or just too much on the internal usage and looking at our current consumption. And the last piece, of course, this should have been the first piece, is also like constantly talking to customers and understanding, identifying, and aligning on the right kind of customers that you want to go after and making sure it fits their bill. So, um, I know there was a few different things and, uh, hopefully that gives you a sense.

But it's, you know, one thing that I think is— tell me if this is true, if I'm picking up that like cannibalization is something that you all have to consider, you know, really thoughtfully because you're both product-led and sales-led. Is that a fair playback?

It is, but also even within the different plans that within product-led, the self-serve side of the business, you might end up nuking the sales of a higher tier product if you introduce something which is, say you remove the limits from a particular feature, which was the most differentiating feature and majority of people users were upgrading or picking the higher tier plan for that. So just keeping an eye on that.

So, I see this is— that example is one of the reasons I think that pricing and packaging— well, let me say this again. That example where maybe you go and you change what feature— a feature's limit in a specific package. Well, a sales rep could be working an enterprise deal and he or she may selling a tier that reflects kind of the packaging before you made that change, that could end up creating issue for that seller in the deal. And I think that reflects one of the kind of challenges that growth and monetization people have, which is how do we consistently evolve pricing and packaging as our product constantly gets more valuable, do so in the context of their deals in flight that might be taking 2, 3, 6, 9 months, and we have to kind of be really cognizant of that dynamic.

I think so. Yeah. So again, comes back to making sure all the different organizations, especially the ones that are going to be impacted, are closely aligned or at least informed. And yeah, every time you start thinking about a new feature that you're adding or building, even you have those conversations with users, but also internally. To say this is how we are considering monetizing it and just thinking about all the implications to your existing, uh, you know, sales deals and what's in the pipeline so that can help inform, or that can help inform the option we go with as well.

Yeah, yeah. Let's, let's shift to a system. From a systems perspective, pricing and packaging is often governed in a software company by how it's implemented in code, as well as downstream business tools that it may interact with. I mean, potentially a billing system, potentially a CRM or a quoting tool, or even an ERP, depending on the scale of the business. Can you talk a little bit about, you know, kind of how you've implemented and architected pricing from a systems perspective? How does it work? What are the key tools? What's the infra? Walk us through that.

Yeah. And again, things have been changing and we're all always looking to change and thinking about more longer-term solutions, but so far. We've had been using Stripe, especially on the product-led side of things, more Stripe. And then we have our own in-house system for entitlements and making sure, yeah, just the metering side of things and all the plans and et cetera as well. So that's, yeah. And I've seen this with other places as well, where you end up it can become a bit unmanageable if you don't think about it. You start out with one product, then it grows with the success of the business. And sometimes you're just optimizing for speed and making sure and you're making some potentially bad decisions and accumulating tech debt. So hasn't been as much of a challenge, but that's been one of the things that we've tried to keep in mind. And that's common with an in-house system to maintain all these, right? So.

Talk a little bit about—

I try to keep it pretty simple.

For people who are listening who don't know what you mean by entitlements, what do you mean by that?

So what features do certain plans get access to and how much is the metering part? Is, say for example, for Otter, it might be minutes. How many minutes do you get access to or how many inputs does a person get access to in a given month and what other features? Does a particular plan, a professional or a business plan, what do you get access to?

And so basically you guys are using Stripe for billing and invoicing. Well, actually, let me separate Stripe for invoicing. Are you also using Stripe for billing and subscription management?

Not for subscription. Partially, yes, but we also, yeah. So we also have an extension of that, which is in-house to have layers on top for the subscription, because there's some nuances which the underlying system doesn't provide. So we have layers on top to like—

Okay. So, so, and I'm trying to paint a picture for builders out there who need to go build monetization. You have your application, you have Stripe, and in between you've built effectively middleware, which is like an entitlement system, which on top of that layer is like a form of subscription management. And both of those systems speak to the application and to Stripe.

That's right. Yeah. And simplifying that a lot, and maybe that's too reductionist, is potentially like a database, a few database tables or a warehouse, which manages different things around subscriptions, what features people get access to at a user level and at a subscription level, and then also maintaining a separate table, if you will, for plans and such, which then you have a middleware talking using that and talking to Stripe to make sure both are in sync.

Yep. And is there anything from a downstream of the application perspective besides Stripe, like a contract product or a quoting product or even an ERP, or is that, that's well in the future for where the business is today?

I think that's more in the future. We're starting to think about it, but for now it's more, yeah, those are not things we consider. We do use some of the other systems. Maybe for taxes, et cetera, which are third party, which integrates with Stripe.

Makes sense. Awesome. Okay. So that's from a systems perspective. And so maybe one more question on the system. So like you want to go make changes to pricing and packaging. Does engineering have to be involved in those changes?

Yeah. So the way we are set up, we would need engineering help in Maybe not with the pricing, but at least the packaging. If you're changing, say, limits, etc., or adding a new feature, we do need that to be able to— if you're introducing a new feature to a plan, we would need, yeah, pricing. We've tried to make it a bit more easier for folks, but I think we're soon getting to that stage where we would be able to do pricing changes without having any engineering support., but it's somewhere in the middle right now.

Yeah, makes sense. Okay, so I'm curious like how this ends up working like at a tactical level. And so let's, let's kind of try to look at that from like a limits perspective. A user hits a limit. How do you think about handling that today?

So again, there's a few different ways we do handle and I've seen handle across different companies. You do have soft limits, hard limits. You have a whole set of things that you can kick off when a user hits a limit. And also you can use, again, the profile of the user itself to say, should we put them in touch with a salesperson instead of allowing them to upgrade in product? So these are some decisions that you have and you can take. Usually it's either a soft paywall or a hard paywall, with soft paywall being Maybe it's as simple as a banner or a modal that shows up asking the user to upgrade, but the user can dismiss and can use it, but within certain limits. Maybe it's 5% of what the current limits are so that it doesn't completely stop the user from continuing to use the product when they hit the limit, but it's not like they can continue and just stay on the plan forever. And then, but for most part, it's more harder limits. Where they have to upgrade to go ahead and continue or wait for the next month. There's a few other decisions, or I've seen this being architected as well. You can either upgrade, you can also, some, you can with workspace expansions as well, you can have like a common pool of, so for example, it could be minutes that are shared and you can add one more user to your current plan workspace and then you get more. So these are some decisions, but usually it's been hard paywalls.

And so in, in the instance when maybe the limit is less soft, more hard, how do you guys approach sort of that opportunity from an expansion perspective? Are you, are you building UI to drive the expansion based on that path? Talk us through how you've approached that.

So There's again, if it's, uh, one thing I've seen and we have this, but now it's more around getting people to upgrade. We do have other areas in the product which pushes people towards expanding and sending invites and being able to discover workspaces and join them if you're in the same domain. There are things you could potentially do where when you do hit the paywall, it's more around having the option, but I've seen that perform poorly when you're trying to do two things. One is it's easier to get people to upgrade as opposed to giving them an option to say upgrade or try and invite this one other person. So we've optimized more towards the former where it's more of a clear-cut one option upgrade. And we let the expansions be handled by some of the other areas. Like say other areas, some of the invite flows, some of the sharing flows, the virality-focused flows focus on the expansions itself. Yeah, I don't know if that quite covered it, but Yeah, makes sense.

I want to go back for a second because it's not often that I get to talk to someone who's deeply familiar with entitlements and how they work. I imagine you've seen entitlement systems across all the companies that you've been a part of.

For most part, yes.

How do you kind of try to educate the audience here a little bit? Like, what should people know about entitlements and the potential ways to think about building these types of systems?

It's always tricky as we think about entitlements, and I'm sure there are much better ways to handle it, but always helps to keep the future in mind. Of course, you don't know, uh, where you're going to be sometimes even a year from now. It's always good to have that vision and build towards that and try and make it a little bit more flexible and not rush into being very hacky, for example. And also it helps to think about From a user perspective, how easy do you want— again, also ties to the company, and are you targeting enterprises, etc., which can be a completely different way to manage, or a smaller business or a smaller team where you don't need as many controls or as nuanced controls to manage the entitlements. But it's always helpful to think about from a user or an admin perspective how you want them to be able to add certain features or get access to certain features and you want to support different roles with different access levels. For example, there could be a viewer-centric role, which if you think about Slack, maybe not the best example, but maybe there's a role that only allows users to view messages and not write any messages at all. So how do you think about managing those internally and making it easier? And how do you want to support multiple roles? Do you want to be able to have everyone with the same role access to the same entitlements? Do you want to be able to give different entitlements to different people within a particular workspace? Those are some things to think about. And there are simplifying decisions and assumptions I've seen work fairly well, where you can just choose to support one role within a workspace where everyone's a paid role and they get access to everything and makes it much easier to manage the entitlements. So these are some of the things to keep in mind.

I think that's really excellent. You know what, I think one of the things that I've— so the last company I was at, we really struggled to evolve pricing and packaging because of the way entitlements had been implemented in our product. And, um, and effectively what we had done is we had hardcoded the entitlement into the application code and then tried to tie it closely to a plan ID in the billing system, which for us was Stripe. Interestingly, we were using Stripe for our self-serve customers. We were using, I think it was Maxio for our sales-led customers. So you can imagine now like two billing systems plus hard-coded entitlements, like it gets quite messy, but it led me to get really interested in entitlements, obviously. And I've been looking for a way to kind of categorize and codify sort of how companies approach this. And I wonder if you think this feels correct. I mean, it feels like. Companies can either go hardcode the entitlement, as we did at that company. Companies can sort of take a more database-driven approach, which it sounds like what you guys are doing, where there are rules stored in the database. Um, companies could kind of take like a middleware approach, um, where there's a system that's trying to kind of own entitlements between the application and the downstream business systems. You could maybe kind of consider feature flags as an approach to entitlements. You could kind of consider API services that you might outsource to, or you could kind of consider like almost like token-based entitlements if you were trying to do entitlements through like an auth provider. Do you feel like those describe how most companies might consider entitlements and approach entitlements, or is there anything missing in that frame?

I think that, that's a good range and that does cover most of it, although majority of the ones I've seen have been more the first couple hardcoded, which always leads to a whole slew of problems. It does make it easier to start with and get things going quick, but at some point you hit that wall where you, it's not going to scale.

Yeah, it's super interesting. Well, we've never done like a fully dedicated episode to entitlements and this is maybe the closest one we've done. So maybe. Maybe we've got, you know, part 2 at some point where you and I go deep on this for people.

Chat more.

You know, there's another question. I know we're getting close to time, but I was really interested to ask you this question. There's a lot of commentary online, especially from billing vendors and pricing consultants that startups have to be incredibly considered around their costs. Now that we live in this world of AI. And I would love for you to reflect on the extent to which that claim is true, given how quickly costs are coming down. Just any riff or personal experience you would share on how you think about costs in the age of AI and how you think startups should think about costs in the age of AI.

Again, I'm evolving my thinking around this because costs are going down, to your point, almost exponentially, especially if you go one generation back with some of the models. It's about 99% cheaper per token. So keeping those in mind and trying to evolve with that, that's been a journey. But generally, yes. And that's been a key aspect that sometimes I think people tend to miss out, or I've seen smaller companies miss out on paying close attention to the costs and keeping a handle on that. I think there's been a whole industry shift, especially the last couple of years with the economy, the shift in the economy to, from being more growth, growth, growth to at all costs to being very cost aware and trying to move more towards profitability. So it's gotten much better. Now across the board. And that's something I keep in— like, of course, we keep in mind as well, paying close attention, trying to balance the different kinds of things you need AI models for and trying to— you don't need the best model for every feature. For example, if you have a few different features or parts of the model being served or parts of the product being served by different models, you can look to spread the cost and also like lower your overall cost, your average cost by depending on certain models, maybe going a generation back and not always using the best in class. So that's been one of the approaches, or maybe even considering an inbuilt instance or like some of the free open source models out there and being able to use them. So those are things that we've tried to keep in mind, but of course, always being careful about modeling out what it means. Given the current costs, but having some scenarios around just looking at historical data, like you mentioned, the costs are continuing to go down in a world where we assume that's going to be the case, projecting a bit further into the future, but not being too optimistic is how I've been thinking about it and we've been thinking about it internally.

That's great. I mean, I love speaking to you about all of this. It's such a rich and broad surface area. Encompasses product, it encompasses pricing, it encompasses data analytics, it encompasses how you communicate across an organization and build alignment. There's so much that is so interesting to cover, especially in a world where software businesses are going multi-product, they're going hybrid billing, they're going multi-GDM, multiple good markets, they're dealing with AI as an obvious and massive inflection. So thank you for this time. The question I love to ask at the end of these conversations is, is there a moment in your career, like a very specific moment that you look back on and say, that was an inflection for me personally?

Again, a few come to my mind, but I think just going back to the oldest I can remember is early on when I joined Adobe. And I was really interested in being part of the go-to-market and working on more of the business side of things. And I joined to focus on machine learning and a data scientist focused on fraud prevention models and such. But we had a couple of teammates leave and I got to start focusing more on just the run the business side of things and also helping focus on growth. And there's a 6-month to a year period where It was a very busy period, but I got to absorb and learn a lot of things, especially across a business and across a business at that scale, which I've still found the lessons I learned there and how people operate and some amazing leaders there. So that's one I look back and reflect. But then after that as well, as I mentioned, my time at Loom and also more recently Otter would be other moments I look back at. Otter has been amazing so far. Looking forward to it.

You've worked for some incredible companies. Thank you so much again for this time. People can find you on LinkedIn and they can learn more about Otter at otter.ai.

Thank you, Fynn Glover. I really appreciate you having me. It was a pleasure.