36 - Rebuilding the Foundation: Why Legacy Systems Hold Companies Back - with Mason Lancaster, Senior Data Engineer at CHG Healthcare

Speaker A: I mean, I think speaking from experience, for us, the warning signs were we were not able to do more with the systems we were on. There were things we were totally limited by that could not have existed prior to doing this migration. So if you feel like there's things that would benefit your business that you're not able to do today, there's probably a, uh, data migration that needs to take place.

Speaker B: You are listening to the Product Builders podcast. Each week on the show, we bring you conversations with experts and innovators building digital products. Our conversations help you gain behind the scenes insights into building some of today's most innovative companies. Subscribe and be sure to check out our website for more@, uh, productbuilderspodcast.com when

Speaker C: people talk about building great digital products, the conversation usually focuses on features, interfaces, and user experiences. But behind every great product is a foundation most people never see and data infrastructure that makes everything work. And for many companies, especially legacy organizations, that foundation wasn't built for the world that we're in today. They're fragmented, outdated, and quietly slowing everything down. So what happens when a company decides it's time to rebuild that foundation? That's what we're getting into today. And I'm joined by Mason Lancaster, senior data engineer at CHG Healthcare, where he's been part of a similar effort to modernize data infrastructure behind a nationwide healthcare staffing platform. Mason, welcome to the show.

Speaker A: Thanks, Mark. Happy to be here.

Speaker C: Excited to get into things. I did a big intro. I mentioned che Healthcare there. Can you give us an elevator pitch? What does, uh, CH Healthcare do? In a nutshell?

Speaker A: Yeah. CHT Healthcare is a medical staffing company. So we have relationships with physicians and we have relationships with hospitals and clinics, and anywhere that would hire doctors, we do both permanent and temporary staffing. But our bread and butter is what's called locum tenens. So. So the way I like to think about it that I had to explain to me is if a hospital has a cardiologist go on vacation for a month, a hospital can't really go without a cardiologist. They need to be able to, you know, take care of their patients. And if it's a rural location, people wouldn't be able to get the care they need. So a hospital will work with us to find a, uh, qualified physician that we trust, and we can handle all their travel arrangements and get them to go work and stay at that location for the duration of the assignment. And hospitals are willing to pay more money because they need someone there. It's critical, right? It's super important for them. And physicians end up making more money doing this. So that's kind of the high level what we do. But that's, that's our main focus.

Speaker C: Awesome. And so as a senior data engineer, how would you explain your role to someone maybe even not in tech, in, uh, a way that they can understand what your day to day looks like?

Speaker A: Yeah, yeah. When I'm talking to someone who's not technical, I typically just say I write code. But someone who I think can understand a little bit more. Like businesses. I like to start by explaining that businesses have data siloed all throughout the business. For example, a business could be advertising on Facebook and they have data related to their advertising efforts on Facebook, but they could also be advertising on lots of other platforms as well. And it's not really actionable to log into each platform and view your results. You want to see it all in a unified central location. And ideally, leaders in a business want to see some kind of data visualization, some dashboards that make it easy for them to view the data and do something actionable because of it, uh, and drive strategy within the business. So I sit behind the data visualization team, which is typically called like analytics or business intelligence. They're the ones taking data and building out these visualizations so it can be actionable. My role is to gather data from all over the organization, bring it into a central data warehouse is what we call it, and make it so that analytics and data analysts can use that data and begin building their dashboards. So I'm kind of behind the scenes. You don't really see a lot of what a data engineer does, but it's critical for getting the data so we can actually use it within a business.

Speaker C: Awesome. Thanks for that explanation. You actually answered multiple questions I had here. But at, uh, a high level, you're sitting at the center here, taking disconnected data, turning it into something that businesses can actually use. And I think that becomes really important when we start thinking about how systems start breaking down. So this really comes to life when we look at what happens as companies grow, which, uh, is perfect. So we can get into the meat of this conversation and talk about that specific breaking point. Because I think a lot of companies across industries, and you probably will echo this, still operating on systems that were built years ago, maybe even decades ago. So starting at a high level, why do legacy systems become such a problem over time?

