The Great API Debate: Open Ecosystems vs. Walled Gardens | E6 - Hard Refresh - An ISSA Podcast

Sa.

Welcome everyone to another episode of Hard Refresh. I'm your host, Kaden Hutchins. Alongside me is Karina, my amazing co host. And we have an amazing guest today, probably one of the newest tech innovators in the cleaning industry to enter the space, Gerald from Bright. Go Gerald. Take it away. Introduce yourself, my man.

Everybody. My name is Gerald. I'm the CEO and one of the owners of Britco. Real quick. My background originally was in software and technology at a career in Silicon Valley working for well known companies. You've likely heard of Meta Stripe, these different businesses eventually from our lens, Silicon Valley usually just works for other people build software for other people in Silicon Valley. So my mom's a property manager and later on I learned more about the industry. We interviewed about 500 different cleaning companies, people in the industry and found a huge ways where software could still be improved for the industry. So I teamed up with a bunch of Harvard Google top notch engineers, raised millions of dollars and now we're in here to improve the software for the industry more broadly. Thank you for having me, Karina and Kaden.

So I got to spend some time with Gerald this week and I will tell you, so grateful for him taking the time to be on the podcast, number one. But just the way that they lead product from a thoughtful and intentionality perspective. I know they've done an enormous amount of research to really understand our industry and it's just so because I have such a warm place in my heart for. For the space. Right. I just love when companies do that and they lead with purpose and heart. So just giving a huge shout out to that leadership team over there, Gerald, what you guys are doing is it brings tremendous value to our industry. So thank you.

Well, thank you, Trina. Appreciate it. Really appreciate it.

Kaden.

Oh, that's awesome. Well, I'm going to top it while Gerald's about to top it. So before we get started, Gerald, we're going to do two truths and a lie. So this is a key moment. I. Karina, we should probably start keeping.

Score of how well we do here.

I don't know our track record right now off the top of my head, but Gerald, you are going to share with us two truths in a lie and Karina and I are going to have fun and see. See which one is the lie.

All right, let's see. Okay. I tried to come up with these. Let's see. Okay, so one of them was. These will be from my high school and college time. So one of them will be in college. I won first place in four coding competitions. That'll be one thing, collegiate level. The second is, I do not have a gallbladder. It was surgically removed. I don't have a gallbladder. And the third is I. It was a semi finalist in the intel science competition in high school.

Okay. I think I know the first one is real.

Karina's like, I already know because he's so smart.

I think number one is true. Number three is true. And the gallbladder, I don't think it's true. I was trying to look at the pause. Listen to the pauses and his voice. And so that's always like, my finding my tells.

Wow. Yeah.

I'm a communications major.

First one again, Jerry.

The first one was coding. I won four coding competitions in college.

See? But it also could be. I only won two of them and took second place.

There was a lot of details. There was a lot of details. I think that one is true. Gallbladder one. Can you even. Is that even possible?

But that was such a random. Yeah, but, like, that's so random. It's like. But he had. He did have a few minutes to really think about it.

I'm gonna say gallbladder.

I'm.

You can say something different. Don't let me peer pressure.

You personally leaning to that one. But I think. I think maybe something about the first one. Maybe he's trying to throw us off with the numbers.

Okay. Who.

I'll say something about the first one, maybe.

Okay, Gerald. Who's right? Which one's the lie?

I was the third one.

Dang it. We're both wrong.

He really threw us off.

Yeah.

Wait a minute. You don't have a gallbladder.

Yeah, it was surgically removed. I had a cyst when I was. You know, I'm pretty skinny, but when I was young, I got even skinnier because I had a cyst that was blocking my intestinal tract. And, you know, the doctors thought it was just, you know, oh, it's just a stomach flu. But then I couldn't hold down food for, like, two weeks. And so I lost, like, another 10, 15 pounds. And they were just like, holy crap. And eventually they, like, did the X ray. They found this little thing, and they're like, oh, there's a cyst. It's not like a cancer, but like a cyst blocking it. And I was in, like, third grade, so they had to go in surgically, remove that. And for some reason, they took my gallbladder out while they're at it. I think it was just close to it. They're like, you know, we should take it out for some reason. And so I always had this moment when in high school, I would go into biology class that I still remember this. And the teacher was like, you know, the gallbladder is really important. If you don't have it, then you won't be able to eat this or eat that or eat this or do that. And I'm like, I don't have a gallbladder, but I can still eat all that. And I was just like, shut up. We don't eat that here.

Oh, man. All right, well, the third one. Yeah, the third one being a lie. Remind me the specifics of that one again.

I said I had want. I'd. I'd been a semi finalist in the Intel Science competition. During high school, people didn't think of me as like the computer science guy. I was actually more. I was fairly well rounded. I was. I did speech and debate. I did these different things. And I actually did a lot of computer science classes on the side. Just like my. My dad would always send me to a local university. So I'd taken six CS classes during high school, learned a bunch of different languages and all that sort of stuff. But I never was like the CS guy in high school, so nobody really thought I'd be that way. I wasn't really competitive in that way, but yeah, but I got started with just a lot of classes, and then I also did an internship at a startup. During my senior year, most people were out drinking and having fun and I was at a. At a. In a garage running code with the cto. You know, that. That was my. Like when I was 17 years old, that was my jam. So.

