SaaS Scaling Secrets
The SaaS Scaling Secrets podcast reveals the strategies and insights behind scaling B2B SaaS companies to new heights. Dan Balcauski, founder of Product Tranquility, leads conversations with successful SaaS CEOs, exploring their challenges, triumphs, and the secrets that propelled their businesses to the next level.
SaaS Scaling Secrets
Kickstarting SaaS Pricing with Fynn Glover, CEO of Schematic
Dan Balcauski speaks with Fynn Glover, co-founder and CEO of Schematic, about his extensive journey from pursuing professional soccer to founding several successful companies, including Schematic. Fynn shares insights into the importance of flexible pricing and billing strategies in SaaS, highlighting the complex relationship between engineering and finance in implementing these strategies. They discuss the evolving landscape of usage-based pricing, the challenges of transitioning from vertical to horizontal markets, and the impact of AI on pricing in the software industry. Fynn also offers unconventional advice for SaaS founders on understanding and leveraging willingness to pay as a critical monetization component.
01:58 Meet Fynn Glover: From Soccer to Startups
03:33 RootsRated: The Birth of an Outdoor Content Platform
05:37 Pivoting to Content Marketing Software
08:07 Challenges of Scaling and Horizontal Expansion
11:36 The Birth of Schematic: Solving Pricing and Packaging
16:01 Understanding Entitlements and Organizational Challenges
22:15 Communication Gaps in Complex Organizations
23:37 Understanding Feature Access Terminology
23:59 Engineering and Finance Perspectives on Billing
25:25 Challenges in Software Categories and Pricing
32:52 The Complexity of Usage-Based Pricing
38:59 Monetization Strategies in the AI Era
Guest Bio
Fynn is the co-founder and CEO of Schematic, a platform that helps digital businesses monetize AI products. He also hosts the Monetizing SaaS podcast. Before Schematic, he founded RootsRated and Matcha, and later served as Chief of Staff and VP of Operations at Automox. He lives in Colorado with his wife and two young children.
Guest Links
https://schematichq.com/
fynn@schematichq.com
https://www.linkedin.com/company/schematichq/
https://www.linkedin.com/in/fynn-glover-b0410015/
https://x.com/fynnglover19
The trade is, a very likely profitable lifestyle business that you can run for a long time versus something that has to go be very big very quickly. Like speed is everything at this stage. Usage-based pricing, usage-based billing is. It has surprised me. The customer's super empowered to go buy whatever they want to solve, whatever problem they have. they're demanding of vendors, SA SaaS and AI vendors is flexibility. You let me buy how I want to buy you, let me, get, build and priced how I want to get billed and you let me buy what I want from your product.
dan-balcauski_1_05-21-2025_140920:Welcome to SaaS Scaling Secrets, the podcast that brings you the inside stories to the leaders of the best scale up. B2B SaaS companies. I'm your host, Dan Balcauski founder of Product Tranquility. Today I'm excited to speak with Fynn Glover. Fynn is the co-founder and CEO of Schematic, a platform that helps digital businesses implement and manage pricing Before schematic. He founder, roots rated and matcha acquired by Springbot, and served as Chief of Staff and VP of Operations at Automox He also hosts the wonderful Monetizing SaaS podcast. Let's dive in. Welcome, Fynn to SaaS Scaling Secrets.
fynn-_1_05-21-2025_130921:Thank you so much, Dan, for having me.
dan-balcauski_1_05-21-2025_140920:I'm really excited to talk to you today, Fynn again. And because, I relish these opportunities to have another person who is as passionate about the world of pricing as I am. We're few and far between, so when I fell find a fellow pricing nerd, I relish the opportunity to dive deep and hopefully allow some others to. Understand what the complexity is in this world and s schematics reason to for being, to help folks navigate that complexity from a infrastru pricing infrastructure layer. But before we get into schematic, I wanted to go back kind of early in your journey. You started your career pursuing soccer, if I'm not mistaken, and then founding roots rated in the outdoor industry. Tell us a little bit about your kinda early journey. What led you to start your first company?
fynn-_1_05-21-2025_130921:Yeah. Yeah. So I I had long wanted to be play pro soccer. That was a dream. I pursued it through college. I played semiprofessional afterward, but it was like late in college that, you're kind of asking, at the time, like the MLS was paying. Players like 30 grand a year. Like you're kind of starting to recognize, even if you take it all the way to the top in the us, like there's gonna be a, a point where you have to build a career. I had no. idea what I wanted to do, it was like, do you go be a lawyer? I grew up in Tennessee, was, I did not grow I did not grow up like. there was this world of startups and SaaS that was very unfamiliar to me until, about my senior year and college and. a soccer team that I was playing for was a guy who was like starting software companies in Chattanooga, Tennessee. And he said, have you ever thought about Thought And I was embarrassed to admit at the time I didn't even know what the word meant, but I kind of jumped in from there. I did an internship with a venture backed startup. I did a internship with a fund of funds, started to get really interested in. Business and startups in particular. And then I went on this sort of big road trip. I left the head, the fund of funds. I went on this big road trip to try to figure out what company to start, what I wanted to do. And at the time I was very passionate about outdoor recreation's, impact on people and society generally. And I was able to raise some money from a variety of outdoor industry companies and brands. go interview, thousands of college students about how they find and discover and engage with the outdoors. And through that journey, which also kind of, happened to take me about 20,000 miles around the US and Canada, I realized that it was exceptionally difficult at that time to find great places to go outdoors. This was 2011, and you'd be coming into a new town with, an early iPhone or a Blackberry. And you'd Google for where to go hiking in Denver or Portland or Austin, and your results at the time on Google were like, Yelp reviews for botanical gardens. This was about six months after all trails had been founded. And so I just felt there's this massive and important informational gap online about how we discover outdoor access, outdoor recreation, connect with it. So I built a company to try to solve that problem in that company. Ended up being a really great experience, ran it for four years where we became a decently well-known company in the outdoor space. We worked with many of the be the best brands and we became a content publishing business. Functionally, we were creating editorial content about great adventures and places to go all over the world, that ultimately kind of led us into. See an opportunity to pivot that business into content marketing software, which we did, and I can get into that, but that's how that journey started and how it began.
dan-balcauski_1_05-21-2025_140920:So, it's funny that, I feel like a lot of technology companies, especially as they try to wrestle with the beast that is SEO, often feel that they become a content publishing platform just as much as they are a technology company. I've had my, my fair share of that as well. I guess so, so, so leads from that story, I guess you go from focusing on the outdoor industry so tell us about how you end up then in the SaaS world from there.
fynn-_1_05-21-2025_130921:Well, so this is about, been about 2015, and the way that company made money is like big outdoor brands like think the North Face would pay us for content creation. And that content creation wasn't like product content, it was like reviews and trail reports and destination profiles for. Every sport imaginable. And so what we ended up becoming very good at is creating hyper-local editorial contents at relative scale. We had hundreds of professional writers working for the business, creating lots of really good content, whole sort of editorial layer. And what sort of became apparent to me is we can build, a cool lifestyle, profitable business in this space, doing this work, also big brands in the industry were starting to pivot to towards e-commerce. And so content marketing was becoming very important for their e-commerce businesses. And they were actively paying us for content, and they were actively trying to find ways to get us to create more content. And so the opportunity that presented itself was to begin to productize portions of our publishing stack so that we could license content to brands, enable them to commission content from a platform, enable them to run really high leverage content analytics. to look at impact not only from a brand awareness perspective, but also attribution down to the sale in the context of like content driven email marketing. And so that was sort of how that opportunity happened. And so we spent 2016 kinda building that platform. I remember we, we pre-sold about a half million dollars in a RR into brands, like before even launching the content marketing platform. then we grew relatively quickly and. That growth
dan-balcauski_1_05-21-2025_140920:that.
fynn-_1_05-21-2025_130921:us raising around a venture capital in 2018. And the opportunity at that point was how do we take this brand, this content marketing software business that's very vertical and start to expand it across verticals and sell into e-commerce, for any type of thing. Not just outdoor, but beauty and broader health and wellness and sport, and so. That's what that was all about. And we did that until about 2020 when an email marketing platform that was also selling into e-commerce businesses acquired the company and merged the team and merged two products I.
dan-balcauski_1_05-21-2025_140920:That's a fascinating journey there from that you guys recognize that opportunity and were able to sort of capitalize on it. I wasn't planning on going here, but I am curious. Around this idea of, having this very vertical focused business and then looking at, okay, expanding cross horizontal as you kinda look back at that time. I guess are there were there surprises or sort of lessons that you learned to be able to do that? Because I think this is kind of a, this is one of these core challenges I think a lot of companies face as they try to kind of expand their market. If you kind of go back and do it again, were there things that you didn't realize of, like how challenging they would be to kind of expand horizontally?
fynn-_1_05-21-2025_130921:So many lessons learned. I mean, I think, for any founders listening, right, like I was in the midst of pivoting a media business into a SaaS business, that in and of itself is exceptionally hard to do, just. Just think about the culture that, that, the cultural change that transpires for a company that's trying to do that. You go from a company that's built itself on great writing and great editing to a company that is building itself on software development. I mean, it's just a massive transformation. I think, when you think about moving from a vertical to going horizontal, well, why would you do that? You do that because you believe there's a venture scale opportunity in going horizontal. As opposed to, and there's not a venture scale opportunity in vertical. And I think that that was true. But I think that when you decide to go horizontal, when you decide to take venture you're going for a, go big or go home type business. And The trade is, a very likely profitable lifestyle business that you can run for a long time versus something that has to go be very big very quickly. And I, at that time in my life wanted to go pursue the venture outcome. That was what was motivating me. I think the more sober entrepreneur of, a decade later, looks back on that and kind of, says to myself, Hey, you had something really special in that vertical and there were so many great relationships. Why did you do that? And, no regrets, but those are some of the trades and some of the lessons and there's, there are kind of. things going out in the outdoor industry now. Like Outside Magazine is trying to create this huge media conglomerate in the outdoor industry where they're bundling all the media brands and they're trying to become like the fat, like the Facebook for outdoor media. And I think it's, I ultimately think it's not going to be very successful. I think it's extremely hard to do. I think there were other lessons too, like content marketing as a category was, it was trying to make content available to companies at scale and what none of the content marketing platforms like mine that raised meaningful amounts of venture capital, maybe sort of appreciated or knew was coming was chat. GBT.
dan-balcauski_1_05-21-2025_140920:I don't know if anybody saw that necessarily. Right. Unless you were deep. Unless you were deep in the research labs at at Deep Mind or otherwise. Very few of us saw this disruption. Well, and look you made some really good points there. Yeah, there's. The world is littered with companies that tried to pivot a services business into a software business. It is an incredibly hard transition. And, I would say no less a difficult transition, as you pointed out, than going from a vertical business into a horizontal business. And I think the other good thing you noted was that, the world's full of trade-offs. And you're taking a very specific bet when you sign up for institutional capital, like venture capital and you're signing up for a very specific, maybe bimodal set of outcomes as you go big or go home as you mentioned. And, that's super helpful, right?'cause there's sure, there's a lot of other entrepreneurs out there who maybe. That is not as apparent to them'cause it's their first rodeo. So appreciate you sharing both of those. I guess kind of fast forwarding then, I guess, was there particular challenges that you saw across those experiences that ultimately inspired you to create schematic or how'd you get into the monetization space?
fynn-_1_05-21-2025_130921:Yeah, it was a little bit of a two step. So, after Macho was acquired, about six months later, I was recruited to a company called Ox. And Ox at the time I knew the CEO because he had raised his series A from the same fund that I had raised my series A from. And we had become friends. He had just raised a really meaningful series C he asked me to come and build a growth team at ox. And that was, again, six months after matcha had been acquired the exact same week. I remember it vividly. My independent board member from matcha got on the phone with me and I said, Hey, it's been six months since the deal happened. I'd love to kind of know how you think about the company, what we did well what we did poorly, things like that. And he said, one of the things that I think you and we, the board did poorly is pricing. I think it was our biggest mistake. I think that we as a board should have come in and really helped you understand. Value to price. We really should have helped you understood helped you understand how to go talk to customers about willingness to pay, packaging preferences, price metrics we didn't, and I think it, it ultimately was like one of the biggest challenges for the company. I joined I. and three weeks later, like one of the first big things thrown onto my plate is go figure out pricing business hasn't changed pricing in two years. we've got thousands of customers and let's get this show on the road. And that presented this really incredible incredible. for me. It was fascinating psychologically. It was fascinating from a data perspective. but it also but it also. closely with insight Venture Partners Center of Excellence on Pricing. And that happened to be a guy at the time named James Wood, who had. Trained at Simon Kucher and done pricing for Segment, and you had just like all this incredible experience. And so got this MBA in pricing and packaging outside of like my operating mistakes, like overnight, and suddenly that translated to here I am interviewing dozens and dozens of customers doing primary research on price sensitivity and packaging preferences, and leader, filler killer, and all this stuff. At the helm of a really, like a company with an incredible product market fit with tons of potential to grow, tons of potential to leverage pricing and packaging to drive meaningful top line, year over year growth rate on top of already strong growth rate. And so that's how it all, kind of monetization really sort of hit me in the face. What led me to starting Schematic is after we came up with the initial recommendations for how OX should evolve its pricing and packaging. It took us si well over six months to implement just portions of the recommendation. We wanted to introduce a third tier and a couple add-ons. Six months later we'd like barely introduced a third tier, no add-ons, and by that point our recommendations like were effectively stale given how fast the market was moving and how fast the product was moving and that it took so long for us to make changes. Really lit up my curiosity, and can go into that in some detail, but that's ultimately what led me to founding schematic and trying to solve problem, which I can talk about in more detail. But that's how it, that's how it happened.
dan-balcauski_1_05-21-2025_140920:Got it. Got it. So you had you kinda had, this meeting with your former colleague, Hey, we really could have done better job on monetization. You get thrown sort of, feet right into the fire at Ock. To go solve that problem. And I love that term, you phrase, you used to hit you in the face. I feel like a lot of people, first time they come up against pricing, it's very relatable experience. And, I know James very well. He is. Everything you talked about to be he is. Fantastic. And I believe you guys had a wonderful conversation on monetizing SAS as well. You were in very good hands learning from him. I guess I'm curious kind of coming out of that so you get the strategy recommendation and then, it's this long slog to implement it, I guess. How did you decompose? Is this a just an operations issue? This is a technical infrastructure issue. This is actually a problem with kind of not everyone buying into the strategy, I guess kind of what was your signal that you're like, yeah, now I guess that birth sort of you focusing on schematic.
fynn-_1_05-21-2025_130921:Well, it wasn't apparent to me that it was a technical issue initially. It felt To me that it was an organizational issue. And when we say this, I mean, we're talking about just like the very slow time to value. Here is
dan-balcauski_1_05-21-2025_140920:Yeah.
fynn-_1_05-21-2025_130921:that the executive team has agreed on, takes us a very long time to execute it. Therefore. Time to value. Time to realizing the benefit of the recommendation is just excruciatingly long, especially in kind of the context of, a series C startup that is making the argument to itself and to its market and to its investors that it can massive incumbents because it can be faster. Like speed is everything at this stage. And so initially my thought was like, this is just like a cross-functional hard thing to do. It requires a bunch of cycles. But then I started digging in more, and I would spend a lot of time asking people in finance, people that were kind of handling billing and finops, like, why is this so, so hard to do? Like, why does this billing system feel so fragile? Why am I always talking about like the constraints and stripe billing that are preventing us from hitting these deadlines? And like was the reality of billing fragility and like the billing system wasn't well set up for kinda things like usage-based pricing. And there was that, but you would often hear the folks in the finance org say things like, well, we just can't get enough engineering resources. We just can't get enough developer time. We're having to argue for like sprints outta the engineering team. We're having to. Lobby the engineering team to pull developers off of core features and into the billing and pricing initiative. And that was
dan-balcauski_1_05-21-2025_140920:That was.
fynn-_1_05-21-2025_130921:interesting to me. I wasn't aware of that really. I started just interviewing our CTO. I started interviewing billing like people that were kind of engineers working on billing and what they started to say, and they would always say it with different words at the time, what they started to say became consistent and they would say something to the effect of. came, it comes back. All this brittleness, all of this slowness that you feel comes back to how we've implemented what are called entitlements into our application. And that was like, okay, cool. Well what's an entitlement? And I know, you know what entitlements, for those that are listening that don't know what entitlements are, like a simple way to think about entitlements is they're like the rules that determine. What features, limits, and products a customer can use based on like commercial context, based on their subscription plan, based on their trial status, based on their contract. And entitlements are sort of this between application your product and typically the billing system and entitlements are kind of there to answer questions like, can this user access feature x? How many seats is this company allowed? Has this company hit their usage cap? Are they on a trial with like temporary access to a feature that we extended to them? And at Auto Moss, what we had done is we had hard coded the entitlements into the application and then tied them closely to plan IDs in the billing system. And what I learned was that because we had hard coded all this. Anytime we wanted to make a change, no matter how small, like just granting an override to a customer, engineering was critical path. We had to go ask an engineer to make a change in the code. And if you think about that, that scale across, thousands of customers, dozens of plans, lots of different permutations. You're sort of entering a world of pain where to make any change to pricing and packaging, whether it's a global, I just wanna introduce a third tier to, I wanna go do something to drive growth. Like I wanna launch an AI feature and I wanna test it with a promo across this cohort of our commercial segment customers. It's just impossible because you gotta go back and you gotta get the engineering team to give you developers to support that. So that's how this kind of hap, that's how I got that's how I kind of found where the real constraint was. And at that
dan-balcauski_1_05-21-2025_140920:Mm
fynn-_1_05-21-2025_130921:what, what started to kind of crystallize for me is, okay, this is the problem at ox. This is like an entitlements problem. I wanna see if that's true for a lot of other companies.
dan-balcauski_1_05-21-2025_140920:mm
fynn-_1_05-21-2025_130921:And so I
dan-balcauski_1_05-21-2025_140920:Well, one.
fynn-_1_05-21-2025_130921:I went out and I interviewed like hundreds of comp a hundred, 150 companies and they were all doing entitlements in a variety of ways, and they were all constrained in similar ways, and I thought, okay, feels like the kernel of something that could be abstracted and solved.
dan-balcauski_1_05-21-2025_140920:There's so many threads in good threads in what you said that I wanna pull on, and I don't think we'll have time to, you can touch on all of them that you just introduced with that little story. But I. So first of all for folks who maybe still be lost about entitlements we'll use everyone's favorite car company, Tesla maybe not favorite at the moment, but we'll leave that aside, right? If you wanna enable full self-driving, you pay them whatever,$10,000, they flip a switch over the air, all of a sudden your car can drive itself. So that would be like a version of an entitlement. And. All the other car companies would've love, would love to do that. But most of them, you'd have to take your car to a shop, but they'd probably have to plug your car in in order to change that, et cetera. Tesla has built it from the ground up to make those type of things seamless and easy. Much like your iPhone updates to the latest version probably whether you don't want it to, but it will anyway. So, your photos app stops working, but you know that, we'll leave that aside for now. So, but then, I am curious, kind of going back into your. So, and look, none of this is to say anything about any of the specific companies we're talking about because obviously this is a pervasive problem that, that I see. And that obviously you identified enough to build a company around it, right? So it's not, it has nothing to do with the individuals on the finance or engineering team or the organizational function or dis or dysfunction of that particular company. But, this is sort of a real problem. I am curious when you start talking to. The finance leaders or team, even the ICS potentially who are dealing with like the billing system versus the engineering teams. I'm curious about like what are the communication gaps going on? It sounds, it's like when you understand the system and you know exactly what needs to be asked for and why I, my sense is that you can get everyone. Relatively on the same page, right? Obviously priorities are always gonna be a struggle. Engineer time's always already gonna be a struggle. But I guess what were the communication gaps that you found that really sort of prevented those teams from sort of really getting their arms wrapped around this problem efficiently? Were they because you mentioned before even different team members, when you talk to them, they would, they would use different language to kind of describe it. Were there common sort of communication gaps that you found as you've had more and more of these conversations?
fynn-_1_05-21-2025_130921:Yeah and I would say the question that you're asking to me is a fascinating one because it can be, it can extend beyond sort of language gaps and into just the nature of complex organizations and different scopes of interest, different incentives, and also just the way categories have evolved. So let me see if I can riff for a sec. Like on the language piece, entitlements was a term that I heard more often than not from like ops and rev ops people. And when you talk to an engineer and you introduced the word entitlements, they'd immediately gr it. But they probably would not have used that word. They probably would've said something to the effect of feature access or feature access
dan-balcauski_1_05-21-2025_140920:Yeah.
fynn-_1_05-21-2025_130921:or feature
dan-balcauski_1_05-21-2025_140920:Hmm.
fynn-_1_05-21-2025_130921:Limit or AP golf API like, there just wasn't sort of like consistency in the termina terminology around this intersection between billing and product. Right? And it's easy to see why the engineer is building an application. They start to kind of think through things like, well, what should my What. care about? Should my application care about who the user is, what plan they're on, what features they're allowed to have, and from a finance perspective, like what do they care about? They care that the customer gets invoiced the right thing and they care about the customer having, making sure that what they have access to, lines up with what's on the contract and what's on the invoice. there's kind of different spheres of. Different scopes of interest, if you will. And sort of what started to dawn on me at that time was like, okay, this is like pretty fascinating because you got this problem that is impacting both these teams plus all the downstream teams that can't like use monetization. They got language issues, they got tools that don't talk to each other. Engineering is being asked to go build and maintain a bunch of logic between the application and the billing system. So what engineering's being asked to do is maintain a bunch of billing logic in the code base. And if you go down and you like talk to A-A-C-T-O or like a technical architect, and you're like, do you think it makes sense that an application should know this? They'd be like, no. Like, all the applications should know is does the user have access to this? Yes or To No. And making sure that the application is like a great application application. Mm-hmm. more you try start to peel that back, the more you just start to see the way software categories have evolved. And what I mean by that is like in the context of pricing, what I mean by that is in a typical software company, pricing and packaging are governed by like multiple stacks, functional technology stacks. So if you think about like sales, right? Sales have CRM and they have quoting, pricing and packaging are often governed by the CPQ product, the quoting product in a traditional sales led enterprise business in a more product led business, like maybe it's the billing tool that and owns pricing and packaging. It's where like the product catalog might sort of initially be housed. And then if you look at the product stack basically a question of. Provisioning and configuration and access tools like feature flags do this. These are all discrete technology categories sold into engineering, finance, and sales, and they don't really talk to each other well. So what you end up with is like diffuse product catalogs. That obviously leads to huge drift. That obviously means that a. Change to pricing and packaging in one place is a change in many different places across many different teams. And here you and I are talking about
dan-balcauski_1_05-21-2025_140920:I.
fynn-_1_05-21-2025_130921:We're like, Hey, well this is like clearly the right way for the business to price and package, but oh, it's gonna take you six months or a year or whatever to implement what I'm saying because all these systems so siloed. You asked him a narrower question than that, but I think the question of language gap is also related to. Siloed software stacks, functional stacks, pricing and packaging being governed in different places by different tools with different spheres of influence in a business.
dan-balcauski_1_05-21-2025_140920:It's funny that you mentioned that because, or, this whole thread is hilarious because there's I've worked with companies before where literally the head of sales was mad because the company bought a billing system and was just like, well, why don't the engineers just bill it?'cause we just move faster. And and the billing system imp the reason the salesperson didn't like it is because the billing system imposed constraints that the. Head of sales didn't want to have to abide by, they wanted to be able to sell anything at any time to anyone. Just infinite like configurability, which of course the rest of the business didn't want. But all of the ire, like in every exec meeting we get thrown at the, oh, it's this billing system's fault, blah, blah. So you're talking, why did I bring that up? Is because, you're talking about differences of incentives. Well, but yeah, you don't wanna Also, there's this whole notion of comparative advantage. Like you don't want your engineers who should be building the product that only your company can build best suited for your market to have to re-implement. Commercial business logic that every company around the world right, is you're not gonna send your engineers to go rebuild A CRM or Salesforce unless you're the CEO of Klarna and they're losing money anyway. So I probably wouldn't pay attention to his advice, but in general, we do not want to like reinvent the wheel where it's like other companies like, yeah. Yeah. All day, every day they're in the CRM business. Let them, same thing like billing solution people, they're in that business. Let them solve that problem. But you're, you did point out all these sort of incentives do come together in a, in very interesting ways. I guess, I'm wondering like, are there sort of. Mistakes that you see kind of early stage companies make then that sort of sow the seeds of this downstream, these downstream problems. I'm wondering is this sort of that, the inevitability or I think are there like things that like, like cer certain decisions that like kind of make this, it. Inevitable, right? I mean, you were hinting before about if you're talking to a technical architect, you're saying, Hey, should this piece of code have knowledge of commercial billing? And they would say, of course not. Is that kind of the, is that the root sin or is there, are there sort of a cluster of these things that you see that, that kind of cause this to, to spur into six to 12 months to actually implement a strategy?
fynn-_1_05-21-2025_130921:I think it's a great question. I mean. I think that this type of thing, so when I started really researching the problem and what that meant was like interviewing a lot of engineers at a lot of different companies that had for whatever reason ended up working on billing and pricing. One of the things that they would often say is something that you just said, they would say, I feel like I'm always reinventing the wheel here, when it comes to pricing and packaging and billing. And I'd say, well, well tell me more about what you mean, and. What they kind of meant was like two things. One was up until I had been tasked with this project, I had never done billing engineering before. Like I'm a trained computer scientist, like I know how to build products. I did not know how to build like billing logic. And it feels like this should just be done. Like it feels like this should be like drop in, like this should be like a standard or like a protocol. Like it feels like this should just have been solved. Some in some ways, they would often reference like authentication, like companies like auth zero, like people would roll their own auth and that was really hard and it was like fraught and people were reinventing the wheel. And then after companies like auth zero, people just, abstracted off away. so that was like one side of what engineers were saying is this desire to be able to abstract this thing away that they didn't have a lot of experience with. The other thing that they would say is like. do a billing initiative and then it's three months later, six months later, one month later, whatever it is, the business will change its mind on how it wants the pricing package. And they'll
dan-balcauski_1_05-21-2025_140920:That never happens. That never happens. They're always consistent.
fynn-_1_05-21-2025_130921:yeah, and then they'll pull me back in and it's
dan-balcauski_1_05-21-2025_140920:and it's
fynn-_1_05-21-2025_130921:I go build like this infinitely flexible system, then constantly pulled into these billing initiatives. But here's the problem. I don't have time to go build some infinitely flexible system like I got, I have time to get exactly what the business told me to get done, and I don't even have time for that. And so I think to,
dan-balcauski_1_05-21-2025_140920:is there.
fynn-_1_05-21-2025_130921:your question, why does this happen? Well, it kind of happens because, there are not a ton of engineers that have a ton of experience doing a bunch of billing engineering. Pricing impacting is always evolving. And the engineer working on this can't predict how the business is going to evolve. And you wouldn't want them to, that's not their job. And then I think,
dan-balcauski_1_05-21-2025_140920:I think
fynn-_1_05-21-2025_130921:of all, and it kinda gets back to just like the reality of startup evolution is like when you're a startup, you're just trying to
dan-balcauski_1_05-21-2025_140920:trying
fynn-_1_05-21-2025_130921:And so you'll make all these trade-offs. just gonna figure out how to
dan-balcauski_1_05-21-2025_140920:out how.
fynn-_1_05-21-2025_130921:way for this customer and billing for this way, for this. We just gotta get through this and survive. And because there isn't some. Pattern or drop in set of components or off, make those trades and then you revisit them later. Should you achieve product market fit? At which point you gotta go through paying and refactoring and you've gotta now address, are we gonna make
dan-balcauski_1_05-21-2025_140920:we gonna make,
fynn-_1_05-21-2025_130921:and entitlements and pricing a first class citizen from an architectural perspective, gonna keep band-aiding. This homegrown system that's fragile between our application and our billing system, and now our CRM and now our ERP stuff like that.
dan-balcauski_1_05-21-2025_140920:I I want to. It is not a pivot but kind of a slight nuance.'cause everyone these days can't stop talking about usage based pricing. And I'm, I imagine this is in the mix of those conversations, as folks, maybe have a more traditional sort of subscription and now are going to what, a pay as you go or some sort of metering based upon some other, usage component that's not just your traditional seat. What are the challenges, I guess, that you see kind of specific to that type of initiative that, maybe it's the same thing we've been talking about I guess are there hurdles from an infrastructure that you're seeing sort of repeatedly as folks try to bring that into their pricing and packaging approach?
fynn-_1_05-21-2025_130921:Yeah, I think, usage-based pricing, usage-based billing is. It has surprised me. And what I mean by that is two years ago when I founded Schematic, I thought, yeah usage-based pricing is gonna be a thing. Schematic's gonna have to handle it well. But I kind of viewed it as like a fraction of companies are gonna be adopting usage-based pricing. you're gonna see relative diversity in terms of pricing models across sas. Some will remain really good for seats. Some might be good for usage, some might be good for, think what's going on right now, at least in my experience, building schematic and that because of AI usage base is accelerated far faster than I thought. And it's just like a bigger number of companies, a much larger number of companies will use usage or hybrid to go bill and price. And so from a technical perspective like. does that mean? It means you have to figure out metering and you have to figure out, do you wanna build metering? Do you wanna outsource metering? Are the tools that you're outsourcing metering good at good for the job? Are they,
dan-balcauski_1_05-21-2025_140920:When you say metering, when you say metering, can you just unpack that a little bit for folks who may not understand what that means?
fynn-_1_05-21-2025_130921:Yeah, like metering, can, it can certainly be like confused. But the way I think about metering is I want to track, how often, frequently much a feature is used. And I may want to against that usage and well, what if I wanna bill an arrears? What I want? What if I wanna bill on overages? Wanna, what if I wanna bill a pay as you go? What if I wanna do almost like credit burn downs? What if I wanna do, usage based bands like now there's all kinds of complexity on the way I could bill against metered usage, depending on what kind of price metrics that my market has anchored to, depending on the nature of my product, all that kind of stuff. And so
dan-balcauski_1_05-21-2025_140920:Mm-hmm.
fynn-_1_05-21-2025_130921:that's complex to build, especially if you start to see scale and it has to be really good really fast. Really accurate. Right, because you're now getting into the ultra, the most ultra sensitive thing, which is like you calculate usage wrong and you send that bill to the customer and like you're risking churn if you've miscalculated. So, that's one of the technical challenges, like we could go into this in a lot more depth, of course. But that's one, right. And that's that also kind of gets back towards entitlements, right? Well, what if you have said. People can use this much in this plan. Well, what if they exceed their plan? Are you going to enforce that? Are you gonna enforce it with a soft limit? Are you gonna enforce it with a hard limit? Are you gonna use that limit to potentially drive expansion revenue? Do you want that expansion revenue to be driven via self-serve? you fired a paywall or you sort of n nudged them to go kind of like self-serve, adjust their plan. do you want that limit drive a sales conversation because it happens to be a Fortune 500 company and they buy through sales and they've hit their limit.'Cause they were just testing out the product with a team within the big company. Like kind of move into this world of to me, fascinating. It's like revenue complexity. It's like I'm supporting LED growths. I'm supporting sales led growth, supporting hybrid billing, I'm supporting multi-product and I gotta find a way to do that. And it's infinite permutations of SKUs, and it's all connected between product tools and billing tools and sales tools. that's what's happening in the world right now.
dan-balcauski_1_05-21-2025_140920:Well, I, yeah, you laid out a bunch of points there and for folks, right? So you mentioned the you're risking churn. If you send an incorrect bill, you're at least risking you're for sure gonna get an angry phone call. That's gonna be the minimum. It may be also a cancellation, but you at least have to deal with that. And especially if you, during that at scale, you're getting a lot of angry phone calls all at once. Which is no fun for any customer support or finance operations team to have to deal with and go rec. Re reconcile everything, let alone if that trickles across, months or quarters and you've gotta go re tell your board or revenue numbers were wrong for last quarter'cause our billing system was not acting properly. That's not a fun conversation as CFO will attest. And then, you just highlighted in that explanation nuances in detail that you were highlighted before, which is like the engineer sitting there saying, look, they always want. This additional thing a month later, right? Where it's like, Hey, with this month, we're, we are gonna enforce overages when last month we weren't, or this time, we're gonna we wanna also trigger these, transactional notifications or, changes in the product, or we want to be able to charge overages at a different rate than we did before, with some other sliding scale of, monetization. And there's also, just knowing about the space as well. Right? There's, you mentioned having to be fast and accurate depending on what you're monitoring. You might be throwing off thousands or tens of thousands of these events. Very rapidly. And so you don't want to necessarily store all those individual data points, so you've gotta figure out, okay, I need to aggregate it, but then I need to make smart choices around when I aggregate it and what I store so that I can, I, there's audit capability all the way back through, and these are just the things that, like when you're. Sitting in that conference room for the first time telling engineers, Hey, we wanna do some usage based stuff, everyone's, oh yeah, that'll be easy. Right? And then it's alright, six iterations later, everyone's I wanna kill myself. Why did we go down this road? But you did throw out some catnip I can't let go away, which is, you mentioned AI and how AI's really sort of driving this conversation. So I'm curious like. What is, I guess, how are these products kind of approaching monetization differently than traditional SaaS? And I guess, are you noticing any patterns in how these companies are structuring their pricing? As people I think everyone's sort of in this mode of experimenting and trying to make sure there's value and, are these things actually production ready or fancy demo. But I guess in terms of. The world you're in, you're probably seeing a lot of folks try different things. Are you noticing any sort of patterns or common ways folks are trying to approach monetization in the AI world?
fynn-_1_05-21-2025_130921:Yeah, I think. Well, so the pat, so I'll say two things. One is the patterns that I notice typically come from like the companies Mm-hmm. Come to schematic looking for help. And those companies are companies that are trying to support some flavor of usage-based pricing. Really companies come to us for three reasons. That is the, by far, the most important reason and sort of the. The sub bullet reason of trying to support usage based is I'm really trying to enforce limits. And there's something notable to me about that, which is four years ago when I was building matcha and then Spring bot and ox, like we were pretty okay with being lenient on limits. It was like, yeah, we'll talk to them at the next renewal cycle if they've been way over. I see companies being a lot more. about limits, and I think it's because of two things. I think it's because like they're actually real costs under, underneath these products to make calls to the LMS and to kind of leverage the infrastructure, but also because it's like, great opportunity to drive revenue growth if somebody is approaching a limit or going over a limit abusing a limit. It just like an exceptional growth opportunity for a company, and I'm seeing startups way earlier than their life cycles realize that and want to do something about it. And so that's the first thing I see. I think the second thing I see is kind of back to that sort of like complexion of a lot of these companies. They're not often just sales led or founder sales led. They're not often just product led. They're often both. And they're often like not just selling like a simple single tier, they're selling multiple tiers. They're even getting into add-ons even as early stage companies. And I kind of chalk all of that up to you gotta B2B sas and AI customer sort of totally empowered, like there's an exponentially growing amount of software. The customer's super empowered to go buy whatever they want to solve, whatever problem they have. they're demanding of vendors, SA SaaS and AI vendors is flexibility. You let me buy how I want to buy you, let me, get, build and priced how I want to get billed and you let me buy what I want from your product. If I don't want the whole thing, should be able to buy portions of it. And I think that is, that's like a pretty fascinating evolution. And it's a challenge for software companies.'cause now you have to build all this flexibility into the way that you. Develop product and monetize product
dan-balcauski_1_05-21-2025_140920:There's so many areas we've opened up here that we just do not have time to explore. Maybe we'll have to have versions two or three through 10 of this conversation.'cause there's so many doors we could walk through. But I've gotta wrap things up to be respectful of your time. I do wanna close out with a couple of rapid fire kind of close out questions. If you're up for it, you ready for it? Fynn
fynn-_1_05-21-2025_130921:ready.
dan-balcauski_1_05-21-2025_140920:What's one unconventional piece of advice you'd give SaaS founders about monetization that goes against the conventional wisdom?
fynn-_1_05-21-2025_130921:I don't know how unconventional it is, but I still believe that. It is pervasive amongst startup founders that they don't have the tool, the vocabulary go have willingness to pay conversations with their customers, whether they are pre-product to post-product market fit. And I think that founders who invest in the tool, the vocabulary to invest in willingness to pay massively increased their odds of. because they massively increased their understanding of how the market views their value.
dan-balcauski_1_05-21-2025_140920:I love that question. I know This's supposed to be rapid fire. I'm gonna ask a follow up'cause it's my show. I can do what I want. If you had to give someone like a 32nd primer on, like when you say vocabulary, what are the things that they need to go throw it to Chachi PT after this conversation and just spend some time researching.
fynn-_1_05-21-2025_130921:Like the vocabulary of willingness to pay, in my opinion, is what is the most, what is my most intuitive price metric? How valuable is my product relative to other products that you have bought and are paying for? How should I package my product? Which features are, kinda must have versus nice to have versus don't matter. What is the maximum you would be willing to pay for this product? What's the price at which this product is prohibitive? What are other influences on your willingness to purchase? And, probably add a couple more, but those are like the key ones in my opinion.
dan-balcauski_1_05-21-2025_140920:Love it. What do you think is the biggest opportunity in the monetization space over the next few years?
fynn-_1_05-21-2025_130921:So a little self-serving here, but I think if we move into a world where let's assume there's 70,000 software companies in the world, and let's say that AI means that there're gonna be another 70,000 over the next five years, or 50,000, whatever. Who knows? If a vast majority of those software companies decouple pricing from code, those companies will be able to use the tools and the tactics and the experiments of monetization with far more agility and flexibility and control than, the last 25 years of software companies ever had the opportunity to do it.
dan-balcauski_1_05-21-2025_140920:This conversation's been fantastic. Fynn for our listeners wanna connect with you, learn more about schematic, how can they do that?
fynn-_1_05-21-2025_130921:I'm on LinkedIn, Fynn Glover, FYNN, and schematic is schematic hq.com.
dan-balcauski_1_05-21-2025_140920:I will put those links in the show notes for our listeners. Thank you so much, Fynn, everyone that wraps up this episode of Sask Getting Secrets. Thank you to Fynn for sharing his journey. For our listeners who found Fynn's Insights valuable, please review and share this episode with your Network.