Speaker A: I think there's a couple reasons why this, why this becomes an issue, but I think one of the most important ones is tech Moves so quickly. As we all know, things are changing almost at a daily cadence at this point with what's happening with AI and everything we're seeing. But if we're on a system that's 10 years old, so much has happened within the past 10 years. The cloud, um, boom happened right, right around that time. So if we're using a system from 2016, we might be on prem. We might be paying to manage data centers that we own and servers that we've purchased where we could be getting a lot more performance and potentially cost savings by moving to the cloud and adopting more modern systems. And it's not just about the cloud. There's. There's so much that's come out in the past, you know, five years or so that can make developers and engineers productivity like, go through the roof, basically, which, you know, I can talk to later with what we've seen. But there's just so much performance and, uh, cost benefits, I think, to moving to some more modern platforms.

Speaker C: Yeah. And I'm not technical myself, but in my experience, you know, these systems end up getting layered on top of each other. Tools change, like you said, and before you know it, that foundation that was built isn't really answering what the company does today. And I think, uh, if you don't stay on top of modernizing a tech stack, it gets really easy to get left behind in terms of being efficient in your business.

Speaker A: Totally.

Speaker C: I think one of the key terms I want to get into here is data migration. Uh, can you tell me what that entails? What does that mean for people who might not be familiar?

Speaker A: Absolutely, yeah. Migrations are happening all over businesses all the time. Especially I mentioned how fast tech moves. I feel like every large business has something they're migrating at any given time, and a lot of times that involves a data migration. So, for example, if a business tried to move to a new CRM platform, switching from HubSpot, uh, to Salesforce or something like that, there is a serious data migration that is going to be involved in moving all of your old data over to the new system. There's times where your vendor may do that for you, but if you have a really complex data footprint, you know, you might have to do that in house. And that can be really challenging and involve affecting a lot of other systems that depend on that CRM or whatever it is that you're migrating. So really, really, it's just moving to a new platform, a new tool. But there's a lot under the hood that is involved with moving the data over Right.

Speaker C: And uh, a big part of today's story that I want to get into is that your team implemented a nine month code freeze to focus on a similar data migration. And that's a huge decision. Right. So what led to that call and can you tell us a little bit more about, you know, that story?

Speaker A: Yeah, and I'll add as well, it wasn't initially planned at a nine month code freeze. That's one of the things with data migrations. They often are. It's hard to estimate how long, um, they'll take and they often totally, yeah, they go longer than you think. So initially we thought it was going to be about four or five months, which I think was a little bit overly optimistic that we've all learned kind of at this point. But the, the reason we ended up doing this. So I'll, for technical users, I'll add we were using SQL Server and ssis like some pretty old Microsoft tools that were great at their time, but just haven't been updated to match what's available now for data engineering and data warehousing. And we wanted to move to more modern tools such as Snowflake and fivetran and DBT were some of the main components of that migration. And the reason we ultimately decided to make this code freeze and do this huge amount of work that would slow our business down for a short time was because our leaders saw what was coming down the line with advancements in ML data science and AI and really wanted to use that to be competitive with those operating in our space. And we realized our data foundation was not ready to build on with some of these more advanced things. So we knew the first part of this was bring our data foundation essentially out of the stone age and put it on something more modern that could allow us to experiment with new things that were becoming available that would make us more competitive.

Speaker C: Awesome. And digging into that a little bit more, what were some pain points you might have been experiencing internally, uh, that made it obvious that your existing systems weren't just scaling with the business anymore?

Speaker A: Yeah, there were lots. Number one is we had an on prem SQL Server instance that we had a large data warehouse. And I joined the team right at the beginning of the migration, right when it started. So I wasn't around to really operate a ton in the legacy system. I was more involved in migrating it, but um, it was essentially bursting at the seams with the amount of data we were trying to use. And we operate on batch processing, so every night we have jobs that refresh all of the data so the next morning, dashboards are up to date for leaders and others in the business that use the, uh, dashboards and data to make decisions. And it was taking longer and longer and longer. As we added more data, there was no way to increase performance based on the tools we were using. So we knew we needed something that could provide better performance and just more reliable quality data. Right. Better developer experience, I think, was a big part of that.

Speaker C: Yeah, that's really interesting. And on the flip side here, how did stakeholders react when they heard that new development would have to pause for any given amount of time to kind of focus on infrastructure? What was that like?

Speaker A: Yeah, that took a lot of convincing. Um, nobody wants to hear that. Right. And there's a lot that came up in that amount of time of new data sources they wanted to report on, and we had to put that on hold. So that was challenging. I think for them it was. They did also see the value in what would happen after the migration. Like that would affect them and enable us to turn around tickets quicker and get through the things they want us to build. But also product management was a huge part in keeping our stakeholders happy to allow us to do that.