Yeah, that's so cool.

Yeah, yeah, yeah.

Very, very cool.

So, yeah, then you got to college and then that's when you decided, I'm going to.

Yeah, I was actually like, yeah, I was. I had a little. This will sound really weird. It's just something that's particular about where I grew up. I grew up in a very competitive environment academically. Like all. Everybody's. Like a lot of people, you know, their parents go to, you know, our professors at Stanford or work at Google. Everybody likes. People cry when they get a B. Like, that was the environment that I was in. And so it was like, very hard to stand out in that environment growing up. But later on, you know, as I. Later on in college and other places, I was like, okay, let me lean in a little bit here. Let me try a little bit harder. And I just kept Paying dividends and. Yeah, yeah, I. I really couldn't stand out that much in the really early days because everybody was so competitive. But later on I was like, okay, let me just keep working harder and pushing myself. I always had a little bit of a chip on my shoulder later on throughout my career, so.

Wow.

Yeah. Yeah. That's a very humbling experience in high school.

You're probably. That's so cool.

Awesome.

What a cool story.

Seriously. See, we learned something. Okay. By the way, we are so. With Tony and Vince, we got it wrong. With Gerald, we got it wrong. With John, we got it wrong.

Okay. So you have to not pick the men you guys want.

Yeah. So we are terrible at. This is the moral of that story.

But super back and be like, all right, we gotta make sure. Did we get anything right?

We didn't. Because John, I think it was the degrees. We said it was like five. And he's. It was the auto mechanic thing that he lied about.

Right?

Yeah, we're gonna get one.

That's true.

Gerald, you were good.

But yeah, if you. If you've missed these two truths and a lie, we do them on every episode. We're bringing a guest besides our first guest. We hadn't thought of the creative yet on that one, but. But yeah, let's dive into some quick control. Karina.

Yeah, we're gonna do this quickly because we want to get into the main segment, but we do check out the latest episode, the Training Trap with Vince and Tony. It's posted on LinkedIn, and Kaden and I are really, really excited to be able to bring the what are you doing? Workshop. It's the ultimate growth hacking workshop during the Business growth strategies on June 11th and 12th at ISSA headquarters. More information coming up. Please sign up. It's going to be a great couple of days with peers and learning from each other. So stay tuned on more details. That's it.

Yeah. And we're going to record a couple episodes in person while we're there. It's going to be fun.

Yeah.

So. Okay. Well, moving on to clearing the cache. Today's discussion that Gerald has been so gracious to come on and talk about is the great API debate, Open ecosystems versus Walled Gardens. Now, Gerald, before we dive in, I think it would do our listeners a favor to quickly go over what an API is for. For some of them, there are. There are awesome people out there that have an understanding, but some people don't understand the. The idea of a system having an API and what it does.

Yeah, yeah, yeah. So an API Is basically the way to software systems would talk to each other like normally regular people. You might use when you're trying to make something talk to you might use a CSV or Excel upload something like that. The way that two computer systems to talk to each other using something called an API. So it's just a structured way for them to talk to each other. So think of it no differently than using a CSV or an Excel sheet between two different systems, except that's just the way it's a bit more structured in the way they use it. So I'd say that's probably how I'd summarize it.

Okay, so now that that's out of the way, this idea that your tech stack should play nice with others, or should it not? You know, you wanted to come on and talk about this topic. What was it particularly about this debate that always intrigues you?

Yeah, I think that's the part that's really interesting is that at the end of the day, building service, contractors, janitorial companies have a lot of data in their company. I think that's something that people don't realize. Every single shift you have, every single punch payroll data that's so important. Labor 60, 70% of your total costs. And so you have a tremendous amount of data on that and past performance, future performance, you know, your revenues. A lot of companies have opportunities to improve how they better understand their finances. Then on the operations side, there's also so much data as well. There's a lot of products that help you with inspections. There's a lot of different ways to keep track of where your missed punches are coming from, whose no showing repeatedly. There's a lot of information around, maybe tickets and issues and complaints that are coming in as well. So there's data coming in from all these different places. And you also are seeing that you're unfortunately having to use multiple tools to do things for better or worse. Right. And so how do you make sure that all seamlessly works in one, as opposed to it being fragmented and having to do double entry? People have to. People are not able, you know, the workforces you're not able to. It's frustrating to have to train them on, you know, a lot of tools and you have to double enter and all these different issues. So the more seamlessly you can have people use, you know, really good tooling. But making it so they don't have to do the grunt work underneath is all really important. So in general, I've been hearing a lot about the desire for the system to just work. But then that comes to the Are there walled gardens that are stopping systems from talking to each other versus can these systems talk to each other and. And then work more seamlessly? So there's pros and cons to both sides. I'm happy to kind of share what I view as the pros and cons of either side because there are trade offs. Right. But it's, it's just a good discussion to be having and for owners to be people in the industry to be thinking about it.

