https://www.listennotes.com/e/3047b62baabb4edb81208089d386582a

Welcome, everyone, to another episode of Hard Refresh. I'm your host, Caden 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 BrightGo. Gerald, take it away. Introduce yourself, my man.

Hi, everybody. My name is Gerald. I'm the CEO and one of the owners of BrightGo. Real quick, my background originally was in software and technology at a Korean 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, builds 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. 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 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.

Thank you, Trana. Appreciate it. Really appreciate it.

Back at ya, Kaden. Oh, that's awesome. Well, I'm gonna top it while Gerald's about to top it. So before we get started, Gerald, we're gonna do two truths and a lie. So this is a key moment. 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 gonna share with us two truths and a lie and Karina and I are gonna have fun and 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 coating 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 is 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 is true. I was trying to look at the pa, listen to the pauses in his voice. And so that's always like my, Finding my tells.

Wow, great. Yeah.

I'm a communications major.

The first one again, the first one.

Was, I'd 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. The 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 did have a few minutes to really think about it.

I'm gonna say gallbladder. You can say something different. Don't let me peer pressure you.

I'm personally leaning to that one, but 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?

That was the third one.

Dang it! We're both wrong!

He really threw us off.

Yeah, we were wrong.

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 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'm just like, she's like, shut up.

Like, we don't need that here.

Oh man, so.

All right.

Well, the third one. yeah, I took the third one being a lie. Remind me the specifics of that one again. What did you say?

I said I'd want. I'd. I'd been a semi-finalist in a. 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. the 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 of me 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. I'm at a startup during my senior year. Most people were out drinking and having fun and I was at a, in a garage running code with the CTO. You know, 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 gonna compete.

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. Better 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, I really couldn't stand out that much in the really early days cuz 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, yeah, yeah, it was 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 one you guys want.

Yeah, so we are terrible at this is the moral of that story. But super fun.

Karina went back and be like, all right, we've got to 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.

It's true.

Gerald, you were good.

But yeah, if you've missed these True 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 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 Trading Trap with Vince and Tony. It's posted on LinkedIn. And Caiden and I are really, really excited to be able to bring the what Are youe Doing? Workshop. It's an 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 of episodes in person. while we're there, it's gonna be fun. 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 some of them. There are awesome people out there that have an understanding, but some people don't understand 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. Normally, regular people, when you're trying to make something talk to it, you might use a CSV or Excel upload, something like that. The way that two computer systems would 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. Nice.

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 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, general trailer 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 is 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, who's no showing repeatedly. There's a lot of information around maybe tickets and issues and complaints that are coming in as well. 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 enough 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 be, are there walled gardens that are stopping systems from talking to each other versus can these systems talk to each other 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 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 try to understand from 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 WinTeam. And so for operational perspective, We were all using Quora, but they were using it for accounts receivable to 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 BrightGo, you know, because there's pros and cons to both. Have you kind of settled on one.

Way that you want to take BrightGo in that regard? Yeah. Our philosophy in general is that, like.

From the lens of the person running.

The business, they just want everything to work. That's just the view from that lens. So I think, and so, like, if you have an application that can do more things, I would say one piece is 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 I, 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 do a lot of things. But I think 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 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 things really well. So yeah, there's general ways. So that's sort of the high level and how we think about a BrightCo. 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 is 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 walled gardens. 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's something that a lot of BSCs don't necessarily understand from an inspection tools perspective. like there's proposals that are including OTV or smart and specs. So you have to use other systems. So to create an eco 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 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 we're trying to move towards that end, but we're not there yet. We don't have literally everything. That's impossible. And so nobody does. Anybody who says they have an all-in-one doesn't, because 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. We're adding a lot of different things, so it's becoming more comprehensive over time in those certain areas where we definitely haven't covered yet. That's just the reality of how hard it is to do that. 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 five, six or three, 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 wild 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 one, two, three 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 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. It could be a little more complicated cognitively. So walled gardens are, I would say, cognitively easier. 'Cause 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 to be gained. Also, there's a lot of security challenges, right? If you're going off sending data left and right, everywhere you have all these people accessing 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 steal man that.

Very diplomatic, very dramatic 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. 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 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 a hundred softwares and. I don't think this is a hot take. This industry doesn't have that appetite. This industry is not one where you're trying to have 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 go ask two companies, they don't bid the same way. You ask two companies think about inspections or how they think about anything, they don't do it the same way. So in any given area, It's actually very hard to find something that can do many things. It's just a big challenge. And that's the challenge person that as a company we're trying to take on is 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. You have to show up even stronger with a better, you have to say, okay, I'm going to really learn this part of the product and actually nail it as opposed to just 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 got to 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 software start to specialize to some degree. 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. Like that's what we should all strive to be if we're building at any given area. But from the owner's perspective, fewer is better from their lens. So I do have to empathize, like 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. Um, 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 the 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 where I'm going through discovery and I'm like, okay, what are, 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 it. 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 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 gonna be okay with that.