Speaker C: Yeah. And as you went through the process again, you said it started off with a four to five month mindset, which ended up being nine months. Were there any moments where the team questioned, you know, this decision midway through and set up, was this the right thing to do?

Speaker A: I think we all felt confident about the approach, but we definitely questioned our ability to estimate. Right. And, but, but we all knew, we all saw the value in it during that time. And I think that's what allowed us to keep going, is that not only us, but our stakeholders also knew because they could begin seeing pieces of what would come post migration as we began migrating certain parts of our data warehouse over. So we never at any point wanted to go back. But I will add, there were some tools we did migrate to that we did not like and we realized we had to switch courses. So, you know, our data warehousing tool was not one of those, but there were, there was a data extraction tool, there was an orchestration tool that we realized halfway through this is not going to allow us to do things the way we want to. And so we had to do a little bit of backtracking and adjust to new systems that we didn't plan.

Speaker C: Um, that's awesome. And actually, I'm really curious to know in terms of the prep work that went into that. Right. So you had in your mindset a tech Stack that you wanted to update to. Can you talk about both the prep work as well as, like you said, you migrated to something was not what you wanted. What did that mitigation look like and how fast did you have to quickly kind of spin around and find something else that answered the business solution that you were trying to achieve?

Speaker A: Yeah, absolutely. I mean, the prep work was big. Like it involved looking through every layer of our data warehouse, every table, and determining, you know, how complex were each of these objects. Unfortunately for us with ssis, your code is kind of siloed and broken out into different pieces. So it was more difficult than just taking your code and plugging into a new tool. It was going through and deciphering these kind of legacy ways of doing data transformation. So there was a little bit of planning with like, how complex are each of these models or objects, if you want to call them that? As far as switching gears, there were two big tools I mentioned that we switched from. One was a data like extract and load tool. And, and we knew pretty quickly into the process this was not the best tool. So with that one we immediately purchased a better tool and began using that. That was, um, a pretty quick shift to we have to switch right now. The other one was our orchestration tool, which we realized it wasn't quite as critical in the moment. It was something we could do right after the migration. So a couple months post migration, that was one that we switched and that one actually involved quite a bit of work because it, it orchestrated all of our jobs, it touched everything that we do within data engineering and it was a lot of work. But again, we've seen the benefits of being on a tool that provides a better developer experience and is more reliable than what we had prior to that.

Speaker C: Awesome. And I know, I mean it sounds like on paper this is a, uh, technical project, a technical issue. And I think a key thing to note that is that it's actually, you know, a business issue. Right. When you're on a bad legacy platform tech stack, you know, decisions slow down, teams lose trust in the data, and suddenly that product experience starts to feel that friction too. And I think this is where it becomes really relevant for anyone building product. Because I'd say any large org will probably have a moment where they have to have this decision themselves. Do we keep shipping on product or do we stop and fix what's underneath? Uh, so switching gears here a little bit, I want to get into the trade offs between short term pain points a team might experience versus long term product health and the Benefits of doing a migration like this. How did your team think about that trade off between, you know, continuing to ship features, continuing to make improvements and uh, then also investing in infrastructure? Uh, you said stakeholders all kind of were on board to begin with and understood the importance of it. But can you talk about the conversations that were had and how you got everyone on board?

Speaker A: Yeah, we um, the first thing I'll mention is our team was, was not able to at the quality, at the rate that we, that our stakeholders wanted. Right. We had a long backlog of things we wanted to do simply because our stack would not allow us to operate as quickly as we wanted to. So already there were pain points that our stakeholders recognized with not just our team but like the tools we were using that limited us. But there was, there has been a huge trade off. So uh, I'll mention a couple of things we've seen post migration that have shown why this was so useful or why it was. So I guess the ROI we got from this. So the first one is prior to doing this migration we do EES surveys. So we give surveys to our or SES surveys. Sorry, so service effectiveness surveys. We give them to our stakeholders and ask them to rate us all throughout our company. And for a couple years we had gotten a pretty low score in data engineering simply because we could not do what we wanted to because of the tooling we were on. And we did that nine month code freeze, finished that in 2024 in like the fall. And then we had about the same level of score, you know, not great and obviously so we spent nine months of the year not shipping new products, we were doing a code freeze. But compare that to 2025 which was virtually the same engineers, same leaders. We had an insanely high score compared to where we were previously. So we went from one of the lower scores in the company to one of the highest if not the highest in engineering. So our stakeholders were happy with the work we were doing, the rate at which we're completing tickets and the relationships that were built in this process. And then not only were our stakeholders happy, but we also, we keep track of productivity per engineer. So that had been pretty stagnant prior to this. 2024 was the same going to 2025. We had a 60% um, increase in engineer productivity. So the results speak for themselves. Right. It was a huge pain. It slowed down the business for a short time. But the long term benefits of this are engineers are happier because we're using better tools that provide a better experience. We're shipping Products faster. Our stakeholders are rating us with higher ratings because they're happy with us. And now we're, we're doing exciting things with AI and ML that we previously were not able to do.