I love this topic because Kaden and I really, we've spent a lot of time. We did a All in one or what was that the name of that podcast that we did the platform debate.

All in one or all wrong?

Yeah, I specifically, I, I try to understand from a meeting people where they are and humanizing technology the most that you can. I think that there's departments specifically from my experience at Pioneer, right. There's departments that really have their own sandbox within their own system. So for Pioneer, the accounting team is working in Win team. And so for operational perspective, we were all using Quora, but they were using it for accounts receivable, accounts payable. So what we did was we integrated the platforms and allowed them to still work in their space. And it just provided such a nice way to not force people to just have to be used with a specific tool because that's what we're using. It allowed kind of like the dependencies to not make such a negative impact because that's what it felt like. If you only pick one solution, it feels like very dependent on that platform. I don't know. What do you think, Kaden?

Yeah, I mean, when we talked about it in that former episode, I'm actually curious, Gerald, kind of your philosophy in building, in building brightgo, you know, because there's pros and cons to both. Have you kind of settled on, on one way that you want to take brightgo in that regard?

Yeah, our, our philosophy in general is that like from the lens of the person running the business, they just want everything to work. That, that's just the view from that lens. So I think the. And so like if you have an application that can do more things, I would say one, one piece that's really important is that if something does many things, it has to do them all really, really well. If something does many things and it does any piece wrong, then that's just really bad because you'd rather have a best in class do any area. So it has to be best in Class. I mean, the more from the lens of somebody running a business, from a cognitive perspective, the fewer softwares, the better. Right? Like if somebody could have 15 versus 10 softwares, which is maybe sounds like a lot, they'd rather have 10 than 15, given that they're not cutting corners and that everything is best in class. Right. So I think that's the general view, which is that, I mean, people are trying to have their taking it too, to some degree. They don't want to compromise on quality, but then they also want to make sure it works together and they don't have to have so many invoices, so many relationships, so many providers. Like that just gets kind of complicated. And so there's room for both types of players, right. Ones that, that do a lot of things. But I think if, if you do a lot of things poorly, I think that then creates a challenge because especially if you do a lot of things poorly and you're not open, then, then it creates a lot of friction with things that could be best in class, right? Like that could come in there and do something really well or something that might do several well. So, yeah, there's general ways. So that's sort of the high level and how we think about Abrico. We don't want to ship mediocre. Nothing should be mediocre. Everything should be really good. And if we're not doing it ourselves, we should basically be very open to working with the best in class in that area. That's just a general philosophy. And there's areas where, you know, we've built something really, really good, but there might be something incrementally even better. And, you know, that's fine. Right. And so it's just at the end of the day, we're all here to make the life better of the company and the business and the people running the business. And so that's sort of the high level way I look at it. I don't, I don't really like it when software's trying to say, this is all mine. Right. We are going to be, you know, you know, don't, you know, box everybody out. That's not necessarily the right setup. So, yeah, that's my high level of philosophy, if that makes sense. Kaden.

Well, I also, yeah, so we don't like walled gardens.

We don't like, we don't like walled gardens. But I think to everyone's like, there's a lot of things that are coming from a client's mandate too, that, that's something that a lot of BSCs don't really necessarily understand from an inspection tools perspect. Like there's proposals that are including O2B or Smart Inspect. So you have to use other systems. So to create a culture within an organization that allows for other tools to come in and connect and integrate, it just sets you up for success because then you're allowed to serve your clients, you're allowed to serve internal and external stakeholders. That's what I always kind of broke because I have multiple BSCs reaching out asking what's the best option, should I do an all in one? And I've told them repeatedly and I'm sure I'll get crucified for this. I'm like, I personally would not do an all in one. I don't think that it supports the tech innovation strategy perspective from like culturally. It just is, it, it's, it causes friction unnecessarily in my opinion.

