AA167 - How to Manage Products & Services Together in Your Business

welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. Okay. Welcome back to arguing agile. I've been told several times now by people well, our organization delivers products and services. And we're, because we do that, we are unique and whenever I hear that as a product manager, I react like they just kicked my dog. I probably should get better at that. I said, what I'm saying is that's a personal failing of my own. That's what I'm trying to tell you. And react like they just kicked my camel. Everybody thinks that company is unique, just because they have a mix of products and services. So in this podcast, we're going to delve into how companies deliver these. We'll look at some examples of companies that do these and maybe some models on how they're organized and how to deliver. So the products and services together, After I got over my initial terrible reaction, I started really thinking about it and saying. Are these things unique? Because even when we talked to the networking event, we went to, I brought this up with a few people that have been in their careers for 20 plus years and said this was pitches unique. But in the early two thousands, when I started my career, I recall most companies delivered a service and a product. In parallel and did it fine, like a normal business. Yeah, I mean, before we go much further, let's just define what we mean by these terms, right? So a product is something that you can actually feel in touch. As, as opposed to a service, which you can experience. But you may not be able to see or feel. Yeah. So let's, you're right. Let, let, let's stop and spend a couple of minutes, maybe five, 10 minutes and talk about how the product delivery is different than a service delivery, organizationally speaking. How are they different? So again, I I'm product manager on the podcast, so in a normal product operating model. See what I'm doing. I did the money. I saw that. I didn't say, I didn't say agile transformation. I said product operating model. The complexity. So if you're, if you're just delivering one product, one product line, you have one, maybe a couple of teams that deliver that one product and you're, and, and if you, let's pretend you're B2C software for a second, that's probably the most pure product delivery model that we can think of. You have a product. You push things out, you're kind of measuring how your users are, are, are responding to the, to the new features and you know, the new things, the new capabilities you're pushing out in your product and you're asking people what they want next and you're delivering new features directly to users. That's B2C straightforward. It's just a product. there's no additional services offered, right? This is like Facebook, for example, like you don't like the way Facebook does their timeline. What are you going to do? Like a tweet and Mark Zuckerberg and say, you don't like it. Like that's, that's it. It is what it is. Yeah. It's a transaction. You know, you give them like Facebook's a bad, bad transaction because you don't give them money. LinkedIn, for example, like you don't like the way that LinkedIn you don't like all the bots that you interact with on LinkedIn. I was going to say AI generated content, but maybe that's too close to home for a lot of people that might be listening to this. You know, you, you want LinkedIn to clean up all the AI generated content. So it's more like. Yeah, good luck or you just want linkedin to give you a few more emojis in the five they give you Yeah, you're right. I have to do emojis on my phone when I post to linkedin then it then it gives me It's like Aladdin. It's like a whole new world of emojis. Yeah. So I look, it doesn't matter what you know, product or service you think about, right? Ultimately it comes down to this. What is it that you're bringing to the market for your customer? If it is a tangible product, then okay. That's a product. Are you just simply delivering the product to the customer, right? Or are you offering some kind of experience for them as well, right? In terms of getting that product institutionalized within the customer so they can actually get maximum benefit by providing services of some kind. You know, the, the one that we talked about at the networking event, we were talking about this was the buying computers from like IBM, for example like back in the day or Dell or whoever you buy computers from a, from a specific organization. And then they would dispatch text to install the computers at your local site, assuming you didn't, maybe you didn't have corporate it to install 150 new PCs, the company that you bought them from the product would be the PCs that you bought, they go on your CapEx and you amortize the PCs over a certain amount of time. However long you're going to use that equipment until, until the value goes to zero, and then you got to go buy new corporate equipment, but the company would send out text to install it for you or to, maybe it's not like Dell laptops or Dell desktops. It could be mini computers or mainframes. But it might, it might be something way more complicated that now the service team has to come out and like help you understand the new machinery and spin you up on the new machinery and how to operate it. You know, yeah, networks, which is a little, I mean they were complex things, right? So definitely that's a good example. Nobody actually ever got fired for buying IBM. And over time, I seem to recall IBM transitioned from being a product company to a services based company under Lou Gerstner. But anyway, let's come back to that, right? So if you've got a company that is. Dispatching you boxes of some kind that you can touch and feel as products and then they're also sending expertise To basically help you use those things by installing them, training you, et cetera. So those are services. And overall, you may hear the term referred to as a solution, right? Which is a product plus a service, right? That's how we used to talk about solutions, right? Back in the day. It was a solution has a product component, has a service component, maybe multiple products. Yes, of course. A family of products, perhaps, and services too, for that matter. You may have installation services. Yeah. You may have commissioning services. So these people coming after the installers have gone, and then you would have operations or operationalization or support services, right? So services can also run the gamut. So if you have that as offerings from your own organization, what are you? Are you, are you a services company? Are you a product company? Are you a solutions company? You're both. You're both. Yeah, you're probably, well, I'm trying to paint the two swim lanes. Operating together synchronously, operating together synergistically. There's one. Nice word. There's one. I haven't said on the podcast. Yeah, that's a good nineties word right there. Synergy. They, they, they're, they're not silos that are separate, which, which I will present later in this podcast as a, as a model and we get to management models. Yeah. But we're, we're, we're on the differences category now. No, a big difference that I feel pushes us into This whole feeling of being unique is the revenue models. Like when I started this with an example of the product only model of B2C. So we sell directly to consumer, the consumer pays us a subscription costs or something like that. Netflix, for example you know, there's no service component, like the service is the product. You pay a subscription costs, you get access to the platform. Right, which some people might listen to this and be like, wait a minute, Netflix is a service. Actually, it's a platform you can get access to. In the old days, Netflix had a service where they shipped you DVDs. They did, and that was a service, and they got rid of that service because the revenue model, let's talk about revenue model, because I wanted to jump to scalability right there with the Netflix example. Actually, you know what, no, let's jump to, let's jump to scalability because I feel we can hit scalability. In two seconds and jump back to revenue model because the revenue model of this, of the people engaged in offering the service versus the revenue model of the product product. Is infinitely scalable. You, you, you can say, I have this platform and you know, as long as obviously there's some technical hurdles behind the scenes that the, the, the product has to be self scaling. You need some technology, you need some know how to do that. However should it be implemented correctly? The product is self scaling. Therefore you should be able to onboard an infinite number of users to your quote. Service, which I really mean product when I say service, right? When I'm talking about Netflix, the service of we're going to mail out DVDs. Now, everybody that mails out a DVD, I mean, there's, there's a person that stuffs it in an envelope or an envelope depending. And if you say, well, Brian, we can just have a machine, stuff them in envelopes or whatever. Okay. Well now you've got to maintain machines and you got to have that people that maintain, again, like the service just got more complicated and more automated, but you still, the service requires an investment of capital to keep it running. There's an R and D cost. Now we're going to get into later and a maintenance cost to improve your service or, or you can just say, you know what, it's not worth it to, to burn all this money and to figure out how to send out more DVDs or whatever. What happens when over two, three years, there's more streaming competitors and you're sending out less and less and less CDs. So all these machines and all these people and all these teams and local regional areas dwindle. Now you gotta, what, you gotta recut fire people, basically, from your services wing? Precisely. I mean, there's a lot of sunk costs right there. That's terrible. The scalability is the, I mean, that's the easiest to understand. Side of both of these conversations of the, how are they different? Okay. Well, the product side can basically scale infinitely or, or contract. Right. It's either, or you can cut features left and right as people don't use them. And you're basically contracting your software, making it easier to maintain. We don't talk about that. We should have a podcast on that one. MIT simplifying your software, basically cutting features that don't get used, simplifying your code, making it easier to maintain simple simplification as an art. In software development. That could be the podcast that's on. It's a great podcast on, on tech debt as well. That's a great podcast. Yeah. But but yes, the scalability thing, scalability of services versus the scalability of the product completely pretty apparent. We don't need to spend a lot of time on that revenue, though. Again, the B2C product, the revenue is. Like that's the Netflix model. People pay Netflix, they get access to the platform. On the platform, they can watch any movie, TV show, whatever they want, right? Services model, completely different. Now you have billable hours. Now you have project based fees. Like we were talking about, oh, I'm gonna send a couple techs out to install 150 laptops. Or 150 desktops at your organization. Like I know how long it normally takes to install 150 laptops or desktops or whatever. Like now you're talking about man hours, right? How many team sizes you have to have? How many consultants you keep on staff? Whatever the labor costs, it's a completely different model. Now, whereas in the software, in the, in the software development tech model product, the product management model that I, that I'm used to I know my team is like, I've got six engineers. They cost this much money. This is a run rate of my team. This is how much I burn every this is how much my profit is. My P and L is pretty static. You know, and I'm just looking for those dips and spikes that indicate we something isn't going right, or something's going really, really right or whatever. It's, I think it's this is probably where they're most starkly different. Yeah. I think on the labor side of things, your challenges are cause you're dealing with people here, right? So you have labor shortages, people leave all of these sorts of things. New people come, you got to train them up before they can go install these laptops or desktops or whatever. So, so the scalability is less than linear, smooth, right? When you're talking about ramping up. Yeah. To the next level with services, I'm saying. This is where smart companies are looking at self service, right? So you're selling the product and then you're enclosing with it some things. You remember buying laptops that came with the readme guide, a whole bunch of bloatware and whatever else. People can help themselves. So you don't have to do that. Services. Yeah. Inclusion, right? I recall a company that I was at launching a mobile product for the first time there was a, it was a company's foray into B to C. And I remember the company just being completely over their heads because people had problems with the software. The software was not as user friendly as a company expected it to be. And there was like we had to implement features that allowed self service. Yeah. Very quickly as a product team, because the team that maintained the service was just overwhelmed. They were just overwhelmed with the customer response. So we had to come up with some sort of way to take the weight off of that, that piece of the organization because we had no self service at all when we launched the application. You know, self service support type of stuff. Right, right, right. Everything we're talking about gets insanely more complex if we're talking about B2B to B2C type of environment. Yeah, it does. Another big thing that should be easy to communicate here is the relationship with the customer is different between services and products, again, the main B2C product that I keep talking about, keep going back to. It's a very transactional. Relationship with customer you do your thing and if you can't get through your thing, then I need to help you or whatever, or I need to figure out how to make that thing easier that, that, that transaction easier. And then we're off to the races. You can get through the thing yourself. You don't need anybody's help. Yep. Whereas on the service side it's, it's longer relationships. I really need to get to know you and what you want. And you know what I mean? I'm, I'm trying to, there's a personal touch basically is what I'm saying. Yeah, absolutely true. Longer as well as because services involve that experience for the customer, you got to be careful as a provider to make sure that the customer is pretty happy with the experience they're getting. It's no longer enough to just come in and check the boxes, right? Because that's your. I think of a company that I was at one time that did all of their IT projects, quote projects, with contracted offshore labor , they basically, they contracted firms to do all the software development, basically. And they had a cadre of project managers that would maintain relationships with these vendors. So basically they could go to the vendor and quickly spin up a project when they were ready with funding and all that kind of stuff. I'm not like, I'm not trying to critique the, the, the model that they had, like it worked for them. But those maintaining those long term relationships with all the vendors Yeah, I think that that model is pretty old, actually, right? That's been going on for quite some time. And with the technology and everything now, it's different because it used to be that these vendors would have to send bodies on site. to the company that's contracting them. And now people are just working remotely. And COVID had a lot to do with it too, but yeah. So that is an interesting model because here what happens is you're basically hiring bodies to do the work of the project. And when that project is done, you spin down that team and you know, either they get redeployed elsewhere or. They don't, but they're not on the team anymore. And so the downside, if you're in a solutions kind of situation is the customer doesn't have continuity of the service and therefore there's a corresponding gap, right? You may have some ops people that pick up the slack, right? But those people are typically boarding later in the game. So they don't really have the relationship to start with. They also may not have all of the experience they need of and knowledge of the product that they're now supporting. we often discuss and debate. Organizational styles and management styles and org design on the podcast. I think now's a good time to hop over to talk about how these companies that have both the services component and a product component, how they kind of manage this. Right. And the, the, the first thing that I've seen, actually, I think the majority that I've seen is they create, silos, like the product org is over here and the services org is here and they don't really share people between the two is just all the services that happen over here and all the products and stuff happens over here. That's pretty much accurate. Most of them are like that and never, never the twain shall meet. So you've got all these product people that have product knowledge, that's their baby and it's and that's great. And then you have services people that hopefully are trained in the use of the product, but yeah, and you have churn. So these people don't have in quotes, they don't have ownership, right? They're there to basically do a job and that's it. Well, they, they'll onboard and they'll get trained in the product. product. Well, when I say product, we're not bashing on these organizations. They, they, they, they're great examples of products and services. So we're not gonna, we're not really going to critique any of these organizations, but we'll look, I only bring it up because our working agreement I mean it's kind of goes against the working agreement, but we're going to give some examples later in the podcast, but organizations like this that have that have both a services side and a product side pretty clearly. But The separate product and service unit, like I think of like a company that we talk about when we were brainstorming for types of companies earlier before the podcast started, we talked about car dealerships, the relationships of car dealerships to the car manufacturers. For example, if you're, if you're a BMW and you manufacture your cars, like the, the, the actual dealership selling the car and selling services around the car. The dealerships buy the car from BMW. They buy the car from the, from the corporate head, main entity of BMW or whatever, BMW America, whoever they bought a car from, basically they buy the car from BMW and then the, and then the service provider, which is the dealership is reselling the car that they got from BMW, basically. I know it's not really truly, but they're also offering services on that car that they sell to you, the user. So they're providing like the product that they're providing is provided by their product provider. And like, this is a great example of the silos that I was talking about. The individual dealer, how much input do they get into the new models of cars, the types of cars, user preference, what types of trends that users are gravitating towards, stuff like that. Some of that, some of that feedback probably filters, I mean, they probably have mechanisms that filter that feedback back up to corporate BMW, for example. Headquarters, I guess. But I, I just don't know what, what that looks. I don't know anything about the car business. Right. But I like what that looks like, how much pure feedback gets directly up, how much just comes from metrics from the dealership and gets passed up or does it get filtered first, I have a million questions. Yeah, I mean, not a lot of there's not a lot of feedback on the direction of the product necessarily. There's probably quite a bit of feedback on the quality of it. The customer's experiences, right? They look at the top 10 reasons why, or top X reasons why. Customers are bringing stuff back within the warranty period, things like that. So that can improve the product. But as far as feedback towards new product direction, I don't know if there's a whole lot. That's very interesting. So, so the service provider is gathering metrics and statistics. Off of the things that they do and funneling that back to the product, basically the product manager. Let's just pretend this is a tech company for a second. The, the service providers for different like this would be like the localities would be like different customers. You know, you'd have your Denver branch and your Tampa branch and your Philadelphia branch or whatever, right? I'm sure they have hundreds and hundreds of dealerships for this particular car brand. But they would all be funneling. Information that may be local to them, some branch in Connecticut or wherever, or in New York or wherever, somewhere they salt the roads, I don't know where they salt the roads anymore, pretty much everywhere up there, they might, they, they, they would have concerns that they're filtering back to BMW headquarters about like, Oh, the undercarriage of the car and how it performs in these slick roads after snow or whatever, that the people in the south in Texas or in Florida or whatever. Okay. You would never get that feedback from them. You're absolutely right. So is, is corporate taking the complaints is the service providers are hearing on the ground and the problems that they're detecting. Right. Again, assuming they're aggregating all their reports. I guess that's an assumption. Assuming that their systems all feed into one place. Oh my God. And go back up to corporate logical, sane manner. is product quote product, which is corporate in this in, in this, in this example, are they actually using the feedback to determine their roadmap and change their ideas and test things and whatnot? I think they, they probably are looking at the feedback pretty closely. I have visions of people in those circular towers in Munich getting together and saying, The undercarriages are rusting. So how are we going to fix that? Well, we will sell them the spray that they put on underneath for a thousand dollars, for example. So I'm sure they're looking at feedback. It's, it's up to them how much of that they incorporate, because he's coming from individual areas, like you said, right? Well, what what are the models? So I brought this up because this is a perfect example of the two models is there's a silo for the product. There's a silo for the services and they kind of have to it like this whole thing breaks down if they don't talk to each other Absolutely, right because some dealership in Some place in Alabama or wherever in Texas does what they say? Really get back to corporate to the product manager that makes a decision. You know what? That complaint we're gonna solve that in the next version of the product, somebody really has to be paying attention to the data and really doing a good job in the silos for something very specific jump from silo to silo. Now, if it's like a very broad sweeping problem, sure 90 percent of dealerships are saying that the alignment becomes a problem over a certain mileage or something like that. Maybe we should build strong components or whatever. The other thing, a silo model, like you have like a chief product officer and a, and a chief services officer, they wouldn't be called the chief services officer, but it would be like the chief of Customer experience, something, yeah, something like that. And I'm less, I'm less interested in talking about that one. And I'm more interested in talking about like the matrix structure where you're, you're people delivering a product line, like pretend, pretend for a second that BMW had, they didn't have like your dealerships and your corporate product that just produce the cars. And they didn't talk to each other. Pretend they had like. Matrix structures where some service providers and some car line manufacturing professionals and like, like they were all part of one team somehow, where the design and production and maintenance of a particular car line we're done in a, in a horizontal altogether or I guess a vertical, I don't know how you look at it. So I'm kind of turning it this way. Like they were all done by one team is like the same people that designed and created the car also are tracking that particular model. To see how things downstream, you know what I mean? Like how would a matrix kind of hybrid approach work? Yeah, I think, I think to your point about that, it's probably best if that kind of a model is, or not best, but most likely that that kind of a model is aligned to like you said, a product line, maybe trucks or maybe convertibles or SUVs or whatever, because then you can concentrate your expertise without having to. Look at everything under the sun, right? That that particular company offers. But even then, I don't know if that's pervasive, really. I mean, in this example with, with car manufacturers, I don't know if that's pervasive. Yeah. This is probably a bad example for this because you like you go to the dealership and it's not like, here's the truck side of the dealership. Here's the sedan part of the dealership. Here's the SUV part of the dealership or whatever here's the particular model part of the dealership. They they just don't do it that way. We probably could brainstorm for other, maybe pharmaceuticals or some other businesses that, that are more like this, like aircraft manufacturing maybe would be like this, like the, the large Passenger jets, the cargo jets, the very small personal jets. Like those are segmented where even different companies are in different verticals. Yeah. Those are very clear segmentations, right? Right there. You know, private jets versus the commuter jets or prop planes, right puddle jumpers or whatever. Yeah, that, that's a good point. But again, even in that environment, right. Do you really have a matrix situation? Maybe you do from the standpoint, standpoint of maintenance folks, because they have to specialize in certain models. So maybe you have that, but as far as I don't know if the customer experience piece of it, right? I don't know if that's really valid there. Yeah, I don't know either. This is a weird one to talk about because I'm trying to make a point here. It's super clunky. In a typical product management company, product only, like let's go back to the B2B Brian homes, mobile development. Company, right? We produce B to B. Yeah, we did. We have B to C mobile games or something, right? The most addicting mobile games on the internet. You get to keep giving us money for in that company, we really believe in a matrix structure, right? Okay. Well like Ohm is the customer experience and a user design expert. He, he hires all of the, the support people and the, the, the user centric you know, user touching people, the service people. And then Brian is a developer and I hire all the development backend folks, right? That's a much better example, I think, of where you can have that kind of a hybrid environment in place, right? Because one cannot succeed without the other. One cannot live in a silo. Right. By itself, really. I mean, otherwise the company's gonna go under pretty quickly. So that's a, that's a much, much better example. I think if you're just looking at the B2C without the experience or anything like that, the services piece of it, you can think about the FM's fast moving consumer goods. I'd say a company selling, making and selling peanuts. Yeah. In cans or whatever. Right. Not much services there. I mean, they produce these things and they sell them off to somebody who then sells it off to the retail people, right? And the consumers buy from there. There's really no services involved. As opposed to anything that requires focus on the customer's experience in using the product, right? Which is coming back to that example of mobile games. You want to make sure that the customers. Continuously keep subscribing and buying things and buying things off of the advertisers, perhaps that you put in there. So you get a slice of it every time. What I'm trying to say is I'm trying to prevent us from slipping back into the silo model for managing an organization like this. And it's very difficult because if I say, okay, well, I have a matrix structure where all of the product lines and product managers who manages product lines, they have to work with the service managers for each different service. You have ongoing swim lanes of services, okay? And the product managers intersect vertically, potentially, right? Maybe some services don't use every product line. Sure. But, but for, for those that do, the product managers intersect vertically with, with all those horizontal service deliveries. To say, Hey, our service is delivering a little bit of column a with your product, a little bit of column B with another product, and then none of column C with this other product. Okay. And then another service line might be only column C, right? Heavily dependent on what the product delivers in that, in that one. So I feel the matrix structure could work as long as the service delivery people and the product management people are both talking to each other in unison. And I would, I would assume that you're going to have a, just like you have. For a product you have sprint reviews I would expect you have service, some kind of service delivery reviews, maybe weekly service review. I don't know what the right cadence is. To say like, Hey, here are all the customers that are using the service and here are all the things that we're planning to deliver. Here's the things we really need from product. Here's the here's where we want to grow the service, but you know, maybe we can't cause the product roadmap doesn't do it. Or maybe we don't have enough money budgeted, or maybe we need some R and D or whatever. Like managing the service, I only bring this up because we did an episode on service delivery. Yeah. And I, in that episode, I wasn't sure. About how service delivery worked. I also feel that most people are not sure about how service delivery works. Because exactly what we're talking about is that there is an intersection of the swim lane being the service and the products that are enabling that service being the vertical that intersects. Yeah, so I, I think what, what is important here is that this is segmented appropriately, right? To your point about the first part using three columns one, maybe one, or so it, it can't be all and sundry to everything. Yeah. So if you're a matrix organization, it's not like you have all of the services, people over here, product people over here, and you could just combine them at will, right? You have to pay heed to what kind of product you're delivering and get the right skill sets from each to stay together for long enough of that product life cycle. I like where you're going. Like you, you're, you're throwing salt on my very confusing wound because like maybe where they meet with the, the vertical, the product and the horizontal, the service, maybe you could. Take people for however long that, that, that service goes or that the products and service meet together. Maybe you could take people and just dedicate them to this particular. solution for as long as we maintain it. That's exactly my point. Exactly. So you don't want to keep moving people in and out, right? You want to keep people together for the duration of that product life cycle, if possible. That's why my brain is pushing me back to silos to this. Cause I think the majority of companies. Would, especially if you're in a silo and you know, like your chief product officer owns all the product people and your chief solutions officer owns all the solution people or whatever you would want to move here. Like, I don't want to I don't want to keep my solution people on this one thing in the same solution, people can't move to anything else because maybe they're really experienced and I don't want to trap them there in one place or whatever, while I'm delivering this solution, they want to move their people around. So they see. People is like interchangeable cogs. They don't see them as this person is going to manage this customer relationship and stay on this quote project. It's not really a project at that point. It's delivery of a service to a customer forever, basically to maintain a level of service forever. And that is the slippery slope though, right? Cause people in that, in that kind of an organization structured in that way, I should say, right. What they're looking at is where's the biggest need? Who's shouting the loudest and we're gonna take Fred from here, Mary from here, bought from here and just move around because that's where the loudest voice is coming from right now. And unfortunately, that's going to have an impact on your customer. I think of anytime I had to interact as a product team member, I had to interact with customer service like the people actually answering the phones or the people was, I was at a company one time where we had There were more like customer engineers that they weren't really dedicated to a customer, but there were some engineers that, that managed a particular customer that said, when this customer calls for all their support calls, you go to this engineer because this engineer, like maybe going back to the beginning of the, the relationship with that customer, that particular engineer implemented their solution. They know everything about the solution. They know everything about their config. You know what I mean? I mean, you can send it to other people. To cross train sure, but you're still going to need that particular engineer To sit over their shoulder to help them come up to speed. Cause it's their setup, their configuration of the products. And I think about that organization how they handled it. Like the, and then when that engineer left some, some other engineer had to take over their customers, had to learn the configs, had to learn that, that particular customer's business and like really specific needs. Yeah. Likes, dislikes, everything. Yeah. Yeah. That was a service. That was the engineering customer support. Service that we offered where the engineer. Implemented our products at the customer site. That was like enterprise solutions back in the two thousands. Yeah, yeah. This is a model that's again, tried and tested, right. It has worked for some companies that have managed to keep people together for a product line for as long as possible. Otherwise. It's not ideal, especially today when everyone's looked upon as a utilization based resource. Yeah, she's a terrible term. But you know, and so that they look at it that way and say, well, you're not that busy with customer a you can also use. Dip it over here and spend a few hours over here. And that's when you start diluting the quality of service you can offer. Well, the issue with that one is when you start doing really crazy stuff, it's like Oh, I think of like, Oh, I'm dedicated to two teams. Like I'm 50 percent with this team and 50 percent with that team. It gets worse when you're like 25 percent here. 13 percent here, 5 percent here. You know what I mean? And like you really get down to the granular single digit percentages because your service people are just wildly thrashing all over the place. And you're hoping that it's going to add up to a hundred percent. It adds up to way more. I mean, every time you thrash, you're going to spend some overhead. Sure. Sure. Even switching between two, right. And we know this, that switching costs. It's coming to a podcast near you in the future, how you manage each one, like the matrix one is very interesting to me. A lot of, a lot of organizations. I mean, it's even what we're talking about now seems complicated. So I completely understand why people bring it back to the silo model. Right. I, in my brain, I'm having a hard time snapping, not snapping back to the silo model where, oh, all my product people just go back to the product, cheap product officer, you know. Yeah. It's the, I think it's the easiest solution people will grasp at, right? This is how we're going to do things because there's comfort in knowing that all product people can work with the product, cheap CPO. You know what a more interesting management solution is, is, is for each customer you have a dedicated team. That just manages that customer. So you have a few service people, just like I was talking about with the engineers, you have, you have a few service people, engineers, whatever that, that, when that customer calls, they maintain that solution. Yeah. This is the customer centric model, right? So these these groups of people I came across this model in publishing some time ago, these groups of people were called pods at the time. And the way they were located, everybody's working from the office is they had these round. Pillars almost in a very open plan office, and you would have, you would have desks with monitors on them around this pillar. And that was a pod. A pod would typically have five to six people in it. They can all see one another. And they all talk to one another. And when a call comes in for support, for example a senior person would take over the call based on the customer, the severity of the issue that was being called in and the relationship that they had with that customer. So pod was very customers focused at that point. This was an advertising. So all these customers were accounts like Macy's or Nordstrom's that they would take out very expensive large ads in magazines and newspapers. So when they called, you listened and you responded the way they wanted you to respond, because these are your top clients. But that went down the line too. So you had some people that will place ads that are much smaller. This is a sound Morose funeral homes. Yeah. Great line of service for for newspapers because people always will die. So they will take out ads and The difference there isn't just the money right? You have to respond to these people in an empathetic way. I mean, you're basically reporting deaths, right? So it took a certain type of person to deal with that and they put these people together in pods. It worked brilliantly until one day when the Publishing house was bought over by a larger one and they decided this was all some kind of woo woo. And they said, no, we're not doing that now, you know and of course it tanked very quickly, I might add. Customers left in droves for a competitor. Well, again, that's the advantage of the services models. You have a deep relationship that at the heart of this, at the heart of why they're buying the service from you, there's a relationship there. And the minute that they Oh, it seems like. The person providing me a relationship changes a week to week, or maybe I don't like the person that's checking the box at that point. Yeah. Yeah. I agree with that. I think you really have to be vested in that because providing a good service is your competitive advantage because your product could be leapfrogged by another company, right? Yeah. And Your product could get to the point where the market is so flooded that the product is the commodity. Like the product is not special anymore. Yeah, like it is a half a dozen other products off the shelf that you can get that do the same thing, but the service. Becomes the real differentiator. Yep. You know, you, you get the, you get the white glove service, the concierge service. You get experts that can knock out what you like. The engineering service that I was talking about before. Yeah. That was the differentiator for, for, for that company at the time, is you can get an engineer, you can call the support number. You didn't get a machine or AI or Right. Did the id whatever. The IDR what, what's the, what's the thing called? I-D-R-I-V-R? Yeah. The IR You didn't get that, like you got a person. That said, Hey, welcome to Brian and Ohm's software development company what do you need? Right. And then. You're like, Oh, Oh my goodness. Like I have a real person, I have a problem. And then they would say, okay, what's the problem? What software, whatever they would ask you some questions and you can get real service within one hop basically, and get connected directly to the expert and it's your expert. It's the expert that knows your system. That is, that is interesting to differentiate that model from another one, which is. You can still pick up the phone, and you can still talk to somebody, maybe in another part of the world and they're gonna bring out their script, oh, it's on their screen, and they're gonna ask you questions like, is it plugged in, right, come on, right, that, that's not really what this experience is about, the customer already knows that it should be plugged in, I mean, they need, they need to talk to somebody who knows their Right. Right. Business, right? So just having a call center operator answer a phone because you're providing a, a human touch there, that's checking a box, honestly, because then they have to escalate to L2 and even they don't know. the customer centric. Solution like that's super interesting. Like there's a, there's a bunch of other models that we could probably dig, dig in on this one, like the, the geographic model of like when, when Uber wants to expand to a new city, they have to spin up a team in that city to figure out the patterns and the to figure out that how their service is going to work in that city The consultancy led. Approach is also interesting I call it the lawyer model because. I like to think of consultancies like law firms, meaning if I'm a law firm and I'm looking to bring on another partner in my law firm or even really an employee in my law firm, I have a, I have a couple of lawyer friends and they described the field like this, no, like there's a million people graduating from law school every day and every law firm is like staffed to the tippy top with new lawyers. They don't need new lawyers. However, yeah. If they're going to hire you as a new lawyer, they want to know that you come with a portfolio of clients of your own. That you gathered on your own and then they'll cut you in. And when you, when you come in, then now you have a little more say over who gets hired on your own staff. So the more clients that you add to the. Parent law firm that you came in to the more power you get to say I need more people to help service my clients To provide a certain level of service to the clients and then there's revenue that goes with that and whatnot. So I It's consulting led approach, but I kind of think of it as like the the the the law firm approach I think of this for every consultancy That I've ever heard of. I think your consultancy could be better if it was more like a law firm, like with the, with the individual consultants should be their own salespeople, their own BD people. Maybe you have a sales and BD wing of the company that assists the individual lawyers in drumming up business Hey, let me teach you how to better let me hear some tools to help you enable reaching out and tapping new markets, but the more people that you bring in as the lawyer. The more people that can help you in your part of the business so now we are organically growing this. This little law firm into a mega corporation by letting it organically expand, whoever can bring in business and kind of wrap new business in their, in their wing of the firm, like let it expand, let it happen. Yeah. And those other people, like you said, they can take the drudgery out of things like contracts and things like that. Right. That's interesting because what that's going to do over time is it's going to have all the people that are good salespeople drumming up business bubble up right and they'll get cut into your point. This is probably have to buy in to be partners. But yeah So that's what's gonna happen over time Most of the law firms that are out there work in this way, right the bigger ones I would say work in this way. I think about consultancies though. That's why I brought this up. I was like that's That's like a software consultancies, agile consultancies. Well, I guess now, now like they're not called agile consultancy. No. They're product operating model consultancies, pro product coaches. That's what I'm trying to say. That's an interesting model though. I mean you know. What happens when you have staff turnover in that kind of a model, right? I mean, you have staff that this is the reason that there was non competes in the past is exactly for this type of thing. Luckily, the Supreme court actually made a good decision and decided that non competes are ridiculous because they are. But this is the reason why you had non competes is, we don't want you leaving and taking the relationships that you've built. As the service provider with you, which, I mean, if you think about the service, the service is built on you building a relationship. So how can you personal thing? How can you not take those? I mean, the, the, the, the people that are buying the service from your company, not the product, the people that are buying the service from your company, they want to know when they pull up to the dealership when they call up the person on the phone, they're going to get. Jed the engineer on the phone, they're going to roll up and get Bob the salesman at their dealership when they go buy their car that the third, third car in 10 years. from the same dealership at the same place. They want to know that salesperson is there that they have the relationship with. You're, you're buying a relationship in the services model. Absolutely. Absolutely true. This is also, I think, valid in the pharmaceutical world, right? Where you have specific salespeople that form relationships with these providers to whom they're selling drugs, whether it's hospitals or whether it's outpatient centers or even physician's offices. And they have a personal relationship and based on that. The business takes place, right? So when that person who has the relationship as a sales rep, when they leave, they're going to take the relationship with them. How could they not, right? Non competes aside. And then they did silly things like they put geographical limitations on non compete. You can't do this within 10 miles of here. Well, how's that going to work in today's world? Before we go to examples. Of these companies, I want to talk about one additional case, which is R and D research and development R and D. Companies all companies do R and D. They might not have a separate swim lane for R and D. So we, so in our example, we have a, we have a large, like a leadership combine, like all the services products offered by the company. We have a swim lane for products. We have a swim lane for services. Right. And those, those generate revenue each of their own, right? We may have a swim lane for R and D, which may be funded by a special pool of money, a special pool of money that doesn't come off the margins for any particular product line. Now product lines can engage in R and D. And it comes off the margins. It's a tax write down it's, it's, it comes off of OPEX, et cetera, et cetera, like a, that that's normal, normal R and D everyone has to do normal R and D. Like if, if I'm a product manager and I have a at Brian & Om's software development firm and we're building mobile games, I might write a story in my backlog that says go figure out new, um, animation technologies and show me some demos and I'm willing to spend two sprints worth of work this quarter. I'm willing to spend a month of my development team's effort, whatever that was, let's say my development team costs 10, 000 a sprint. I'm willing to spend 20, 000 in R and D money just, just to have a demo of new animation technology. So my, my team doesn't look at anything where any technology you're using now. They just go out on the market, grab new, grab new things, make new animations, show it to me, show it to me side by side with our current animation to see if I want to just leapfrog our current tech. They're effectively developing tech enablers here. They are. I'm paying for that off the OPEX. Sure. Okay, I'm paying for that off the OPEX. It's not amortized. I'm not, it's not a feature that's going straight into the application. I'm paying for that off the OPEX that my OPEX come up comes off of my PNL. It comes off the margin. Okay. And if I'm throwing out a bunch of terminology that, that, that is new to you, you listen to this podcast please comment if I'm going a little too wild here, but the, the, the margin means I have, I have how much it costs, how much revenue comes in. Versus how much it costs to keep the product running in production. Like pay all the salaries of my people pay my AWS bill or whatever, my hosting bill or all that kind of stuff. And then the money that's left over my profit that's left over. So I'm taking a portion of that profit I'm paying for some R and D research. And there's tax implement implications about how I do that. Okay. Or, or corporate might come to me as a product manager and say, Hey, Brian, we're giving you a million dollars. We're going to write this down corporate level. We're going to write it down. We're just writing it down on our, on our taxes at the year, completely writing it off. And it's a special pool money. It doesn't appear on your P and L for your product, but I want you to use this money to spin up a team, to figure out what the next hot game is on the, on the market, B2C, right? So I'm going to use that. I'm a higher couple of engineers. We're going to experiment some things. We're going to experiment on the market, throw the five, six, 10 games out there that are little tiny little games, see which one hits, and then we're going to go deep on that one game and, and, and then when it, when it hits, we're going to pull it in and it'll be its own product line, but all that pre work of figuring out maybe corporate is funding that with R and D dollars. Okay. So I, I, I've spent more time than I wanted to setting up the R and D thing. So this additional lane of R and D services. Can spin up r and d products can spin up r and d. Companies that don't know if it's a service or product can spin up r and d. Sure. And whether you do it on the out of the margin or whether you do it as a separate line item on your budget or whatever. Like some of the ideas of r and d like we talked about earlier Ikea, for example. ikea they wanna offer a new service that says we'll have people from the store, we contracted with people from the store. They'll come to your house and they'll build the IKEA furniture for you. What, what, what cities in America will that service take off in? Well, first, you gotta launch some pilot programs. Pick some cities for a pilot program. Offer it as a pilot you might do that with R& D money. You might pay for all these salaries with R& D money. You know, the real profits are realized by the store, but , you might, you might decide, Hey, I don't know if we need to do this or not. Corporate may decide to do that and not any of the stores. Yeah, absolutely. Yeah, that's very true. So again, R and D can be, like you said, like different forms of R and D, right? But all of that is internal money and it's all basically a. What's the word I'm looking for? It's basically on the cost accounting side, right? You're it's in the it's in the liabilities column at the end of the day, right? Because because it might be just fundamental work that will pay off in the future like like space travel and thinking about there's a lot Of R& D in space travel. I mean it also it might go nowhere at least just like the the accounting podcast we had with With Newton. Yes He his thing that was kind of revelatory for me was if you're, if it has no value after the year's over, it's sunk cost. You just write it off. Yeah, it's done. Yeah. That's right. Which is, which is, we might experiment with something and find out, you know what? We don't want to do anything with this. We we have the learning and we could build features on the CapEx with this, but we don't want to, it's not a high priority or we don't like it. We tried something. We don't like it. Okay. It just gets written off as no value in the years over. Super easy. Yeah, absolutely. So come, come back to this model, the companies that do this, like not necessarily naming companies, but the sorts of companies that do this, you mentioned Ikea as a name, I guess that's a good name, right? For a company. I say about Amazon here providing a platform, there's R and D there. I mean, they're, they're doing POCs and figuring out. Whatever happened to the drone delivery? They were gonna do drone delivery I would imagine there's a whole lot of I thought they tried it. I thought they tried it. There's a lot of R& D money tied up in they gotta buy the physical drones, and they have to choose a a city that they could work in yeah, there's a whole bunch of stuff. Yeah, and they, in the end, for whatever reason, could be regulatory it doesn't go anywhere. It could be. Or it could be that this, they actually can tap into this. You don't know. Yeah. Just like driverless trucks that they're looking into, right. For, for delivering between warehouses. So yeah, there's a lot of R and D and a lot of sectors like that. But that like just to kind of wrap up cause I'm kind of all over the place with this R and D category. Cause it's really like I don't know how many software development companies are dabbling in, in, in like augmented reality, virtual reality. Like Meta had a, had a big thing a while back. Like all that's out of R and D money. They don't know if that's ever going to make money for them or not. Yeah, but you gotta do that. You gotta, you gotta roll the dice a few times before you hit the number you're looking for, right? So it makes sense to me. But anyway, like we, we said that we would give some examples of companies that, that, that had both a product and a service component the first one that I want to talk about is Intuit. Intuit is a good one because a lot of people talk about Intuit on the in the product space. Right. They, they they give accolades to Intuit for its financial software products. You know, TurboTax, QuickBooks, basically. Sure. You know, so the, the, the actual development of those products, TurboTax, QuickBooks, is one thing. Like, they have development teams full time development teams that maintain them. Update them when the tax code changes, whatnot. But then they have actual accountants and financial management people that they can review your tax returns and review your your books and whatnot that, that can actually work with you. So that's, that's a, they have a services component. That works with their product component and those services people use their products. Yeah, and then the other third tier they have is some sort of What am I trying to say? Like Amazon has the capability for you to file your own taxes, right? Directly from their product. Which is again a service, right? That you value as a consumer. So that's a good example, I think. Intuit is a good example of a company that has product service mix. Believe it or not Atlassian other than hosting our favorite software to hate on Jira uh, like they like Atlassian also has a consulting wing Training wing support services like you theoretically you could call I would never call someone in Atlassian But theoretically you can call them they have their product, which, which people know and hate, but then they have many, many services. And I'm sure they always have R and D going on and not just R and D in the form of buying actual good companies. Like they have actual R and D. I don't know what they do. They don't enhance Jira, but they do something. I don't know what they do. I think in that vein, there are a lot of companies that are, that fall in that same category, like Salesforce or companies like that, SAP, I mean, they have the product. They also have services and increasingly over history. What you've seen is. Their margins have gone up on the services as opposed to just simply sales of products. Right. Right. I would imagine Salesforce probably is that way too, because Salesforce, when they first debuted, there was nobody in their market. Now their market is just jammed with competitors. And I would imagine that there, I don't know. I probably, I don't know if this is, I don't know if I can even research this, but I would expect that if I got a peek into their financials, I would find that their profits from product probably are pretty stable, steady, but product, but profits from their service. Probably are where they are making a larger margin. Yeah, again, that's true of a lot of companies like that in that same Bracket, so to speak. I think about Companies from early in my career, Citrix is a great one because Citrix, it was like their consultants, their people that actually could log on and tell you why things were not working and whatever those people, like they were gold. They were, they were, they got you to solve the problem working with them pretty effectively. So I do agree. Citrix is a good example. Tableau is another great, great example. You know, the people that you can like actual experts in data visualization and their products, taking your data. And visualizing with their products. Great one. They pretty much were kind of head and shoulders above the rest. But I think the, that field is also getting crowded now with other players in there, Microsoft included. we already talked about Ikea and BMW. We mentioned those specifically. BMW is a great example. Cause again, that like there's, there's a product that I think of, I think of anybody automotive as siloed where the product division is over here and the service division is over here. Service slash distribution is over here. Because you also have, I don't know if we mentioned the service being like your car servicing, your car maintenance. Taking in for oil changes and checkups and stuff like that that's a regular job. maintenance service that BMW offers via its dealerships or any car manufacturer, any, any, anybody Ikea is same thing. Ikea, the, the, the people that decide we're going, we're going to produce this dresser or end table or whatever, or Oh, we, we we really need to break into the home couch market or whatever. We need to make beds. Like those people that spin up new products are different from the individuals that manage the stores. That sell the products I think about that people deciding what products to create and how many of them Versus the people that run the stores and decide well the store here in tampa is going to offer You know free delivery within 20 miles of our home store location And we're going to offer the ability to set up your furniture For a service fee and we're gonna offer something else. I don't know what else. Yeah, I think you're right that that model is different, though, because in that specific instance, it's not even there's their employees who come to your home to set it up. They sub it out to external vendors, right? Right. So that's an interesting model. Presumably they've got their margins are above the waterline. We haven't even gotten to services of services or subcontracting services. Like we haven't even gotten to that one. But the, the Ikea model is interesting because like they they have a restaurant in their store. who, who decided like, Oh, we're, we're just going to open a restaurant in our store as an additional service, you know? So while you're shopping, you can get food in our store. You know, and like eat a bunch of cinnamon buns and sit on couches that are made out of cloth I don't know who thought that was a great idea It works for them. It works for them. He keeps people in the store for longer, I guess the other company is FedEx that we talked about before the podcast FedEx you wouldn't think of because you think, well, if there are logistics, transportation company, like they've got the trucks and the planes and stuff that takes packages, like that seems pretty purely service delivery. To me until you think that, Oh, well, the entire FedEx system actually is built on a platform of software built by a platform team, basically a service delivery, I'm sorry, a product delivery team. That is their product is a platform used by internal employees of FedEx. And you, as a customer outside the external customer, you have a window on the web. So you're talking about tracking, buying stuff too short, right? But the majority of their system is internal to the company. Yeah, it makes sense. Right. I mean, think about what they do on a global basis, right? I mean, they have to move stuff all over the place. So logistically they need to keep track of everything. They have their own fleet, right. Or planes and whatever else. So yeah, it makes sense for them to have a platform where they can track all of this logistical stuff to ensure that. Something gets from A to B in a timely manner. But they also sell products. before we dip into the products that they sell, the interesting thing about FedEx is it seems more, it seems that we're a lot of the tech products and tech companies on this list. FedEx, I feel is more of the service led that affects the product roadmap to say, Hey, we want to offer this service. But in order to do that, we, we need to be able to track all the packages. Hey, product manager, implement some kind of tracking for us. How can, how can you solve this problem for us? We need to know within a certain amount of time when the package is going to be delivered. And the product will look at what the service is trying to deliver, and where the service is trying to go, and then start building things that help the service. So I feel it's, it's product, it's product following, The service more than it is the service kind of being an equal partner. Yeah, right I don't know if that's really coming across I know what you mean I mean Just the ability for you to go online on their web page and say i'm trying to ship this right and they and you can go In and enter some Raw data. Here's how big my package is. Here's how much it weighs roughly and they can tell you to go from A to B, it's going to cost you this much that platform because you're not obliged to use their service at all. After that, you could say, well, this is too expensive. I'll just use the post office, which has a similar but very different model. Similar in that they're also in the logistical business, right? But you know, I don't think they do as good a job. At tracking all of these things. Yeah. As, as the other, I don't know. You could argue it's because one's for profit, the other's not. You could argue that you, I mean, you could argue that, but I think you'd be skimming over a lot of nuance. Yeah. Yeah. That I, that I want, that I want to talk about, which is, well, how would we launch a FedEx like today? Well, we, we, we'd start with one store and the customer wouldn't see any of the, our backend software. Right. You know, we, we'd have a, a very basic product here, here's a package. And then API integrations with FedEx, UPS, postal service, whoever's picking up the package and and people have to come to our store to find out where their package is at, right? And then as our, as our service grows, now we offer a web portal. Okay. Now we have a product that's following our service. Well, people don't want to come to the store anymore. The services. You come to the store, you ship the package, it goes to wherever you want to go, you pay some money, that's it, end of story. Now people say, well that's great, but I don't want to have to come back to the store to find out where my package is. So now, product develops a web portal. This number, you can punch in the number on the web portal, you find out where your package is in the world or whatever, and then you have it. So like, we started with a store, And then now the product is following the service. Yeah, that's, that's an interesting model to me is the product following the service, we talked real early in the podcast about like. You know, late nineties, early 2000s development where like, Oh, I'm going to sell a bunch of Dell PCs. And then I spin up my team and they go deliver the Dell PCs or whatever. It's like the service is kind of following the product in those models. This is more interesting to me to talk about. Maybe if you want us to do a part two of this one, we'll, we'll start with services. That follow products like the, the, the Airbnb. No I was going to say Airbnb, but also Uber, Uber's an interesting one because Uber, when they want to break into a new market, they'll spin up a team. In that hyper local market to start figuring out you know maybe it's maybe it's the food delivery apps that do that. Uber, Uber eats or something. Maybe. I can't remember, but DoorDash or whatever, maybe it's those apps. One of these companies that relies on hyper local markets. They have to spin up a team to test out their product in that local market to see if there's traction. And if so, then they hire people from that local area. I think it might have been Airbnb actually now that I'm talking about it. to figure out if they can get traction because they, because every locality has different laws and different regulations and different things that they have to comply with. So they had to spin up a, a team in the hyperlocal location and that is a services team at that point. It's not a product team, the product is the same. I mean, now, now where the product and platform has to change is to say, Oh, this, this place has a different tax than this other place. Or this, yeah, maybe the platform has to be enhanced to allow for some local customization. But that's, that's, that's a one off enhancement for the platform. The actual customization based on locality and the need for additional features based on localities. That's something that the services team is leading. The product team. So as this podcast went on, we got more nuanced in the, how the service delivery and product delivery. Kind of work together that's true. That's that's interesting. Yeah. I also think that we're not done. Like it was probably just scratching the surface. If you keep going, you would find more nuance. I think, I think, I think we need to reach out to Brian Fidalgo and get him back on to talk about service delivery. Now that we're like in the depths of service delivery, I think it might be time. Yeah, I can do that. I'll reach out to him. The podcast follow on is how a product delivery organization can follow a service delivery, because if you, there's actually a great business model if you think about it, because if what we said early in the podcast holds true, the service delivery people are forging stronger, more longterm relationships, less transactional relationships. More long term relationships with the clients. I mean, that's the hard part. That's a business development, basically. That's the hard part. And it doesn't involve the hard R and D type of dollars that a product development might, that doesn't mean it's cheap either, because you have to spend the time to forge those relationships over time. Right. I mean, it's, so you could say it's similar. I don't know. Depends, I guess. You don't have a whole lot of capital investment, but you do have time investment and energy. I mean, that might be okay. I mean, your service people might be the people to tell you like, Hey, you don't need a lot of money because there's this gap yeah that we see if you're in tune with them, and you're listening right again You can't do that in silos really not do that in that one Yeah, sure you kind of you've got to be working across those swim lanes and verticals intersecting together to say hey at this customer this implementation of the product with the service that you're providing Let's talk about those problems. I would expect if you're a product manager, you're going to be going to more meetings and you're going to be getting more in depth. Like I, I, everyone hears this as like, Oh, more meetings, I'm out. To really know how your product's being utilized. Yeah, yeah, yeah. You, if you're in a, in a matrix organization like that, Yeah, get ready. Buckle up. so if you're in a model that we described as I think I said the pod model, it behooves you to talk to other parts, right? Because they have other customers that they're serving and they get different feedback. So you may have more meetings. In that sense, where you're meeting with other pods to figure out how how their experience is faring and how collectively you could improve the services and product. Interesting. I like it. Talking to people's heart. Oh, I don't like it. I don't like it. It's too hard. Okay. Too much pressure. Well, this is a, I mean, this is a, I didn't expect to go this long, but I'm happy that we did because just, just like agile doesn't work here. Products and services together. In one, in one business, we're unique as unique as GE and FedEx as unique as everybody else, probably pool and BMW and Levi Strauss, every Johnson, Johnson, every other company that we've named while we've lightly broken the working agreement but the, the, the way that you manage the relationship between the two, I think that's the thing that we've come from this podcast with a new appreciation that to say, this is very, like when we talked about the management methods we were not happy with any of them. No, I think, I think the customer centric model. We were most happy with. Yeah, that was the closest one. Yeah, but the, the, like the silos, like we, we know there's problems with that. You know what I mean? Whether the matrix, we know there's problems with that. Yeah, yeah. Interesting. Isn't it? That was the, that was the most interesting takeaway in this podcast to me. Yeah, I agree. Yeah. Cool. All right. So I think it looks like if you're still with us, well, thank you. And let us know in the comments below what you'd like to talk about. And don't forget to like, and subscribe. That's right.