Speaker C: Uh, one of my upcoming questions was going to be, you know, what were the biggest improvements people started noticing? So really great stats, uh, in terms of what you were able to share there, at what point did people start to feel like, okay, this was really worth it and we're seeing the benefits. Was it once, you know, everything was completed, or do you start seeing benefits towards the tail end of that migration? Like, like, what does that look like internally?

Speaker A: Yeah, for us, I think it took a little bit of time. Like, there was, there was some trust that needed to be built with these new products with our stakeholders. So it wasn't immediate that people were, uh, our stakeholders were like, you're doing so great. We love this. It took a little bit of time. I would say within, you know, six months or so, our stakeholders started noticing that we can complete their stuff quicker than we were previously and we're ensuring better data quality because our tools allow us to focus on that. So I think for me, it took a little longer than expected because as the data engineering team, as soon as we finished, we were thrilled and excited and saw the benefits right away. But trust is built in drops, right, and lost in buckets. So it took a little bit of time for them to come around and see how great it was.

Speaker C: That's a great quote. I'm going to write that down for the future. But speaking of trust and building on it, during the freeze, what were some of the hardest moments for your team? So what kind of communication did it take to keep everyone aligned and kind of optimistic during a process where everything was frozen? What did that look like?

Speaker A: Yeah, I think the biggest challenges for us, like, we saw pretty, pretty quickly that things were going to take longer than we thought, but we still didn't think it was going to take nine months. And there was one point where we got to testing that took so much longer than we thought because, uh, that's a critical part, right. We can't migrate data to a new platform without ensuring that it's reliable and that our calculations and our metrics are looking the same as they were on the previous platform. Testing took so much longer than we thought. And I think the key thing that allowed us to keep going and keep people on board and keep people happy was product. I think I mentioned that earlier, but at the start of this whole migration, we really built out and hired a lot on our data product team. And they were people who had great experience, both working technical roles but also keeping people happy and their ability to understand the technical requirements of what we were doing and what engineers were going through as we were dealing with this big project, but also able to speak to our stakeholders in a way that I don't know that they understood and maybe a less technical way that kept them happy. That was key. And again I mentioned like our, our SCS score went up so much. I think a big portion of that is not just because we as engineers could do a better job in our tools, but because product was able to build better relationships. So although it was a data migration m, it was also, you know, building out our data team, I guess and building out data product.

Speaker C: Yeah, in my experience, you know, everyone focuses so much on, on that end user experience on the things that they can see on, um, like that razzle dazzle that exist in product and sometimes they forget that like the technical updates, technical pieces can have so much impact on what you're doing and can be improved. Focus on just like the basics and the groundwork. So I think that stuff, it's easily forgotten when you're so focused on, you know, innovation, new features, iteration. So love the anecdotes that you're sharing here. But looking back at things, would you approach anything differently? Would you have done anything a little different after this whole process has been done?

Speaker A: Yeah, I think there's a better understanding of maybe how to estimate work and things that take longer. One of the things I love about these new, at least in the data engineering space, these new tools are a lot more code first which allows you to migrate to tools a lot easier. So at this point if uh, we were to migrate to similar tools that exist in the industry today, we could do it so much quicker than we were previously. So I think this is already kind of a growing trend. But for me personally, don't get locked into tools that are not code first because code is so much easier to migrate than some of these other drag and drop UI tools that have existed, you know, ten years ago. Um, I think that's a big learning. You know, don't get into systems that are trying to get vendor lock in, which I think is also another trend that's kind of going away. I think, um, keeping things open and easy for people to switch tools seamlessly seems to be more popular. But that was a big learning from this project.