I think in terms of what the industry really wants and I'll, I'll be just from my discussions with a lot of people running businesses, they do want an all in one that, that's genuine genuinely, they want a modern all in one that can do everything really well. That is what people want. It's very hard to do. That's where, you know, we're trying to move towards that end, but we're not, we're not there yet. We're not, we don't have literally everything. That's, that's impossible. Right. And so nobody does. Right. Anybody who says they have an all in one doesn't. Right. Because they, there's a lot of areas where either they're not best in class in certain areas or they actually don't have all the features. Right. And so we are, we're just, we're adding a lot of different things so it's becoming more comprehensive over time. And there's certain areas where we definitely haven't covered yet. That's just the reality of, of how hard it is to do that. But people do want fewer softwares I think that is generally if you were to ask any, anybody running a business today, would you rather have 10 softwares or 5, 6 or 3? They'll usually pick the lower number but then of course they'll ask what's the trade off? And then, then, then there's finding that trade off, that happy middle. So maybe I'll also put the case of why, you know, I know this is the hot take, but why walled gardens could be good. Right. I'm also happy to kind of like steel man, that Just intellectually like so, so at least people who are like, oh yeah, maybe that is the right way. Right. The good thing about a walled garden to a certain extent is that you have fewer providers, like 1, 2, 3 providers instead of 10 or 20. You have a lot more predictability in terms of understanding your data where it is. The issue with having too many systems is that they might, if they have edit access to each other, then it's hard to track things and you might have data that's, you know, you don't have a single source of truth, at least from some people's lens. Could be a little more complicated cognitively. So walled gardens are, I would say cognitively easier because you don't have things talking to each other and kind of potentially making things used as not intended, I guess from the lens of the person who designed it, in theory. So I think there is a lot of reason from, I mean those are all good reasons, good intentions. But that being said, I think there's still, there's still to be gained. Also the security challenges, right. If you're, if you're going off sending data left and right everywhere, you have all these people accessing your, your system from different angles. That could also pose a security issue, especially with all the important information on the accounting side as well as payroll, as well as just building information. So anyways, I'm not again, I'm just.

Trying to steel man, that very diplomatic, very diplomatic of you.

Yeah, sorry, what was that? Sorry?

I said you're very diplomatic. You're giving them both sides. You're not clearly saying one or the other. It's very diplomatic of you. I appreciate that. I was very much like, no, I don't like all in one solutions. No big deal.

I think there's also something like when we talk about an all in one solution, we have yet to present a number going from 10 to one. Right. So some people think, I think of like main business functions where all in ones exist within the ecosystem of that business function. So can there be all in one sales functions, marketing tools, finance tools? Right, because there are thousands of things that are needed within each of those business functions. And like I think of the early days of how we started building software. There was aspects of even operations that we ended up cutting because it was, it was too much. Right. We, we existed on the bidding and estimating side before someone came a customer. So we were involved in the sales process and then most of our other tools were more on the operational side. So we were talking about two separate business functions that There's a lot of moving parts in between each one. So the idea of can you get down to five, which represents five core business functions. Right. That's, that's amazing because, yeah, if you're using seven different tools just in the sales segment of your process, my CRM, my automation here, then. Yeah, you know, as to Gerald's point, you're about to run into dozens.

Yeah, it's. I think the, the area that I'm very tapped into is just the broader software ecosystem. Not in Janitorial, but also just what does, you know, Fortune 500. What do these top companies all use? What do their stacks look like? And they're, they have a lot of appetite to do what is called tech stacking. Right. Just best in class. But even. Let's imagine if somebody's using Salesforce, they then use like 10 different sales toolings on top of Salesforce, even 20. And that's just within the sales function. Then you have marketing with another, you know, main kind of source, and then five more that feed in and they end up with 60, 70, 80, even 100 softwares. And I don't think, I don't think this is my. I don't think this is a hot take. This industry doesn't have that appetite. Right. This industry is not one where you're trying to have, you know, things within things within things that are best in class. That doesn't seem to be the right way to do it. People do want some amount of consolidation, but I would say the friction from that lens is that it's really hard to build really good products in this industry. I think that's something that anybody, you know, you go ask two companies, they don't bid the same way. Right. Like, you ask two companies think about inspections or how you think about anything, they don't do it the same way. Right. So in any, any given area, it's actually very hard to find something that can do many things. It's just, it's just a big challenge. And that's the challenge. Personally, as a company. We're trying to take on, as we're building more and more things because we do see that cognitively people do want fewer softwares.

Right.

But then that then raises the ante. Like you have to show up even stronger with a better, you know, you have to say, okay, I'm going to really learn this part of the product and actually nail it as opposed to just, you know, creating something that's kind of a shell and then moving on and saying, you have 10 things. I think that's not working. I think that is not being received well from the industry. It's that, okay, if you say you're going to do X, Y or Z, you gotta do all of them really, really, really well. And there's also other, other considerations which is that companies of different sizes have different needs and different specific things. A company with 20 cleaners is completely different than a company with 200. And it's very different from 2000. I would say 200 and 2000 are more similar than 20 and 200. Right. Like you start to see these really interesting things that start to happen. And so you also have to think about like certain softwares start to specialize to some degree, but not within just like a niche of a certain category of what they build, but also within, you know, the size of company, et cetera. So software's hard. I think that's the realization. And you have to basically be specific of who you're building for. You can't pick too many battles. And you have to say each battle we're going to do really good. Like best in class, one of the best. Right? That's what we should all strive to be for building in any given area. But from the owner's perspective, fewer is better from their lens. So I do have to empathize like they, they do want one. That's just the reality. They want one software like they just want one to rule everything. That's, that's what the owners really want from my lens, what I'm hearing. But of course there's just a practical, it's really hard. So that, that's sort of the dissonance here.