Yeah. Right.

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, 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 Otuvu 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 can be scary at times to think about multiple systems. But the reality is, and I love how you said this, 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 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's what matters. It doesn't matter what we think. 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 coexist, right? 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 heading in between. That's what they want, right? And now there's the reality of how practical it is and there are certain challenges, but I think it's really important for us to all to always understand there's a really good reason why they want that, right? 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 costing correctly, putting a lot more pressure on the operation 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 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 upsells, the way that you make sure you're making money. So 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'll 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 Maximize. It's called service CEO, and my mother at the time was only having 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 and you go up to 70%. But 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, people sometimes get excited. They're like, Hey, Gerald, what do you build? I would love to learn more about Branko. I'd love to use your software. There's all these questions around this sort of stuff. And then I usually ask them, what are you using? And then they'll usually say, this, that, this, that. I'm like, those are great tools. Have you gotten the most out of them first before you switched? That's something that surprises people because in their view, they're like, Hey, why am I not trying to sell them and earn their business? But for my lens, it's like switching software is a lot of work and it's always easier to incrementally get more out of your existing software. And for my lens, I usually know the limits of different I've got a lot of providers out there because I've seen them in the wild. I see how well they work. And so I'm like, yeah, you can 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 a value, then let's talk, right? That's a different type of conversation at that point. And so I think that part's really important because again, some and some servers are just hard to choose. 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 tool or how it's built. And that's different than, of course, as well, because they've spent that extra legwork and they've hit their limits, their cognitive limits of their team to use that tool. So I think that's where it's really healthy discussion, I think, 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. We're not going to just switch cold turkey. 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've already tried everything in 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. Cause 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. Um, 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 costs 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, see your pants with 30 cleaners, 50 cleaners. That's different, right? But if you have 400, right? Like you're not gonna, you're, 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 what 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. 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 four, you know, hits the p l type of goals because you're taking from the p l in the short term as well. So that's sort of the way that.

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, 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 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 curious, Kayden, from your perspective, an onboarding strategy, how does that work for your team? And how do you guide the conversation for VSCs?

Pilot.

Okay.

We are so adamant to go test what they think in theory is the best way. I've shared this story so many times. I was on site at a hospital out, just outside of DC actually, Karina, and this entire building service contractor, 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 idea. 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 gonna 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 gonna have to go back to the drawing board. And I was like, that 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 me a thing. 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, I've learned from when I didn't do that approach, and I just thought that they were gonna, from a front lines perspective, embrace a new feature that I was rolling out. And this was like very early on. I was 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 be like, here's a link, install it, and then it just gets 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 line, right? You can only fit about seven words per page, right? So you then start to realize like, okay, these are highly constraint design criteria. Every single button makes experience worse. Every single checkbox makes 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't afford to train them a little bit, not a ton though, but, you know, as, 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, hundred 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 Vetta and you start to realize that there's actually interesting patterns between it in terms of different populations.

I'm nerding out here a little bit.

No, no, I love this.

When, so we, we were designing, I'm like, can we get another hour? 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 Brightcove when we were designing it. I think 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 stakeholders. And you can't get them on a Zoom call to show you how to use that. That just doesn't work. You have to just show up. And so in the early days, I was with Saagar, 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:00, 6:30, do my workouts and all that sort of stuff. So yes, we're at a shift at 1:00 a.m. 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 a bunch of product questions and this and that. And then Sager is the one that asked me 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, at the end, the guy was like, so what does he do? Does he write all the code? Like, pointing at me. Cause 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 would 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 his character, which is like, Hey, like I'd like to see you use the product and 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? 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? Cleaners would like to leave early. Like 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 wouldn't, right? Like they would want to go home, get back at 10 p. m. 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 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.

Yeah, 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 panaderia and grab some breads and then be like, here, here's my offering. 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, completely 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 dead. Yeah. Kind of, 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 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? Yeah. 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 when you're just like, oh, translation. That doesn't even solve. 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 are 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 10 things and helping you reduce the number. So don't necessarily try to go from 10 to one. Maybe you go from 10 to nine or 10 to five. 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 is 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 thoughts.

Porcelain thoughts.

Caden 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, Christine, 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 a member of the Innovation and Technology Committee. To get on the show, we'd love to have you. Thanks, everyone.

Thanks, guys.