Speaker C: Awesome. And then one more question in this category here, but um, what did progress look like as a team, as a whole, during a period where you weren't shipping features, was it just really focused on progress on the data migration or were there other things that your team was able to look at that helped them feel that there was progression moving forward?

Speaker A: Yeah, I think it was 95% data migration. There were a few things that were critical that we had engineers or leaders tackle during that time outside of the migration and then come back to continuing to assist with that. But there was a big like team building aspect with this. We had, for example, there was one week we had a handful of models we wanted to get through really quickly and our leaders. It's kind of a tacky name. But these, these models are called AGs. They're aggregate models. And so we had an Agathon, which, uh, kind of a tacky name, but it was super fun. We all got, we all came into the office, we had a bunch of food and you know, we, a lot of us worked late. We grinded that week through all these AG models and migrated them and we actually completed them in a week. We had prizes for who could complete the most. Um, so there were little things along the way that I think kept people engaged and kept people excited about what we were doing, even though we were going through challenges, uh, during that whole nine months.

Speaker C: That's really, that's awesome. I love hearing that. And that sounds like an awesome way to keep people engaged during a period like this. And I think what's really interesting is that, you know, the biggest product win here isn't a new feature. It was creating and updating a system that actually allowed better products to exist in the first place. Uh, so that said, I do want to zoom out a bit because this isn't just a healthcare story or a data story. I think this is something a lot of large orgs run into at some point, regardless of any industry they might be in. So from that lens, if someone listening works at a company dealing with legacy systems, what early warning signs could they potentially look out for if this is something that they know is coming up for them?

Speaker A: I mean, I think speaking from experience, for us the warning signs were we were not able to do more with the systems we were on. Uh, there were, there were things we were totally limited by that could not have existed prior to doing this migration. So if you feel like there's things that would benefit your business that you're not able to do today, there's probably a data migration that needs to take place, you know, or upskilling. Right. That was A big part of this too. Like we all had to learn new tools and skill up in these areas, so that that could also be a part of being able to do things you are not able to do currently. But I think that was our biggest indicator was we're limited in the abilities we have because of the stack.

Speaker C: That makes sense. And since you've gone through the process, where do you think teams might underestimate the process and when they start thinking about modernization, are there kind of key things that stick out to you?

Speaker A: Yeah, I mean, I mentioned testing. Like that's the. That was the biggest thing that was overlooked was the level of testing that was going to take place in something like this. And I think that's true for any kind of data migration or migration in general. Right. That's a significant portion of moving to a new system. But I think also, you know, for us it was important to spend a lot of time looking at different tools and trying things out before doing that. And again, that was an area where we did make a couple mistakes by getting into tools that didn't meet our requirements as well as we hoped they did. So underestimating the amount of time it takes to really explore the landscape of what's available today and what the best options are, that's great.

Speaker C: And actually one of the questions I had that I feel is really relevant to that is are there small steps teams can take before committing to something as big as a full migration? So it sounds like obviously exploration and planning is one. Anything else that comes to mind that people can start doing now before committing to like that big long haul?

Speaker A: I think building trust with leaders is important. Right. Like our. There was a good relationship with leaders who also wanted this. If, if leadership isn't on board, it's never going to happen. I, um, mean, it has to come from the top down. So for us, we were lucky because it did come from the top down. There was leadership that saw the value and also saw the realization that we had to bring the Data foundation there first before exploring new features. So I think, you know, beginning conversations with leaderships within an organization to make sure everybody's aligned on what are the challenges and what are the potential opportunities to migrate to new systems that would benefit the business. That relationship has to be in place first.

Speaker C: That's awesome. And I've got one last question here, but are there signs that a company is actually in a good place with their data? So I know a lot of legacy companies will, uh, consider this. We'll talk about modernizing. Right. But are There signs on the other side that say, you know, actually, this might not be the time for it and you're in a good place.

Speaker A: I think a key indicator that you're in a good data space, like you have a good data foundation, in my opinion, is a. That the data is used by the business. A lot of businesses claim they're data driven, but really at the heart of it are not utilizing the data. And nobody really knows that except for the data team. Right. Who's responsible for that? And I've worked at companies where there wasn't a ton of adoption with the data products we were building. We were kind of just building things, hoping people would use it. The nice thing about CHG is there already was a lot of adoption. So as far as, like, I think your foundation kind of has two facets to it. One is like, do you have a data foundation, a data warehouse? Is it being used? Is the business getting value from data in any way? And for us, that was the case. The other side of that is the actual stack, right. The tooling that enables you to provide that data. And for us, that was where we were kind of in the Stone Age and needed to bring it to a more modern era. You're in a good data space if data is actually being used and the business trusts what you're building. As far as the foundation, in my opinion, you know, you're in a good space if you're able to accomplish the things that you and the business want to do. If there's any gap there, then it might be time to consider operating in different tooling. Awesome.