But I think that's where we get to challenge the mindset. Challenge I said that weird, but challenge the mindset a little bit with the bscs, right? It's like have them think through what are the problem are you trying to solve for when you're trying to think through technology? And do you really understand what it means to have an all in one? And why do you want an all in one? Is it because of the cost? Is it because of implementation? And just pushing back a little bit because I think oftentimes, Gerald, you're going to find that they don't necessarily understand really what does it mean to have an all in one. And I've had so many conversations when I'm going through discovery and I'm like, okay, what are, what, what technology are you using? So they rattle off the five of them and then throughout the conversation they're like, oh, I'm also using this and this and this and this. And they're like, I didn't even realize I was using them. It's like 25 different ones. I'm like, yeah, because you don't think about it. So what exactly are you looking for? What problem are you trying to solve? And that's going to help you figure out what is the right solution for you.

Yeah. We don't have a marketplace in our sector that makes connectivity between platforms super common. And so like in, in the software space, so much is interconnected and can be integrated into each other. And so I don't operate my business looking for an all in one. But that's like. I love what you said, Gerald. The, our industry is not going to be okay with that. Right. They'll, they'll constantly like our, our ability and desire, like our threshold to be able to deal with multiple systems is a much higher pain tolerance than this industry. So I definitely sympathize with that. I think in time, technology in this particular industry, if we start seeing more of these API connections into these specialty tools, people that are nailing the job super well, I think the level of tolerance will come down or, sorry, go up. People will be more able to tolerate because I hear the same thing all the time. It's like managing multiple systems from just a data sharing standpoint, if you have to do it manually takes a lot of time. And we've existed on that end of a complaint for especially the majority of our years was you guys at Otuvi are a walled garden. You got some cool things in there, but you're a walled garden. And we've had to kind of start breaking out of that same mindset. And it's, it can be scary at times to think about multiple systems, but the reality is, and I love how you said this in the. They just want it to work. They just want it to work seamlessly without having them to manage everything manually.

Yeah.

And that's key.

Yeah, it's. And I think one, one of the layer, it's like, I think it's always really important for us to, you know, as a technology provider, we might want to say, oh, you know, what we have is the right thing for you. Right. But we always have to start from the lens of, you know, what does the user, what does the person, the end user think that that's what matters. It doesn't matter what we think. It, it matters what they think. At least that's from my lens. Right. And so it's just like, what do people want and why do they want it? And I think the, you know, making the case for the, for the all in one walled garden, just, just putting that out there, right. Like one of the things that from a business owner, they don't know what an API is. They don't like to think about sending CSVs between systems. That just sounds not fun. However, on the other end, the way that they also think about it is that they don't think of their business as disjoint parts. One part does sales, one part does finance, one part does operation. Yes, the org chart might think of it, but for them, these all push and pull from each other. How you bid is very representative of then how much pressure you'll have on the margin side.

Right?

And so these are all, these all coexist, right? These, these functions all work together. So in their head, we're running one business and they all push and pull from each other. And so in theory they want one system that can understand and see all the differences between them without all the headache in between. That, that's what the, that's what they want. Right? And now, now there's, there's the reality of how practical that is and there's certain challenges. But I think it's really important for us all to always understand like there, there's a really good reason why they want that. Right. Like if you, if your strategy is to bid lower, which is what happens as businesses scale, right, they get their margins go down over time, they go from 15 to 10 to 5. That then means you're putting a lot more pressure on the accounting side to then make sure your job costs incorrectly, putting a lot more pressure on the operations side because you have to run much leaner. And so one thing over here affects all the other parts of the business. And so from there, from the lens of somebody running a business, these are not in isolation of each other. You're running one thing holistically. So in their head it makes a lot of sense to have one system. So you know, the way you retain is the way you sell, is the way you, you upsell, is the way that you, you make sure you're, you're making money. So that that motion I think is incongruent with a lot of. It doesn't match up with then having 15 softwares now. Yeah, there's a reality of what we're dealing with day to day. But yeah, that's just the learnings that I've had just spending a lot of time with different people in the business.

Well, and I Also throw in something I've always tried to understand from a platform optimization. That's really where I tried to get people to think through. Like, if you are using a system, to what percentage are you optimizing that system or that platform? Right? Like, if you're really wanting to use. Because that's how I learned the power of technology. I was using a system with Maximi, it's called Service CEO. And my mother at the time was only using it for client contact and email and addresses. And there were so many different facets of this business or this platform. So I started maximizing all of the different features and functions and it became super powerful. So now it's like I try to challenge people that are using all in ones. I'm like, well, so what percentage of the platform are you optimizing are you using? And most of the time it's less than 40 to 50% because they're only using the tools that are super good or super strong. That's the other thing. It's like, why are you paying for something that you're not using? Or if perhaps it's a part of like the journey of technology, you have to think through, maybe it's not feasible to use it at an 80% optimization rate out the gate, but you have to have a plan for that, right? So maybe out of the first 60 to 90 days you're at a 60% optimization, then you go up to 70%. But like, think through that because that's really, if you're going to do it all in one, you might as well try to optimize all the pieces of it.

