SaaS Stories
SaaS Stories is my not-so-secret quest to learn what it truly takes to succeed in the world of SaaS—and I’m inviting you along for the ride! I have the pleasure of sitting down with brilliant minds and industry trailblazers to explore their journeys, uncovering the secrets behind their growth, the gaps they spotted in the market, and what really drives them.
It’s not all smooth sailing—there are challenges, unexpected turns, and moments of reflection where they share what they’d love to change about their journey. Think of it as a candid, insider’s look into the world of SaaS, with just the right amount of curiosity, empathy, and wit.
Join me as I dive deep, selfishly soak up all the insights, and hopefully share a little inspiration with you along the way—one SaaS story at a time.
SaaS Stories
Feature Flags and Mastering Dynamic Pricing in SaaS
Understanding effective pricing strategies is crucial for SaaS companies to achieve long-term growth and success. Fynn Glover shares insights on the importance of ongoing evaluation of pricing models, the concept of "willingness to pay," and how feature flagging can enhance monetization.
Discussion Points:
• Fynn's journey into SaaS and founding Schematic
• The significance of establishing pricing strategies early
• Engaging customers through willingness to pay exercises
• Common pitfalls in SaaS pricing and packaging
• The role of feature flagging in revenue growth
• Advice for enterprise-level SaaS companies
• Importance of cross-departmental collaboration in pricing strategies
Welcome everybody to another episode of SaaS Stories for 2025. Today I'm joined by Finn Glover from Schematic. Welcome Finn.
Speaker 2:Thank you. Thank you for having me.
Speaker 1:And all the way from Colorado. I was just saying how jealous I was with the snow that you're getting there. Are you much of a skier?
Speaker 2:I am. I do love to ski.
Speaker 1:Amazing, we should definitely swap places. Everyone's surfing here. I'm dreaming of skiing. Skier I am. I do love to ski. Amazing, we should definitely swap places. Everyone's surfing here. I'm dreaming of skiing, though, but welcome to the show. I'd love to hear your story, and it all starts with the story of your early career experiences and how that helped you transition into the world of SaaS and tech, and really what made you found Schematic. What was the big idea that you had the gap in the market that you saw? How did it all come about?
Speaker 2:It's a good question. I guess it depends on how far we want to go back, but I All the way.
Speaker 2:All the way. I was born in I grew up in Tennessee I, for most of my early life, really wanted to play soccer as a profession and took that through college and a little bit post-college and it was sort of kind of in a year after school or so that I worked for a startup and then I worked for a hedge fund and they were kind of my two first real experiences with capitalism, but from two very different perspectives. And you know, I think it sort of gave me the bug. It made me want to start companies and that led to me starting my first company in 2012, which at the time was a location-based application to find great places to go surfing or skiing or trail running, and that grew into really a media business over the next few years where we were serving outdoor apparel brands and destinations and creating content for them. And about four or five years in we saw an opportunity to productize portions of our publishing stack and start selling content, marketing software, to these e-commerce direct to consumer brands, and that was sort of really the beginning for me of like moving not just into entrepreneurship but into software, and so I ended up raising money around that company. We grew that company for a few years it um, it never got too big and maxed about 30 people, but we ended up being acquired in late 2020 by an email marketing company um, and then I.
Speaker 2:I stayed at that company for about six months before joining a totally different world, a cybersecurity company that had just raised its Series C, and I joined that company largely because I had gotten to know the CEO and saw an opportunity to kind of learn a different stage of running startups. I had known zero to one, zero to two, this was going to be series C plus, and so I did that for two years, wore a lot of different hats Pricing and packaging was one of the many hats that I wore, and I can talk about that at length, obviously, but that's what led to the founding of Schematic, and I founded Schematic with several people that I had worked with across both my first startup and the company, the cybersecurity company I mentioned. We started the company about 18 months ago.
Speaker 1:Amazing. So much to unpack there. You've had a world of experience in so many different areas. I guess what you know to a lot of the founders listening to this podcast right now and really just with a focus, that you grew that first company to 30 people. What were your first hires and would you change that now?
Speaker 2:And would you change that now? Oh, I made many, many, many mistakes in that business, and hiring was probably, I think, pricing was my biggest mistake in that company.
Speaker 2:I think, pricing actually constrained that business more than just about any other mistake that I made. And when I say pricing it wasn't like price optimization, it was like a fundamental misunderstanding of the market's willingness to pay and kind of how they would think through kind of value metrics or price metrics and things of that nature. Additionally, we had pivoted the business from a media business, which was really kind of a services content business, into a software business, and that pivot for any founder listening's just a very difficult pivot to make. I think on the hiring side the hardest hire for me was always a technical leader because you know at the time I've become a little bit more technical as I've gotten older, but at the time I was not technical, so it was very difficult for me to vet technical co-founder types. And then secondarily, like I was, I was always driving sales, so like to transition out of founder driven selling and into a sales leader was a real challenge and kind of I tripped on that one at least twice.
Speaker 1:Yeah, yeah, and kind of, I tripped on that one at least twice. Yeah, yeah, let's go deep into the pricing mistake that you refer to. Like, what if you could go back now? What would you do differently? And, with that in mind, how should founders think about pricing and packaging?
Speaker 2:So I think zero to one, and by zero to one I just mean like maybe you are in the pursuit of product market fit. You've not yet found real product market fit. I think that there's an incredibly simple exercise to use regularly and it's an exercise that I wish I had had in my first company and that exercise is simply willingness to pay as an exercise or as a conversation with prospects and customers. So effectively, the way to think about it is it's primary research with the target buyer and these conversations are just incredibly enlightening and illuminating about your value to the market. And the way I run these conversations today for my current company is usually across eight different questions, takes me 30 to 45 minutes with a prospect or a customer. I've always asked for permission to have these conversations with the prospect or customer so that they're coming in sort of cognizant that they're about to have a pretty meaningful, exploratory, objective conversation about our value. And I can go into what those eight questions are, but fundamentally, what's so important about these exercises is that you remove founder charisma, sell and you structure these conversations to give the prospect or the customer a really honest venue for talking about your value and associating price with your value.
Speaker 2:It's really a fascinating exercise. It's incredibly powerful and it's useful, at least in four very distinct scenarios. The first is maybe you validated a problem. You've kind of created solution a maybe you've got prototypes or mocks. You want to see if the way you're actually coming about solving the problem is commercializable. That's kind of scenario.
Speaker 2:Oneenario two is maybe you've won some design partners but you don't know what to charge. You don't know what the value is and they're willing to give you feedback on that. Scenario three is you're six, 12, 18 months into a successful customer engagement and you want to come back and learn about how they perceive your value, having gotten success from the product. And then the fourth is when you've really achieved product market fit and you've got a real cohort of customers and you want to learn from that cohort how your pricing and packaging should evolve, given it is probably assumed that your product has evolved quite a bit since winning those early customers right, okay, so out of those eight questions you mentioned, what is one that you find surprises you most when you hear the answer?
Speaker 1:And sorry about my ignorance, but what is founder charisma?
Speaker 2:Well, it's really easy, for I mean, a founder is always selling.
Speaker 2:So if a founder gets, if a founder requests a willingness to pay a conversation with a customer or a prospect and then gets on the phone or the zoom and like sells yeah, they can very easily bias that prospect or that customer and then they would extract biased information that pretty much could inflate sort of how they think about their own value or pricing or packaging, and I think that's to be avoided because early stages, zero to one, this is really about. Am I truly tapping into something honest between my value and the market's perception of my value?
Speaker 1:Yeah.
Speaker 2:So that's what I mean about founder charisma, the questions. I mean the questions are like they're so fun when they are mixed together. I mean the questions are like they're so fun when they are mixed together. But one question that I really really enjoy is to understand your relative value. And what that means is, like, how valuable is my product relative to other tools you are already paying for, sort of in a similar or adjacent category? And so, for example, if a customer is paying $100,000 a year to Salesforce and you're building a tool and the sales stack and they value your product at 50% of Salesforce, what they're kind of implying is that they think that you're worth 50 grand.
Speaker 2:Well, if you associate that question with several other questions, you start to be able to walk away with a proxy for how the market will kind of think about your pricing and your packaging. Where the rubber meets the road from a question perspective is, you know, when you start to kind of ask them like their maximum willingness to pay. And there are two ways to kind of get to that question. One is very open-ended, you know, and it's you know now that you've seen a demo, now you've considered this, you know what's the maximum that you would be willing to pay for this on a monthly or annual basis and you let them sit with that and it can be silent and awkward and they can deflect and they can defer um, probably say something lower than they're willing to pay just to try and get a discount on it.
Speaker 2:And that is true that you need to have prepped them by kind of making them understand. You need to have made them feel safe that they are not negotiating against themselves. That's an important sort of primer. The other way to ask that question is if this product were priced at X a month or Y a month and you insert the price, how likely? You know which of the following best describes your intent to purchase. And then it's four choices, and choice A is high intent to purchase would buy immediately, have sole authority and discretion to do so. That means your price is too low right.
Speaker 2:Or it means you've, like you really are probably kind of tapping into maybe kind of a viable market, and then from there the answers become a little bit less responsive. It kind of goes into I would never buy it at this price, or I would have to talk to my boss about it, or things like that. This price, or I would have to talk to my boss about it, or things like that, and what you're really trying to do is understand the extent to which your pricing is optimized for what you need to achieve, and typically startups need to achieve adoption. So your question is like is this priced for adoption?
Speaker 1:yeah, yeah, okay. So the process is maybe speak to try and get a market fit. Speak to those buyers, see where potentially you could be pricing Anything else founders need to be mindful of after that.
Speaker 2:As it relates to pricing.
Speaker 1:Yes.
Speaker 2:I think what I would say is just that exercise is like, a very actionable exercise, it should be run periodically. And I think, given it should be run periodically, sort of like the maybe this is obvious, maybe it isn't, but like pricing is always evolving.
Speaker 2:And so you're never going to stop doing this type of thing, yeah, yeah. So you need to view this as not a one and done. Willingness to pay exercise it's sort of not the idea. The idea is I'm going to build a practice and a muscle around understanding my market's willingness to pay and I'm going to check back in on that with real discipline and real. You know I'm going to be very methodical about this, yeah.
Speaker 1:I agree. I think this is where a lot of companies go wrong. They kind of sit with the existing prices for years and years and then they have a realization that oh, we didn't adjust for inflation. And then they put it right up and there's a lot of controversy from their customers and they're not quite happy. What are some of the biggest pitfalls you've seen SaaS companies make when it comes to pricing architecture?
Speaker 2:There are real problems from an architectural perspective.
Speaker 2:Maybe just to piggyback off of one last idea, most, let's say, software startups are constantly investing in their product software startups are constantly investing in their product, and so one would assume, therefore, the product is like getting more valuable every month, and so I think what is true of you know, my own experience as a founder is that it's really easy not to align your product roadmap with pricing and packaging roadmap, but when you do have the right discipline around it, it's a really, really kind of good thing to do, because every release is an opportunity to evolve packaging, evolve pricing, make more money, but also, like it really forces you to consider are the product investments we're making going to drive commercial value for the business, going to drive enterprise value for the business? And so the alignment of product roadmap with pricing roadmap to me feels like an area that many companies have an opportunity to improve against to improve against Architecturally.
Speaker 2:Okay. So this is a big media subject. So where should I start here? You mentioned that companies get to a point where they want to change pricing and it's been a couple of years and then it's really horrible. It's not just hard because of the strategic question what should the price be? Or the customer comms question how should we communicate this change to pricing that's coming out of the blue? It's also hard because often software companies implement pricing into their applications in ways that make it very difficult for them to change pricing over over time. And typically what happens a very common pattern is engineering will hard code pricing into their application. In other words, like what's happening is the billing state of the customer. What a customer should be charged is stored in the application. Well, why does this matter? Well, when the business wants to change pricing.
Speaker 2:Now, a change anywhere is a change everywhere including in the code, and so you have to change price in the billing system, you have to change pricing in the CRM, you also have to change pricing in the application. That requires dev resources, that requires pulling developers off of their current sprint, which is focused on the current, the core product, and into a billing initiative or a pricing initiative, and you can sort of see this is like a compounding sort of tax on a business's agility.
Speaker 1:Yeah, I can see how that can go haywire and it's more complicated than people think, I think. Another thing I've seen is you know, there's a lot of talk about pricing by usage or features that are getting used, which I think I mean I'm not a developer, but it sounds like that could get quite complicated quite quickly. So what are some tips on? Some tips on avoiding that maintenance nightmare?
Speaker 2:So the rise of usage-based billing has driven a ton of complexity into SaaS pricing, and part of the reason it's complex is because you know the question is how should we meter against usage events? Can we support, you know, what type of volume and scale are we talking about? How should we aggregate those events to inform what we charge the customer? These are all questions that typically engineers are tasked with answering and then building against, and so you know this is why you've seen a lot of usage-based billing platforms get founded by entrepreneurs and get funded by venture capitalists. This is why you've seen Stripe become much better at metering than they were even two years ago, because it's clearly it's clearly sort of a pricing model that has a ton of staying power.
Speaker 2:It's not going away and there are going to be lots of flavors of usage based, and I think the thing for all developers and startups to probably internalize is that there's like no point to go build metering in-house. It's it's it's a problem that well-funded companies are spending literally all day, every day, solving for you so that you can go focus on your core product.
Speaker 1:And how can you tap into that Like you're a startup?
Speaker 2:Like how can you find those tools? Is that? Is that what you're saying?
Speaker 1:Yeah, yeah, kind of. Maybe, you know, get the learnings from the bigger companies, I suppose, and, and you know, are there any, any shortcuts for them to take, rather than have to figure it out on their own?
Speaker 2:Yeah, you know, it's funny that you say that. So when we started Schematic, we we must've interviewed a hundred CTOs and engineering managers and people who had become billing engineers, and you know. So what's so interesting about it is that there's this sentiment amongst sort of that group of people that I the sentiment is, I feel like I'm recreating the wheel every time we work on billing and pricing at my company. And you know, the more I dug into that, the more it started to kind of become apparent to me that engineers do not want to go work on pricing and billing because it's not core application, it's not core innovation, and because I wasn't trained to go know how to do billing and metering and pricing like these implementations, I don't know how to do them. Now I have to go figure it out.
Speaker 2:What if I find the wrong information? What if I implement in the wrong way? What if this becomes a catch-22 and I get caught here and I'm mired in another billing project in two months? And so I think what startups have an opportunity to do is, you know, pay a little bit of attention to kind of what's happening in the billing and feature management and pricing space and look at what the vendors are producing, because they're producing a ton of information on how to not reinvent the wheel and how to set up pricing and pricing implementations that can scale. I think you know we have a very specific perspective and thesis on this that I'm happy to get into. But I think that's sort of the high level sort of advice that I would give to people.
Speaker 1:Okay, taking a step back and just going into feature flagging, can you explain what feature flagging is and how can it be leveraged for revenue growth?
Speaker 2:Good question Feature flagging. So feature flags for people who don't know them are kind of if, then statements in a code base, um, you know, for example, like if this customer is, you know, if this is customer x, they should have feature y. Therefore it should be turned on, because you're often kind of on or off logic statements that based on usage so it can be.
Speaker 2:You know, kind of the history of feature flagging is that you know it's been done for a long time, but as a category of vendors it really was kind of created about 11 years ago by a company called LaunchDarkly. And the way, kind of the thesis behind feature flagging is that you would deploy and roll out a feature to a test group so that you could test the feature with a small subset of customers and then you could remove the flag once the feature were stable. So very much sort of a core set of tooling for sort of the DevOps movement of the 2010s. And you know a number of companies were founded in that time. Some of them became very big. Launchdarkly is probably the most famous and the dominant player. But the whole idea, right, is like deploy a feature, roll it out, remove the feature because you don't want a lot of features in your code base, because that can create a bunch of hygiene issues.
Speaker 2:Well, what's interesting is what happens in practice. And what happens in practice is a little bit different from the theory. And the theory is always remove flags because of the hygiene issue, but in practice companies everywhere are leaving flags in the code base all the time, basically as like feature gates or entitlement gates or long-lived flags, to shepherd access to an application based on, to your point, what the customer bought, what is in the customer's contract or what is in the customer's subscription, what is in the customer's contract or what is in the customer subscription. And so that use case is not very well served by most of the sort of incumbent feature flagging providers. And the reason it's not well served is because it requires them to extend into integrations with downstream business tools like CRMs and CPQ tools and billing systems, and that's the sales stack and that's the finance stack, that's not the DevOps stack. So it pulls those tools into sort of other areas of the business that are just not native to who they have always served.
Speaker 2:So to your question how does it involve monetization? When you imagine extending feature flags from just an on-off switch into this is what a customer should have access to, or this is how much usage a customer should be entitled to, whether that be an API call or a seat, and it's integrated with the billing system and the CRM, suddenly the business can be very agile because the engineer can put a flag down, billing context, contract context can be behind that flag, the product user or the customer success manager can make a change to what a customer has access to without ever getting engineering involved, and that change that I just described is very local and micro. But now you could imagine doing this at scale with like full-scale pricing and packaging changes, trials, overrides, you know, there's kind of a long list of packaging and pricing operations that companies would then be capable of deploying more regularly.
Speaker 1:Right, it's very interesting. So am I right in thinking that you know this is kind of? It gets tested out to maybe just a few users to see is this something people want and therefore let's get it out to the majority?
Speaker 2:That's a good way to think about traditional feature flagging. And you know, what we're positing to the world is that traditional feature flagging shouldn't stop at the deployment and roll out of a feature. It should extend into how features are packaged and monetized and priced and gated and things of that nature.
Speaker 1:Yeah, yeah, as a user on the customer side, I've seen this happen with a bit of the software that I'm using and it's always in beta and you just kind of notice it and you go oh, I wonder how long that's there for.
Speaker 2:Exactly.
Speaker 1:But most of it is pretty cool to play around with, I think, as long as customers realize that's what it is and don't expect it to work perfectly as well, because there's definitely some glitches. Knowing what I know, I don't tend to be too upset about that. What are some common mistakes companies make when implementing feature flags? You mentioned a few of them already, but maybe some others that founders and developers don't seem to be aware of when they first decide to do this.
Speaker 2:You know that's a good question. I'm not a developer myself and so I can't speak to that question very intimately. But I think one of the most common things I hear is sort of around flag hygiene. In other words, zombie flags that have been left in the code and I don't know what. You know what that flag is or what it should be. There's bad nomenclature. I have to go kind of dig to figure out, like, what's going on with this flag. It's impacting a customer. Maybe there's a lot of pressure around it. That hygiene issue is very real and it's it's something I've heard quite a bit from people that we've talked to. You know, and I think that in the world that we are trying to bring to life, you know, there's just maybe an opportunity for re-imagining, and that's re-imagining feature flagging as not just a DevOps tool but a tool for the entire business.
Speaker 1:Yeah, that's a good way to look at it. Coming back to pricing strategies, we mentioned how they disrupt engineering teams and development teams. Do you have any kind of tips on how founders can evolve their pricing strategies over time with inflation in mind, and all of that without disrupting the engineering teams? Is it something they have to get right at the beginning?
Speaker 2:Yeah, so it is an architectural question and you know this comes back to early decisions made, which is if we hard code pricing or entitlements into our application and tie them very closely to a plan ID in the billing system, we will have engineering involved in all future billing and pricing initiatives, and so how might one avoid that? Well, you can go build your own sort of middleware entitlement service or you can outsource to a company like Schematic, and there are other companies and startups that have a similar vision and that have similar offerings, and so I would encourage people to look at all the offerings. But I think if you're a CTO of an early stage company and you have been through growth stage before, you have seen and felt this problem and you know that it is very painful and complex. If the business is successful and it's very easy to implement kind of good architecture in the very beginning it's very trivial.
Speaker 2:Whereas if you sort of make some of these decisions that kind of early on that force you into the hard coding path, you're making a decision to incur very real, not only technical debt but commercial debt, and it is an engineering decision and it kind of starts with the engineer's experience set with monetization. If they've never seen any type of real scale before, they might not be familiar with the problem and they might think I can just pack a bunch of metadata into Stripe or you know. There's going to be a whole host of things that they can do that feel easy right now, but they end up being very, very problematic if the company becomes successful and goes down the route of multi-product or usage-based billing or hybrid billing or multiple go-to-market motions. You name it billing or hybrid billing or multiple go-to-market motions you name it.
Speaker 2:Yeah, I think for go-to-market founders or go-to-market CEOs, there is an opportunity to challenge engineering, to create more flexibility from a systems and architecture perspective, if you believe that pricing is a lever to be able to pull with agility.
Speaker 1:For sure you believe that pricing is a lever to be able to pull with agility. Sure, I think that's what I'm hoping to achieve today with this podcast is to get a lot of these founders thinking, because I don't think they kind of go into developing the product with pricing in mind. I think they're thinking about many other things and probably neglecting pricing a little bit. You mentioned CTOs. I think we've given some good advice to founders of startups and scale-ups, but I think enterprise level SaaS also has these problems. So, say, you're advising a CTO on a bit more of a bigger company, an enterprise level company. What are the top three things you tell them? What are the?
Speaker 2:top three things. You tell them what a question. Okay, I think, at enterprise, all of this starts to get very organizational, and it's how you build a pricing practice that's cross-functional, cross-functionally representative, and so let's just make it very tangible, let's say the business is 50 million in ARR and it's like many businesses of that size.
Speaker 2:It's got a product-led motion and a sales-led motion and probably some combination of seat and usage-based from product engineering, product marketing, sales, finance and that is meeting with some level of consistency. I would recommend at least quarterly, if not more frequently. And there are kind of two things that are going on. One is are we creating space for objective analysis of our pricing and packaging in terms of its impact on growth and impact on retention, impact on pipeline? And secondarily, if there are changes that we need to make, is engineering aware of those changes? Does engineering have the ability to support those changes? How long would it take for engineering to support those changes? If that's all up front and center, companies can be much better at pricing at that stage because inevitably they've probably got a bunch of systems that they would need to work through and be relatively proactive around if they were going to make a change.
Speaker 1:Yeah, if I could throw one story into the mix as well, this is actually a company that's, you know, I would consider an enterprise level company, and they recently changed their prices. I'm not going to name them. I still love them and work with them very much. But one place where they did go wrong is, I think, with the lack of training on the sales side. So I think, you know, they probably focused too much on the engineering and the development and that all rolled out pretty well. They kind of forgot to train the sales team in explaining what the new pricing model and titles does. So this is also a challenge that I would highlight.
Speaker 2:What a good point. Yeah, not enabling your reps to understand pricing and understand how to communicate value, especially in the context of a change, can make sort of the entire exercise in the change or not.
Speaker 1:It can be really damaging when you work with companies in schematic. Do you work across different departments? Do Do you offer advice to multiple teams? You know what are the key teams you need to. You find that you need to be in touch with during the onboarding process.
Speaker 2:We are typically selling into the engineering leader and occasionally there is a stakeholder and what I would sort of loosely describe as product. Sometimes that's the founder CEO of an early stage company, sometimes there's maybe a product leader in an early stage company. But we're selling to startups and we're typically selling into the engineering leader within startups, and if people want me to wax poetic on their pricing strategy, I'm always happy to jump on a call with them, but I don't get into consulting with them.
Speaker 1:That makes sense. Now a little bit about yourself. You've obviously gone through a few different companies. You've had success. You've now landed in pricing. If you could go back in time and change one thing, or give your younger self one bit of advice, what would that be?
Speaker 2:god, these you're gonna. You're gonna pull out my like inner freudian psychologist trying to figure out who I am.
Speaker 2:Um, let's see, you know what I? I think what I would say to myself is so I started a company when I was 23 years old, just after college, um, and I think that I would have benefited from from age 22 to age 27, trying to apprentice under another, more experienced entrepreneur. To apprentice under another more experienced entrepreneur. You learn a lot by going out on your own and it's a baptism by fire, but some of those lessons can be more lessons in survival rather than lessons in scale and best practice and how to price and how to sell and how to run an engineering team, and you know all these things that you can learn because they're out there, and so that's probably something that, if I could do it over again, I would consider, given where I am in the game now.
Speaker 1:I really agree with that I've heard a lot of people say this actually to younger people is just go and work for a startup, and I think most people are kind of wanting to work for the bigger brands and the bigger companies. They don't realize you're not going to learn as much there, and this is my own experience as well. My first job out of university, you know, nine months spent working in one of the bigger companies and I did the same thing every day until I got bored and I went to work for a startup and that just blew my mind. I was like what you want me to do? What?
Speaker 2:But it was such a good learning experience.
Speaker 2:Yeah, yeah, I agree. And if you, if you feel sort of like you've got really good direction on where you want to go, like if you want to be a founder, try to go work for a founder. If you want to be an engineering leader, go work for an engineering leader, I think. I think it's a way to, um, accelerate education, maybe even faster than starting on your own. I mean, everybody says starting on your own is like the fastest way to learn, but, um, I'm not sure it's always true absolutely, I think, a lot of young people as well.
Speaker 1:They don't quite know what they want to do, so experimenting in different places is probably the best way to figure that out yeah, I agree ben, thank you so much for being on the show, really love your story. I've learned a bunch of things about pricing. Um, I'm sure all the founders on this call as well are rethinking their pricing models and probably scheduling meetings with their engineering teams as we speak. So thank you for all the insights. Appreciate it.
Speaker 2:Thank you, Joanna. So it's so much fun to be here. Appreciate it very much.