Speaker C: Ah, that's a really great tidbit there. And I think, um, you know, takeaway is pretty clear. If your foundation isn't right, everything built on top of it becomes even harder to do. So there are definitely clear signs and indicators whether you're doing it right or wrong. Uh, so thank you for sharing that. Um, and I know we've covered a lot today, Mason, but before we close out, let's switch gears here. I want to do a little quick fire session. Our quick fire segment. I'm going to throw a statement your way. Just want your quick take on it. Short answer, kind of. First things that come to mind here. Uh, cool. Let's see, let's do two or three here. But, um, what is one skill product builders should develop that's often overlooked?

Speaker A: Um, I kind of mentioned this earlier, but I think the communication skills, again, that was like the key in our project was communicating with stakeholders.

Speaker C: Awesome. Uh, let's see what is a recent trend in data or in tech or in product that you are paying attention to right now and hyper focused on AI.

Speaker A: Agentic coding tools like cloud code and other similar tools that are available to now I think are for us. They're changing a lot of how we work and I think it will influence a lot of people.

Speaker C: All right, uh, last one here. I know you also teach on top of your day to day job. What is one thing you try to instill in students that applies directly to the real world and that you pull

Speaker A: from your experience right now, it's that you are responsible for your own learning. My students can use, I encourage the use of AI and to be honest, they could probably use AI to get through the whole course and not learn anything. But they are responsible for their own learning. The tools available are amazing, but if you don't take a minute to understand what's happening, you're never going to learn.

Speaker C: That is great. I've had a lot of conversations on AI. We didn't dig into it too much today, but that is a great bite for students and actually probably professionals as well.

Speaker A: Yeah.

Speaker C: But, uh, before we wrap things up, Mason, we like to end with what we call is our majestic bite. If there's one thing listeners can walk away from from this conversation, what would your majestic bite be?

Speaker A: Yeah, um, a quote that I heard from a leader at a business that I was at, uh, previously that's always kind of stuck with me is you as an engineer or developer or whoever are hired to do a job, not to use a specific tool. And with what we've talked about here, that's very true. Any engineers that got attached to the tooling we were using are no longer using that tooling. And it would be a challenging shift to use something different. And I've noticed, I don't know, with the way tech is going, things are changing so rapidly. Things. For example, I haven't shipped any code that I've written to production in the past two months. AI has written 100% of it. And I've been there giving requirements and steering it. But if I was attached to coding in a specific way, I would not be getting the gains and the opportunities I am by using these AI tools. So, um, I think it's a key to just always remember the concept of your role and the value you provide to the business rather than getting to use a specific tool or doing things a certain way. And I'll also just kind of plug a book for anybody interested in data engineering. The fundamentals of data Engineering that was written by Joe Reese and Matt Housley is uh, an excellent book. If you're interested in that at all or wanting to get into it, learn more about it. Covers everything from any part of data engineering that could be something you would have experience with and does it in like a technical and non technical way. So I'll plug that book for anybody interested as well.

Speaker C: Awesome. Mason. That was a fantastic bite and thank you for being on the show. This was a super insightful conversation. I think a lot of people talk about building better products, but this is a great reminder that sometimes that work starts in places that we don't see or that we can easily neglect and revisiting the groundwork has benefits that outweigh those short term pains that we talked about. We'll link to CHG Healthcare in the show notes and I think for anyone listening, this is one of those conversations again that reframes how you think about what it actually takes to build something that works at scale. For those of you tuning in, thanks always for listening. If you found this episode helpful, give us a follow, leave us a review or give it a share. This is the Product Builders Podcast and we'll see you next time.

Speaker B: Thank you for listening and we hope you found this episode insightful. If you enjoyed the show, please leave uh, a five star review. You can find more information and links to all the resources mentioned in today's episode at Product Builders Podcast. This episode is brought to you by Majestic Apps. We imagine, design and build digital products with clients like Chevrolet, Audiomac, IBM Barefoot and more. You can be sure you're in good hands. Reach out to us@mesticapps.com.