Yeah, I completely agree with that. I think one thing that we notice, like, people sometimes get excited. They're like, hey, Gerald, what do you built? Like, you know, I would love to learn more about Brent Co. I'd love to use your software. There's all these questions around this sort of stuff. And then I usually ask them, like, what are you using? And then they'll usually say this, that, this, that. I'm like, those are great tools. Like, have you gotten the most out of them first before you switched? You know that that's something that surprises people because in their view, they're like, hey, why am I not trying to, you know, sell them and earn their business? But for my lens, it's like, you know, switching software is a lot of work and it's always easier to incrementally get more out of your existing software. And from my lens, I usually know the limits of different providers out there because I've seen them in the wild, I see how well they work. And so I'm like, yeah, you could get a lot more out of that. So why don't you go do that first before we talk. Right. Because switching softwares is a much bigger headache than using more of a software that your team is already using to some extent. And so we usually recommend that and if they still use it to their fullest and then they don't get enough value, then let's talk. Right. Like that's a different type of conversation at that point. And so I think that part's really important because again, and some software is hard to use and so people even try, they spend another six months trying to get more value and they can't. And at that point it's a structural issue with that, with that tool or how it's built and that that's different then of course as well because they've spent that extra legwork and they've hit their limits, right. Their cognitive limits of their team to use that tool. So I think that's where it's really healthy discussion, I think, because, because the reason why I say all this is that later on when it's the economic decision of okay, are we going to go through all the time and effort to retrain everybody? That's going to cost a lot of money, going to cost a lot of resources. We're going to have to double pay software for a few months. Right. We're not going to just switch cold turkey. Right. So that's going to take a financial investment. So how are we going to stomach that unless we know that hey, this is the better long term path and we' tried everything the current. So anyways, that's sort of how we tend to see things. And you know how we, when we, when we consider bringing somebody new onto our platform, this is kind of how we make sure that they're serious to a certain extent. Because it doesn't help anybody if they go in and they're like, oh, two months in. No, actually, no, we want to stick with the current one. We actually think we can get more out of it. We're like, this is not a healthy relationship in that sense. So anyways, that's just like something we've started to learn a lot about the industry.

Yeah. And they actually don't follow the pattern of the wisest choice when switching providers is to duel it. They just cut it. It's like you should simultaneously test processes against each other through the transition. And they're like, no, that's doubling the.

Cost or whatever, you have to double, right? If they, if company has 500 cleaners, 200 cleaners. If you have 10 cleaners, different, that's a different story. Say, right, you can just, you know, fly by the seat your pants with 30 cleaners, 50 cleaners. That's different, right? But if you have 400, right, like you're not gonna, you're not, you know, you miss payroll, you, you don't pay somebody correctly, you're gonna get like a labor lawsuit on your hands, right? You're gonna get, you're going to get lawyers sending you something. So you can't have that, right? So like you're going to have to double run to some extent do some sort of pilot, do some sort of like double pay for some amount, which is fine, right? That's the cost of implementation. You have to train. Training is resources. As long as there's a destination that's much better than where the current could get you, right. Then it's worth it, right? Because I always say like, is it really worth it? Because there's a lot of pain to switch. Like this is just the reality of software. Switching softwares is really difficult. So it has to be worth it. And there has to be some sort of difference in the business that you can make to say, okay, I'm glad we did this. Now the businesses are much healthier, better spot financially in terms of retaining clients or having higher margin or selling better. Like it has to be one of these big poor, you know, hits the P and L type of goals because you're taking from the P and L in the short term as well. So that's sort of the way that to think about it.

Well, and I'm so glad that you're talking about onboarding because I think it's such a huge pain point and not a lot of times. I Read this on LinkedIn a couple weeks back and it was like the smartest platform position, an upgrade strategy, not an onboarding strategy. And I think there's so much beauty to that statement because I've gone through several onboarding processes through large meat, small, medium and large platforms and it is excruciating. It is so bad. And it's like, how have we not figured this out? And it's such a hot topic. So many companies that's their biggest like fear is how do you disconnect the duality of having one system and the other? And when do you. How are companies really guiding a proper onboarding experience? I'm quite, I'm Curious. Kaden, from your perspective, an onboarding strategy, like how does that work for your team and what do you, how do you guide the conversation for BSCS pilot?

Okay, like, we are so adamant to go test what they think in theory is the best way. All I, I've shared this story so many times. I was on site at a hospital out just outside of D.C. actually, Karina, and this entire building service contract that they had won the contract and we spent the entire day like from the high level executive standpoint, they were like, we need it to do this, this and this. We got it all up and running. And throughout the day I straight up said, I said, are you sure? Like, is there like supervisors we could pull in to make sure that they would like, enjoy this process? Like, go pilot your. Well, so then they made all the changes and they're like, oh no, no, everyone would be fine with this. They just kind of do what they're told. And literally I got them, five supervisors came in at the end of the day and they destroyed what was built. They're like, this isn't going to work. And they said, here's reason why, number one, number two, number three, oh my gosh. And they were like, okay, well we're going to have to go back to the drawing board. And I was like, there was a reason why you quickly go quickly take a process, go introduce it to the team. And I'm talking like, more often than not, hundreds of locations. Someone comes to us and we're like, nah, nah, like you get five. We limit you to five. Go test the workflow, go get actual feedback from the client, from employees before you pull this trigger because that will be a cost of mistake. So that's, that's probably the biggest principle we take on an onboarding is please pilot, go test it somewhere and then do the full rollout after 90 days of your love and results.

