The Death of Seat-Based Pricing with Lee Bridges
Episode Summary
AI is fundamentally changing how SaaS companies should think about pricing. When your software makes teams 70% more efficient, charging per seat means you're literally shrinking your own market. In this conversation, product management veteran Lee Bridges explains why seat-based pricing is a burning platform and what comes next.
Lee, returning to the podcast after five years, recently led a pricing transformation project that forced him to confront an uncomfortable truth: AI-driven efficiency gains directly reduce the number of seats customers need. His solution? Outcome-based pricing that aligns incentives between vendors and customers while future-proofing against AI disruption.
Guest
Lee Bridges - Cheif Product Officer at Inn-Flow, father, audio engineer, and vibe coder who recently completed a major pricing transformation project for a B2B SaaS company in the field service space.
Key Topics Covered
The Seat-Based Pricing Problem
How AI efficiency reduces Total Addressable Market (TAM)
The misalignment of incentives between vendors and customers
Internal team conflicts created by per-seat models
Why "reducing a team from 10 to 3" destroys 70% of your revenue potential
Outcome-Based Pricing Explained
The difference between usage-based and outcome-based pricing
How to identify and price meaningful outcomes
The psychology of "you make money when your customer makes money"
Avoiding the "nickel and diming" feeling of usage-based models
Real-World Implementation
Case study: Field service sales teams (20 minutes to 90 seconds per quote)
Tiered prepayment models with outcome "credits"
Combining platform fees with outcome pricing
When outcome-based pricing works (and when it doesn't)
The Future of SaaS and AI
Why B2B SaaS isn't going anywhere despite AI hype
The problem with expecting everyone to be a product manager
Consistency, training, and the limits of LLM-generated experiences
Vibe coding and no-code tools in practice
Notable Quotes
"If you create efficiencies that make a process so efficient that some number of people will no longer be necessary... you reduce the number of potential seats. You reduce the TAM."
"If I give you a dollar and you're going to give me $10 back, I'd be insane to not do that as many times as I can."
"You're really expecting everyone on Earth to be a product manager. That's just not going to happen."
"Most people don't have a high level of agency. They don't know what they want, when they want it, and they don't know how to describe it."
Practical Takeaways
Evaluate your pricing model now - If you're charging per seat and building AI features, you're creating a strategic vulnerability
Start with new products - Test outcome-based pricing with new offerings rather than risking existing revenue
Identify measurable outcomes tied to customer revenue - What metrics does your sales team already use when discussing ROI?
Consider hybrid models - Platform fees plus outcome pricing can balance predictability with value alignment
The complexity trade-off - Outcome-based pricing must remain simple enough to avoid litigation-inducing confusion
Transcript
Tom: AI is going to make companies need fewer employees. So what does that do for SaaS companies who charge by the person? And what does AI mean for software development in general? And what's outcomes based pricing all about? These are some of the questions I ask old friend Lee Bridges. Lee was our first podcast guest over five years ago. He's an experienced product manager, father, audio engineer, and coder. He's super smart, logical, and just the kind of person we love to talk to on the podcast.
Tom: Well, Lee, it is a pleasure to see you again.
Lee: Thank you. It's great to see you as well. Tom, it was great seeing you in person recently whenever I was in Nashville back there. But it's good to talk to you now as well.
Tom: Yeah. No, I'm glad you brought that up, because this conversation came out of that conversation, which is that you mentioned you have recently gone through a pricing project, and I wanted to talk to you about that because I'm a SaaS OG self-appointed. And all of our pricing was seat based, and you were telling me that that's dead. And I wanted to hear your why it's dead. And what's next.
Lee: More of a prediction than a current kind of declaration, but, yes. Happy to talk about it. I think it's really interesting what's going on?
Tom: So, what is going on? I mean talk to me about your pricing project.
Lee: Yeah. So, of course, a ton of B2B SaaS is seat based. It's very natural. It makes a lot of sense. That's who's using the product. It's an easy metric. You can you know, the permissions are based off of of the users already. So you know who's in there, so it's easy to charge by it. Ai is really changing the game in my opinion. I'm not the first to say it, but I think it makes a lot of sense. So whenever you look at AI driven products, they create just enormous efficiencies that were never able to be achieved in the past. And so if you look on the negative side, that means people may lose their jobs in the future. From a business who makes software their perspective, that is a, you know, creating those efficiencies is a benefit to their platform. But if you combine those two ideas, then you actually reduce the Tam for the software maker. Whenever you create these efficiencies, whenever you make a process so efficient that some number of people will no longer be necessary to do that process or to achieve the goal in the software, then you reduce the number of potential buyers and the number of potential seats. Let's say maybe not potential buyers, but the number of people who actually need to use the software, which represents a real world reduction in TAM. And so have.
Tom: You seen this in practice? I mean, in reality or is this more theoretical right now?
Lee: I think it's it's on the verge. Like I think for certain products already in the, in the market, it is a real world thing. It's it's a realized issue. But for us with the current with the project that I was working on, it was more theoretical as we looked to launch a new set of products that were aimed at really achieving a, an unheard of level of efficiency. We were looking at how to price. And so the research and kind of thinking through how how this software was going to work. We realized that this was a theoretical, but we think real. If we achieve our goals with the software, then it is a real problem for us.
Tom: Okay. Let me summarize. Make sure I understand it. So let's say I'm building software that allows an organization to take a team of ten and turn it into a team of three. And I'm calculating my total addressable market, my TAM, based on current status, which is everybody's got a team of ten. But now I just whacked that with my product. So it's just a team of three. Am I understanding the dynamics correctly?
Lee: That's right. And then suddenly you have a Tam. That's 30% of what it used to be.
Tom: And so like you said, do you think that this is sort of a wave that is gathering and kind of how is SaaS suite based SaaS affected by larger changes in the economy of technology, creating efficiency. And then I'm not so sure, like you were, you were doing this in kind of a hard hat space. And I'm not so sure that well, in a hard hat space, I could definitely see people getting laid off. But most of my experience is in hospitals and they're pretty loath to lay people off. And so some people just get redirected but they still may no longer be seats. Does that matter much if they're getting redirected or if they're getting laid off? In terms of how that affects the Tam.
Lee: I think for the the software maker, it does matter, because I think this happens over and over again with technology and just in history. So we see we see technologies come along that reduce the number of people that are necessary to do a certain job. And then it may not be within the same business that they get reassigned. Though, you know, it may just be that they and it may take a generation of workers. It may not happen within the same generation, but the skill sets change that are necessary and people end up doing other jobs. Now, if if they're moved to another job that is not related to the workflow or the the goal that the software was built to achieve, then it does matter for the software maker because they're no longer a part of that market. They may get reassigned to some other task within a hospital or a medical environment that may have nothing to do with the platform that's being built and priced in this scenario.
Tom: So I think I've always felt like seat based licensing wasn't awesome because it was it misaligned. The incentives of the business wanted as much utilization as possible, and the customer wanted as little as possible to reduce their expenses. And that was a missile that felt like a fundamental misalignment. So first, what are your thoughts on that observation? And second well, anyway, we'll just we'll just go with first for now. What are your thoughts on that observation?
Lee: I think it's a solid observation. I think in addition to to that observation, I'd say it misaligns often the incentives internally for the business you've got sales folks and CS that are focused on increasing the way that they get paid. Their incentives are aligned to increasing the size of the account. The only way to do that is through increasing seats. A lot of cases. And but product should be focused on making a usable engaging and adopted product. And that's not always the goal of the other people in the business. That's not what they're incentivized to do necessarily. And and so you get these misalignments between teams, even not just between customer and business, but between internal cross-functional teams.
Tom: I hadn't thought of it in those terms that it's not just you against your, your customers. But it's you against yourself in terms of the the servicing of those accounts. So if pricing buy Z kind of has some. It's simple, but in the long term it kind of stinks. What did you come up with?
Lee: So we call it outcome based pricing, and it is akin to usage based. But it's a little it's a little different. And it I think it does matter. It's not just marketing, it does help with marketing to refer to it as outcome based, but it also has a real world kind of tangible effect on how you how the pricing model is, is built. And so outcome based is about aligning that pricing model to the value of the customer. And so you're talking about incentives and it's about aligning those incentives internally and externally. And so an outcome may be renting a room in a hotel. Or it could be producing a report or it could be documenting a specific thing for us as documenting assets or including assets in the built world into a quote, something like that. Those are outcomes. The outcome is something that's tied to revenue for the customer. Often you want to you want to align that. And it is it starts to make sense now talking about incentives. That outcome is something that the customer wants to achieve. They want to produce that outcome. That is the whole point of the software. They're driven for that. And if you tie it to to revenue, then it's even easier to communicate that. Like listen, every time you generate revenue for yourself, we're going to make a little money. And that makes it easy also to calculate that ROI for the customer and and really communicate the value of the platform. Obviously you've got to do the job well and you've got to make it highly efficient and you've got to make the product deliver on that value. But that's that's the goal in that outcome based pricing.
Tom: So that in your software that you built the outcomes based pricing on? Was all of the data captured within your software, or were you dependent upon your customer to share some data with you?
Lee: So it depends on what parts of the platform they want to use. And that's the beauty of the outcome based pricing. You can have different products packaged together that have different outcomes, that your pricing all at the same time. Now it should be very clear. A lot of the times it's like one outcome per product. I would suggest that means they can use the product liberally. They can use it as they want to without being charged necessarily until they see the value themselves. And once they produce that outcome, then they're, they the usage of that product, the, the outcome counts against their, their pricing. And so it, it depends for which part of the platform they're using it. They could bypass certain products within the package and not be charged for those outcomes. And let's say, import data from another platform and then progress through the package to realize the value in other parts of the package and use other products so they can capture that data in our, in our product and, and be charged for that outcome and then move on to another product within the package, very easily produce another outcome.
Lee: And then as they, you know, they have their own customers. So they're trying to take their customer through a journey. And as they progress through that journey, then each outcome has its own pricing attached to it. And and a relative scale to which one outcome is is a higher price than another outcome. And so you can balance the the outcomes there. So yes, it's possible to stay within the platform, completely capture the data, use it through the platform continually for different outcomes. But we don't force it. And that's really the one of the beautiful parts. You're not selling an individual product. You're you're just trying to get them on the platform to begin with. If they want to bring their own data, if they want to export, they get to a certain part in the customer journey and then export some data. That's fine. We just want to get them in there, and then we'll grow the account by product led growth mechanisms to get adoption of other parts of the platform.
Tom: So is there I may not be following this all that well, because it sounds a little bit like communism in the sense that it's like an awesome critique of an existing system. But more difficult to implement than you might think. So one of the things that concerns me is identifying what constitutes an outcome and if that outcome has been successfully achieved. So I'm going to try to put some flesh on this. I have a client who helps hospitals reduce falls. So falls are very expensive. And hospitals don't get paid for them because they shouldn't happen. And so their software allows an observer to identify when a fall has been avoided. And that's a very positive outcome if you can avoid a fall. But the problem is what constitutes an avoided fall. And you don't get agreement on that within the hospital, let alone a hospital between the hospital and the vendor. And even if you use AI so there are video based platform that could use AI to identify. Oh, yeah, that's an avoided fall. I could still see a situation where if someone essentially pays a fee for every avoided fall, eventually some financial person is going to say, I need a video of every avoided fall, and I'm going to watch it and decide if I need to pay you for that or not. Yeah. And so you're kind of like complex agreements tend to lend themselves towards litigation. So if you're signing a 400 page contract, you're probably going to end up in a lawsuit. And the reason why is, is that it draws you into the terms rather than the goal of the relationship. And I'm concerned that complex pricing could do something similar. But tell me why I'm wrong.
Lee: You may not be wrong. I mean, I don't have expertise in every industry, so this this idea may not be applicable in every industry. I think it my goal would be to find what's the you know, the outcome. Yes. Preventing falls but maybe it's it's the metric. Like let's I think I would start it looking all the metrics of the business that's making the software. And that prevented fall may be the main metric, but maybe they have other metrics such as time to discharge something like that. And so you could look at a weighted scale of pricing at rate of discharge or the time to discharge. And so for certain situations or classifications of why a patient is in the care of this facility, then at different lengths of time of discharge, then the software maker is compensated at a different rate for that discharge. And so that outcome could be. It does. You know, if you prevent a fall, then there I would assume going to be discharged earlier and then you could make more money that way. But I don't know. I don't know that business well enough to speak to it. I think you want to start with the metrics that you have been measuring your your product already, or you should have been measuring your product success already because that's where the value is. You know, whenever sales teams talk about the ROI of your product, what are they talking about? And then is it actually measurable? I think are two of the factors.
Tom: So particularly in healthcare, SaaS doesn't work to do much by itself. It always requires some degree of service support to go along with it. Adoption of software is very hard. You know, you're in a environment where people already have a way of doing things, you're asking them to do something different. And I kind of have yet to see enterprise software that was so simple. Everyone immediately said, oh yes, this is much better than what we're doing now. I need to do this right away. It's there's anyway so you get at the limitations of the customer and what you're talking about. What data have they got? And are they able to arrange that data, access that data to where you could start to think about things like outcomes? It's hard for a lot of organizations to measure their outcomes. You were doing things related to field service. Talk to me a little bit about that business and what constitutes a positive outcome in that business, and then how you would price in the field service business based on an outcome.
Lee: So it depends on which product and which persona within that field service provider we're discussing. So we started this discussion around pricing and packaging and moving towards this pricing model for the sales persona, which was a new area for the business. And that was important because it was less risky. We weren't risking existing revenue, we were moving into a new domain and therefore we could experiment a little bit. We though, understood the sales persona after doing a lot of research, being on the job site with them. And you may say, like, why is a salesperson on the job site? Well, they are they are looking to understand the job site themselves. They're trying to document which assets are here. What condition are they in, how old are they, what refrigerant do they use? What types of filters do these units use, etc.? Is this specifically an HVAC and commercial kitchen and a few other industries, but large critical assets that are being used continually on a job site? So a salesperson is they receive an RFP or request for proposal, and they need this data to provide an accurate quote to the customer, to their prospect. And that's time consuming. And they don't get paid for that work. This is all before the sale. And so efficiencies really matter. Also, having an accurate data set and an accurate quote leads to higher margins and accurate handoff between the sales team and the operations team. And so getting the data correct but also getting it quickly. Two very important things for this persona. And so we just studied and talked to a lot of people about how long it takes. We observed people. We understood what each step of the process meant for this person. And it's it's a multi-step process.
Lee: They go and document on the job site. They come back with a list of assets. They manually enrich that data set with a lot of this information, because you can't tell on the job site necessarily how old a unit is. You can't necessarily tell what refrigerant it uses. And so you may have to go back to the office, look at your list of assets and do a bunch of research. And this takes on average between 15 and 20 minutes per asset. Whenever you consider the on the job site work and the back office work of doing the research. And we were using AI to produce the same outcome in 90s. And so that is an order of magnitude difference in efficiencies. So and we did that by attacking the problem in multiple stages. But the, the the user can walk and talk and take photos. And by the time they're done they have structured data on that asset. And so this this was a huge gain. Now you could look at the technician as well. So that was for the sales persona. For a technician it's different. It's these companies ultimately sell uptime of assets. And so you have to look at what parts of the product can increase that uptime, which is also about reducing downtime. So speed speed to fixing a problem. And and then also whenever you're looking at maintenance preventing issues so that assets stay running instead of going down and then having to fix them quickly, they can just stay running. And so but the more time you spend in maintenance, the less money you make, the lower your margins are. And so efficiencies lead to more revenue. And so those it depends on the persona what they're doing. Et cetera.
Tom: What you just described to me I would my instinct would be to charge per quoted asset.
Lee: That's one of the outcomes. That's one of the outcomes. And so that is one of the, the points at which we, we charge. Now it's not a straight charge every time they use it. It's a prepayment. It's a tier of expected outcomes, the expected number of outcomes. And then they fall into a tier. And they they prepay for those. And their outcomes kind of count against those prepaid. So they're paying for.
Tom: What am I trying to say? They're paying in anticipation of the usage in the future?
Lee: Yes.
Tom: And if they go over that usage, it's just like your phone. If they go over that usage, you can pay a penalty. And if they're under it, do they get to bank those?
Lee: So I think those are all up for debate. We made the decision that they don't get to bank them. But if they go over their simply charged at another, they have to buy another kind of tranche, so to speak, of credits for these outcomes. And they're charged at the same rate as their current tier. Now, of course, economies of scale, as they increase the number of outcomes they're paying for, they get reduced rates. And so there's a penalty there for under committing if you under commit and then you go over, then you're going to be forced to pay for another 5000 credits or something like that, and then it's at the same rate you're paying previously. Whereas if you had pre-committed to that additional 5000, then maybe it would have been a reduced rate. So you get this again, aligning incentives internally and externally, the sales teams trying to push for larger deals. You're looking for larger commitments. That also leads to more adoption. There's less friction for adoption of additional products within the package etc..
Tom: It's funny. It's like pricing is so psychological and we, we want to have a a logical path. Like many things in life, we want to have a story, a logical story that we can follow that describes, that justifies the outcome or justifies the decision we make at the end. And so I used to be very transparent about pricing and wanted to be able to explain each step along the way. I'm becoming more and this is probably a reflection of my life in the services business. I'm becoming more black box pricing oriented of how much does it cost x why does it cost X? That's just what it costs. And because I think the more time you're spending talking about what it costs, the worse that's a bad outcome. It's the wrong it's a rotten conversation to be having about how much does this cost? Sure. And so I wonder about you know, as a vendor, I want my pricing to be simple. And so can I price based on revenue of the client? Basically, it's like, how much is the market willing to bear? And so for an organization of your size, how much would you pay for this particular outcome. The what? For my product. And it's interesting to me that you guys, the sales thing feels like a brilliant place to start, because adoption among salespeople will be high if they're going to make more money because they're using the software.
Lee: Right. So, as you said, like we cut down a quote process from 20 minutes per asset to 90s per asset. I can literally go to the truck, come back in and say, okay, here's the quote where it used to take me a week or two to get back to somebody about what it was. Right. And in an emergency situation, time is of the essence. So, yeah, I totally understand why a salesperson would adopt that. Nursing is a little different in that everything. My software is always interrupting their existing workflow. And it they can they can very rarely point to something and say, oh, that saved me 20 minutes. Anyway, I'm babbling a bit, but I'm curious about your thoughts of black box pricing and the idea of that. Well, it just is what it is. I've got a chart back at my office that says for this revenue, your revenue. This is what I charge organizations of your size. But the most I'll say to you, Mr. Customer, is, well, for organizations of your size, this is what we charge. What are your thoughts on that?
Lee: I think we may see more of that. I think we may also see more business unit type pricing, not just this outcome based pricing as we move into AI. And by business unit, I mean per office or per team or per per location. And I think that's similar to what you're talking about. It could be per revenue tier. It's a little different, but a little related, I would say. And so it's it's black box in that this is just what we think our software is worth. And we charge for every x that your company has. And that's just the way it is. I, I think that's better than user based pricing, seat based pricing in the AI world, in the AI future, because you're tying to some unit that produces positive outcome for their business. And I think that's better than seat based, because it's not necessarily going to diminish as quickly in the AI future. I still think outcome based pricing to me is is fairly like people worry about nickel and diming their customers. And I get it. And I think usage based and this is one of the different like usage based versus outcome based. They are very similar, but I do think there is a tangible difference and that's in that usage base can definitely feel nickel and dimed and it's really hard to communicate the value. I think usage based works really well with like API products or technology platforms, things like that that are not necessarily customer or like user focused. They're a little behind the scenes, and technical people can understand how the usage of this product is leading to value for them.
Lee: And so it makes a little more sense. Outcome based is is less about how much you use the product. And that's why I mentioned earlier like in the in the case of a quote, they can play around with the product as much as they want. They can add as many assets as they want to a quote to begin. They can remove a bunch, they can add more, they can play around with the dials, etc. there. The credit isn't consumed until they hit this thing is finalized. I've got approval from my manager and I'm sending it to the customer or the prospect. And that's at the point at which they are achieving the outcome, which is tied to the value of their business. And and all of that usage led up to it. But we weren't charging for that, you know, that that usage is free. That's a value to the to the person using the platform. And that means no nickel and diming. And whenever you're talking about pricing, you're actually able to tie it to that outcome more directly. And change the subject from this is going to cost you X amount of money to this is going to generate you X amount of revenue. How can you not be willing to pay a 10th of that? You know, if I give you a dollar and you're going to give me $10 back, I'd be insane to not do that as many times as I can.
Tom: So in health care.
Lee: Yeah. So.
Tom: They spend money to save money?
Lee: Yeah. So that's the way I look at it. And what we're trying to achieve is make that discussion about pricing easier to kind of redirect the conversation from. This is going to cost me how much money to this is tied to X amount of outcome in revenue for you. And so this ROI just makes sense.
Tom: So This makes me think about a couple of things for existing clients. So to go back to the client who prevents falls in hospitals I mentioned how the CFO or some other green eyeshade person would want to get the videos of all of the falls avoided so they could audit that. But if that video stands up, you know, it's like, wow, these are legitimately avoided falls. First of all, I get bored watching it. And secondly, after I saw the first ten and they were all obviously avoided falls paying $700 per avoided fall would feel like this is a bargain, right? You know, if my normal costs are somewhere between 1500 and 35,000 if you like, $700 in avoided fall would be wonderful.
Lee: Right?
Tom: And and, like, I had a boss who used to talk about on the invoice wanting to show customers exactly what they got and how much money they had saved in that month as a result of getting the invoice. I've never gotten an invoice like that. You know, I can't think of one in a SaaS product where somebody said you saved X amount. It's a cool idea in in theory, but it also it comes back to the complexity about now I want to start arguing with you over what's in this invoice rather than just paying the darn thing. Which is really all I want out of an invoice is for someone to pay it. And so I want to give you a scenario for another client that I have and ask, based upon what you've learned about this, how you might charge for it. So their service is called Never ending support. And so the company provides support for technologies that have gone end of life. For instance I'm going to get some of this wrong, but it's like dotnet six recently had a critical security event. And it's for software which is no longer actively supported. So they do this for a lot of open source stuff. And how would you price for a service that says when you have us installed, when there are known issues with end of life software, we will get you a patch that addresses that known issue within X amount of time. So it's a little bit like car like insurance. Tell me, are you how you would maybe price something like that?
Lee: It's interesting. I, I mean, it it sounds like every time I produce a patch is really where the value is. And so that might be the place to start. I think, yeah, I think, I think that's where I'd start. I mean, it might be as simple as that. And and maybe that means the better you are, the less you make. So maybe this isn't a great pricing model for for that situation. And maybe it's about monitoring as well. I think the it doesn't have to. Just like user based pricing isn't a one size fits all. You can use this in combination as well. There could be a platform fee plus an outcome fee, for instance, which you see in usage or in user based or seat based pricing all the time. You see you know, here's a flat fee to gain access to our platform. And then you're also going to pay X amount per user. Or maybe here's a per user fee. And then depending on the features you want, then there's a tier a good better, best situation where you pay different amounts or access to different modules charge different amounts per user, things like that. So I think you can combine this idea for in different situations. So I don't know. I mean, I definitely am not saying this is the future of every pricing decision in the world. But I would start probably there with just every time we provide a patch.
Tom: I like that a lot. So that brings a number of bills for me and basic conversations I have with this client. One of them is that they have a they, you know, what they say is the most comprehensive, updated library of end of life open source software anywhere. And that their orders of magnitude larger in terms of that data set than anybody else. And a problem that they have is cross-selling within their existing customers. So they get a call from a prospect saying, oh my God you guys support AngularJS? When? End of life. And we need something to support that because we're not ready to move off of it just yet. And but they they don't. The guy who buys the angular is not the guy who's going to buy the net. Or Java support or something like that.
Lee: Yeah. Different teams are doing different work and yeah, working with different technologies. Yeah.
Tom: Right. Exactly. So the problem they're addressing is what do you do about end of life? How do you manage that risk? And I think your concept of like, well, you have a platform fee, which maybe gives you access to a scanner. And that scanner is directed points to our library of end of life software to really help you identify what you've got across your entire organization. And then you decide yourself what patches you're going to buy. And so you might only pay us one time to get yourself totally up to date from a patch standpoint, and then you can decide on your software about which ones do I want to continue to patch as additional vulnerabilities come out?
Tom: And so then then they're starting to think about the entire organization rather than sort of one crisis at a time.
Lee: Well, and we're talking about tech debt which is always about risk mitigation. And so risk mitigation I think is really hard to monetize. And so in general, I think, I think the platform fee makes sense to me because it's, it's access to a feeling of security, a feeling of I've handled this risk, I've mitigated this risk. And then every time that I, I see a positive outcome from this risk mitigation, then I'm going to be charged again. But I know that that is tied to real world value for me. I've, I've I've prevented another risk. I've prevented a more acutely defined risk than this general kind of risk of I'm just going to ignore this problem in general. You know, so that's a really interesting problem. I've never worked in tech debt type space before, so it's fun to think about.
Tom: Well, yeah, because I think nobody wants to spend their resources fixing old problems. You know, I'd much rather add a bathroom to the house than fix a leaky faucet. And so if somebody else will take care of the faucet for me, and I get to do the fun stuff about adding the new bathroom, right. So let me shift gears a little bit from pricing and talk about kind of AI in general. And I mean, there are there's certainly buzz about how not just seed pricing is dead, but sass is dead because of AI. Everybody's going to build their own apps. Do you have an opinion about that?
Lee: Are you referring to how, like, people talk about AI is going to be able to generate a UI for me? And I just say, I want to do this, and then it just gives me a tool to do it. And then we don't we don't need software companies anymore. I, I think in B2C that might be possible. I think in B2B. That's a long way off if it ever comes. I think that there are certain challenges with B2B. One interoperability. Interoperability of data. There are challenges with training of the users. If we still have users of software in the future then I think that remains a concern. Now, if we get far enough into the future, maybe we don't have people using software and then yeah, sass is dead. But as long as we have people using software in some way, then or wanting outcomes from software, I think in the B2B sense that's going to be much harder to achieve. And the reason is I mean, just those two factors alone, the interoperability comes to play whenever it's, let's say everyone opens up their their APIs and makes it possible, you know, they have an MCP server so that the LLM can interact with the data. It becomes more possible to move in this direction, but you're still going to want to have these outcomes be continual, not point in time, people. They're like levels of agency within people. Within humans, there are certain people that have a high degree of agency and people with low degrees of agency, and people with low degrees of agency are the majority of people, in my estimation, in my opinion and anecdotal experience in life. People don't know what they want, when they want it or how to go achieve it. And I think this idea of, well, I'm just going to tell the LM what I want and it's going to provide me a tool. You're really expecting everyone on Earth to be a product manager.
Tom: Right?
Lee: Like that's just not going to happen.
Tom: That's right.
Lee: And and so the most people don't have a high level of agency. They don't know what they want when they want it, and they don't know how to describe it. Even if they know I want to be able to do X, they don't know how to describe that. And so you have that problem. I think that's a problem in B2C and B2B. But then whenever you get to I have a team of people that all need to achieve the same type of outcome. Why would you want LMS producing different experiences for each of them? Then you have different. No one knows what's going on. Like this outcome was produced in this way. This one looks different. Why does it look different? I don't know. That's just because Bob said a word differently to the Lem. And Sue said, well, I want it in pink. And and Bob said, I want it in blue. And now all of a sudden your, your customers are getting different outcomes from your business. So I think consistency across the outcomes is important. And also training those individuals, if you just hire someone into your team and say, hey, we use this tool, or hey, we use LMS to produce this outcome, they're going to be like, wait, what? I don't how do I do that? Well, you just talk to it, but I don't know, like, what do I say to it? Yeah. How do I talk to it? How do you train in a business for that experience? I don't I don't think it's possible.
Tom: That's really interesting. So it makes me think about there's a bakery here in town that I've been going to for years. And one of the things that I've noticed about it is that it's always the same that the when I buy French sourdough, it always tastes the same. And that's not easy to do. I mean, it's somebody who, like, you know, likes to make cookies occasionally. One thing I like about it is that mine are always all over the place. They're they're never quite the same. And so I'm thinking about if I was a baker and I was trying to explain to an LLM how to how to make the French sourdough loaf. I couldn't talk my way through that. And even if it was like, oh, well, we'll put a camera on it and we'll put a listening device on it, and it'll have all of these sensory inputs. So there's there's two different theories of AI that are somewhat in that are very much in tension with each other. One of them is the concept of a large language model. And the other one is this concept of a global model. And so the, the large language is looking for patterns in gigantic sets of text. And the global model is like, it's not about text, it's about being able to actually see the world and to draw inferences from all of the information that you collect from looking at the world. It's I'm going to get this wrong, I'm sure, but it's a little bit like Waymo versus Tesla in terms of self-driving where it looks like Waymo's ahead, but it's got the the funny radar on it. It looks stupid. But it does seem to be safer than self-driving in a Tesla. And they're attacking the problem from two different angles, right? And so I forgot a little bit about where I was going with all this, but it's.
Lee: LLMs and…
Tom: Globals. That's right, that's right. It's just sort of like, where is software going in general as it refers to AI? And I think the answer is we don't know yet. And but number one, we know this is like if you're charging based on seats, that's, that's going to that's a burning platform. You should get off of that.
Lee: I think.
Tom: So. And I think the second thing is, if you're not using if you're not vibe coding yet, you need to start vibe coding for sure. Yeah. So what sort of vibe coding are you doing?
Lee: So at work, you know, been working with the engineering team to develop new processes to to make it possible to, to use LMS in, in coding and, and so that that work is a little more structured and and we need we need some frameworks around it. And so working with the teams to, to experiment and then solidify those processes, I think I was, I was working directly with a small team of engineers to develop these, you know, to experiment. It was a little bit of a. Tiger team, as they say, to go off and solve a problem. And we we had such a short amount of time, we really needed to use coding agents to help with that and get to the the outcome that we wanted faster. So that's, that's at work and more, more official In my personal life, I've got a like a passion project called Spun It. That is a way for really. I built it for myself. It's a way for me to track the records I spin, the ones I listen to and I like. It's just the type of nerd I am to to want to track that and understand my listening habits. And I can't code. I'm not a developer, I don't I can look at HTML, I can write HTML, I suppose, but that's not exactly coding. I can't write JavaScript or C plus or Swift or anything like that. So but I have an app on, on the Google Play Store and also the Apple App Store, and that's via a no code tool called Flutter Flow that I've been using. But also that's limited in some ways. And I do use vibe coding for creating specific functions and and cloud functions to achieve certain processes. So that's more of a just a hobby of mine.
Tom: Did you learn something from that?
Lee: I did, I mean, I think. This that world was, was new to me in some ways, of course. I've been having technical conversations with engineers for years. Not necessarily. You know, this is the way we're going to solve this problem. But what are the ramifications of this technical decision or that technical decision, especially as it pertains to the user experience or the time to finish the effort the effort necessary to achieve this goal. But this gave me, even though I wasn't writing the code myself, it's almost talking about creating kind of software experiences out of nothing I had to understand more about the data model and more about the business logic. And how do I want to get from point A to B? When do I want that function to run? What are the inputs to that function? What are the outputs? What am I going to do with that? How am I going to present it to the user? These are all things that I had been in the conversation for, but not making decisions about not determining myself. And so I definitely learned a lot about data models and really the inputs and outputs to different parts of the the platform. I'm probably doing a lot of this wrong. I had to think about security.
Tom: Who thinks about that?
Lee: That API keys and and things that I've definitely outsourced to the engineering team in the past. So I definitely a lot of learnings.
Tom: That's very cool. Well there's lots of things I could talk about. Probably ought to get back to the day.
Lee: It's always great to talk to you, Tom.
Tom: It's great to talk to you.
Lee: Are a lot of fun. So I appreciate it.
Tom: The Fortunes Path podcast is a production of Fortunes Path. We help service and technology businesses address the root causes that prevent rapid growth. Find your genius with Fortunes Path. Special thanks to Lee Bridges for being our guest. Music and editing of the Fortunes Path podcast are by my son, Ted Noser. Look for the Fortunes Path book from advantage Books on fortunespath.com. I'm Tom Noser. Thanks for listening and I hope we meet along Fortunes Path.