Again, thoughtful intentionality. That's what it feels like. That's like, you have to do that with these things otherwise. And I've had hard lessons that I've used with Pioneer and I've learned from when I didn't do that approach. And I just thought that they were going to, from a frontlines perspective, embrace a new feature that I was rolling out and this was like very early on. And it's like, oh wait, you can't just demand things. You have to have them understand the why. Like, why are we using this? What? Why did I improve it? Like, and that's why I started to do baseline assessments with our operational Teams and really understand, like, what is it that we're trying to solve for so they can understand the entire work for all the stakeholders know the goal that we're marching to. That's what I heard.

Yeah.

No, it makes a lot of sense and I think it's also, it goes back to also some of the challenges of designing and building software for this industry. I think it's that if you think about the different groups, right, let's imagine you have owners and executives, you have middle management supervisors, and then you also have the end cleaners. If the software that you give to the cleaners requires a training session, requires you to share screen with them and show them how to use it, it's just not going to work. It has to just be like, here's the link. Install it and then just get it. It just works, right? It has to be like that. It's just magically, hey, everybody's using it. It has to almost be at that point. So that's a very, I would say from a product perspective, a really high bar. Like, if you think about like a product like Apple, it's built so that your grandma can use it, right? Like in the sense that, hey, anybody could use it. And so to a certain extent, it needs to have that level of design and kind of intentionality and ease of use, right? Like, I think some of the little things that we learned in the early days was that like, you know, there is an older population that's cleaning as well, and they use their phone on maximum font size. And so that means that you can only fit about three to four words per, per line, right? You can only fit about seven words per page, right? So you then start to realize like, okay, these are highly constrained design criteria. Every single button makes the experience worse. Every single checkbox makes the experience worse, right? So it's like every single screen you put up makes it worse, right? So it's like, okay, how do we design for that? Then you have to then think about, you know, maybe the executives, which are all about. They love data, they love information. You know, they're. They're hungry, right? It's a completely different Persona. And then you have the middle management, which has different strengths but also different ways where, you know, they might not be super analytical. They want something that's simple, but they also do need a bit more insight into the, into it. You can afford to train them a little bit. Not a ton, though. But, you know, as Kaden was saying, but they also have a really tough life. A lot of them are Working too many hours relative to, you know, how much they think they should get paid and all this sort of stuff. So it's, how do you be part of their solution and not their problem? It's, they're, they're just, it's a, it's a very tough job that they have. So some of them are in charge of, you know, 100 buildings, 70 buildings, right. And for them to have to deal with an app is the last thing they want to have to deal with. So it's really tricky because each of these different stakeholders have different needs, different Personas, different desires from a product perspective. So it just makes building really hard. Like I come from working on Instagram or working on Facebook and Meta and you start to realize that there's actually interesting patterns between it in terms of different populations. So I'm nerding out here a little bit.

No, no. I love this. When. So when we were designing, I'm like.

Can we get another.

I know, I love this. Me too. I could go for another hour to know, but. So one of the things that we learned quickly when we were building clean code was the frontline team members had gloves, right? So when they were trying to hit the radio buttons, they couldn't do that. And so I had to adjust the UI UX for them to be able to press them quickly. And so things like that, you don't realize until you get in front of the frontline team members and really understand how they're using technology. And companies that are doing and being intentional, I think over, they supersede the other companies that don't have a really good pulse on the front line and all of the stakeholders.

I have a funny story from the early days of Brightco. When we're designing, I think our, you know, we still have this philosophy which is always talk to the user and in this case it's not just the middle management owners, it's the cleaners. And you can't get them on a zoom call to show you how to use them. You know, that just doesn't work. You have to just show up, right. And so in the early days, I was with Sagar, my co founder, CTO and I, we were out there in the field and you know how these shifts are at night, right? And I tend to be a bit of a morning person. I tend to, you know, wake up early, 6, 6:30, do my workouts and all sort of stuff. So yes, we're at a shift at 1am we showed up, we wanted to say, hey, use this. And you Know, I'm the CEO, he's the cto, he's the tech guy. I mean, I'm very involved in tech and software technology as well, but I work on different parts of business. So there I was asking the person, you know, I'm supposed to be the one to ask them a bunch of product questions and this and that. And then Sagar is the one that asked maybe some of the technical questions. But I was so tired. I was so dead that day. I was just like a zombie just standing there. And then the person and then the saga was there, asking all the questions. At the end, the guy was like, so what does he do? Does he write all the code? Like, pointing at me? Because I wasn't talking, right? I was just so dead. I was listening, but I was like, barely awake. I would always fall asleep. It was really nice. The supervisor drive us around, visit these sites, and then they're just like, no, he doesn't even code, he doesn't do anything here. I thought that was one of the funniest interactions we had, but that was like, hysterical, which is like, hey, like, I'd like to see you use the product. And let's, let's show us what you have, show us your challenges. And, man, you also learn so much because there's also. This could be a whole other topic, but you also have to think about the incentives between the different people. What might be great for management is actually adverse, or what they don't want to show or don't want to give up from people on the ground. And so how do you also manage the fact that stakeholders can be misaligned? Like, that's just the reality of it. And yes, it's a software problem, but it's also a people problem. And how do you think about software fitting into these sort of structural challenges? Like, cleaners would like to leave early, like that. That's the reality of the industry. If you tell somebody they have to work six hours, they would love to leave after two. Like, that's. I mean, who, who wouldn't, right? Like, they would want to go home, get back at 10pm to then spend time with their kids, right? They would love to put their kids to sleep, you know, be with them, you know, that, that you could, we could all get, you know, read them a story before they go to bed, catch the last bus before they have to walk home. Like, these are just realities of their life.

But you're also dealing culturally the differences and the language, and there's just so much there. I think it's we, we don't realize how many variables are in the equation. When you don't, when you are implementing technology or presenting technology. It's just I got so much too of going on the buildings and talking to people and being with the area managers and doing ride alongs and. Because I, I needed to understand and I am Hispanic, I speak the language, I know the people. I've been in this industry my whole life, but I still learn so much from a shift perspective to a coverage team, the equipment that they're using, how they hold the backpacks, it's all like taking a toll on how they perceive a technology.

Everything I learned pretty early on, if I'm going to show up to a shift and ask somebody to use my software, the least I can do is bring them coffee and drop by the local pan and bring her some breads and then be like, here, here's my offering.

Can I, can I ask you some.

Software questions that you're probably not going to like have the most fun answering, but I'd love to just have you try this. Right. So like that's, you know, we have to, you have to cater to who you're working with. Right. In la, that's the population there. In other areas it's a completely different language. Different areas, not all, you know, one population or the others.

Right.

Yeah, we, yeah, that the differences in the diversity of this industry is more than most. We were, we were talking with an airport last week and most of the cleaners speak Arabic and I was just like, that one's more deaf.

Yeah. I'm gonna be honest.

And that's not as easy as Spanish, French, Portuguese, Hindi, Tagalog.

We've seen it all like our populations need it. All right. And so yeah, it's, it's, it's quite. And some people like this, this is the part that's just like mind blowing. Some people don't know how to read. Like, yeah, that part is just like a. What? Like, okay, how do you build a product for somebody who can't read? Yep. Like that's not a large population, but there is a population of people who are not, who are not particularly literate and they are cleaners. Right. And so that's where you're just like, oh, translation. That doesn't even, that doesn't solve it. Right. It's just like you need clear buttons, you need, you need it in a way that they can read the time.

Right.

So okay, okay, okay. Numbers can work, right. But it's like, okay, like maybe they can, you know, Recognize the building. There's certain things like that where it's like, okay, these are okay. But once you start, it gets pretty complicated, pretty quick in terms of how you build for that type of user.

We are doing it.

Like I said, we could go on for hours and we don't have hours. But Gerald, it has been an absolute pleasure for you to be on the show today. Before we head off, I would like you to share the one gold nugget that you would like people to remember from this all over the place discussion of tech people and passionate people. What's a one or two sentence golden nugget that you would want people to remember about an API versus walled gardens kind of concept.

I think we all understand why you want a walled garden and why you want an all in one. I think it's really hard to find something. So just really make sure you talk to all the different providers, actually understand the limits. And sometimes the best answer could be an all in one, but sometimes it's something that's doing a subset of that. Maybe just one thing or five things or ten things and helping you reduce the number. So don't necessarily try to go from 10 to 1. Maybe go from 10 to 9 or 10 to 5 and that could all be a win. And don't get too obsessed about just the number. But we understand what you're saying where you do want to get the number down to some degree, but there's also other things you care about in your business. That's the nugget there.

Awesome. That's an awesome nugget and it's going to be blasted all over social media.

Thanks for not saying pristine. What was the one that I hated? The Pristine Thoughts. Porcelain. Porcelain.

Porcelain thoughts.

Kaden is the best. He really does humor me. He wanted to introduce this segment as the Porcelain Thoughts and I just can't get behind that. Can't.

So appropriate though it's memorable.

It is. Well, I just said pristine.

Very memorable.

We will get it, I promise.

All right, well, thanks everyone and hope you enjoyed. If you are liking these, like, if you want to be a guest on the show and you have some valuable insights, you're a passionate tech person, even if you're not a passionate tech person, but love talking about tech, feel free to reach out to Karina or myself or any member of the committee. Gerald's also member of the Innovation and Technology committee to get on the show. We'd love to have you. Thanks, everyone.

Thanks, guys.