Innovation at the Edge: AI, ERP, and the Art of the Calculated Bet

Welcome to Practical Product Management. This is the podcast that Marilyn and I host where we talk about how product management is done in context. All the theory and the books and the ideas are all lovely and great, but product management is done in the context of your company, your team, your season of life as a company, and, and space. So today we have a guest. We have our person that we need to know personally, which is always fun for us, Evan, who is joining us. And so Evan, I'll throw to you to let you introduce yourself and then we'll dive in. Hey guys, look, I'm very excited to be here today. My name is Evan J. Schwartz. I'm the Chief Innovation Officer of AMCS Group. AMCS is the largest leading SaaS provider for resource-intensive industries. Our goal is to maximize the margins, profitability of our customers while also doing the best we can do for the environment. Awesome. Very nice to meet you, Evan. Nice to meet you guys. Excited to talk to you and learn more. My first question, my first question is like, what is a chief innovation officer and what problems are you helping companies solve? That's a great question. So, I would say most companies tackle innovation sort of as a shared responsibility. So, it's not like companies aren't innovative. Every company is innovative. You reach a certain size though where you need to start putting a focus on those things that are innovation because everybody across various departments and companies have responsibilities and roles. So, this allows us to compartmentalize. So, what is innovation really? It's taking a bet on something that we think is going to dramatically change the way our customers operate, increase their revenue, simplify, reduce costs, optimization. Maybe it's some better way for us to do something. Everyone knows a lot about AI going around the world. I mean, you can't— it's— I've seen it on the front of an orange juice gallon. AI is making everything now. So, a lot of what I'm doing here over the last couple of years is making sure that AMCS is doing AI right, right? And that's a tough, that's a tough battle when you look at what's happened over the last couple years. This isn't everybody, there's a lot of people doing it right, but a lot of people are not doing it right. MIT's report was very damning from last year, you know, 90% to 95% looked good early days, didn't scale. If you go to Gartner, it's still in the 75%, 65 to 75%, can't get it out of POC. How do you get it there? So for me right now, the critical roles and bets that I'm taking, and there's a variety of them, is we take it in, we build a team, we build the use case, we make sure we're following, you know, ethical, moral processes. All the guardrails are there. We get it way past the proof of concept. And then once we've got it critical mass, we kind of lift it up, put it back into the product organization who then takes it, perfects it, marketing puts it in the world, and then we move on to the next bet. You reach a certain size in a company that if you don't start to put a focus on innovation, it starts to slow down because the company in itself has a hard time moving in a variety of directions because you've built a lot of products that you have to maintain and support. This gives me the ability to remain agile and take a run at a lot of good bets to see what's going to be innovative and work well in the market. So how do you— sorry, I'm going to jump in. No, no, go ahead. Similar question, but So when you say that, it sounds, I mean, I think it sounds great. I totally agree. I guess I'm a little, it makes me a little like itchy and makes me close one eye when I think about like, how do you just hand it over to product? So that's a great question. That is a great question. The job of a product manager is to be— That's absolutely right. That's a great question. Yeah. So the reality is, is I'm not necessarily an island unto myself. Myself. So as we bring in use cases and best bets, I've got an innovation council filled with SLT people that are going to fund these projects. If a project gets funded as a bet and we've gone through, we've done the use case, we've done some of the market analysis, we understand why we're doing it, then it involves, all right, product person, this is going to land back to you. How much can you give me from your team? Is it oversight? Can I borrow your product manager or a product owner that can sit with the team? I know that you may not have the development resources, you may not have all of that. So what really an innovation officer is, is a separate PMO program where I'm taking— it's a matrix organization where you're pulling people from a variety of disciplines into a concentrated project. Or goal to get something across the line. I don't really own those resources, I'm just managing it. But it is different enough because we would take certain risks that might not be taken within a mature product group or organization. So it gives us the ability to run, fail fast, to prove things out in a way that maybe you wouldn't take those risks in a standard product development organization, right? And if it— and if I do fail, so that's why everyone's got different profile, right? But if you're serving the industries that we serve that are highly compliant, highly regulated, you don't always get to take those risks. And this gives us a medium to run at a narrow vertical, the risk, but heavy oversight from the product organizations that are going to be the receivers or the benefactors of, of this outcome. This just allows me to run fast, fail fast if, if we can't get there because we're answering questions. Really, if you think about it, We're filling in the question marks. And if we can't get there from there, immediately the council says you've proven not a good bet. Save as much money, put it back in the best bets. Let's run it the next one. Right. And that just allows us to kind of really stay at the cutting edge while still delivering that mature product to the industry. That's how we're— that's how we're staying on the knife's edge. How do you source ideas, Evan? So to Leah's point, like one, one of the things that we are pretty passionate about is A product manager must know their customer, their customer problems. They must understand the business benefit, and they must be able to work with technology to build something, right? Um, and it sounds like, like you're sort of held aside as this like incubator, which is, which is great. It's fine. Lots of companies have them. Um, but are you sourcing ideas from the people that are closest to the problems? Where do you get all your ideas from? Where does that come from? Yeah, so our product organization is very tight with our customers. We've got very sticky, what we call lighthouse or champion customers that are very connected into our product organization. We find that there's a lot of movement at the tier ones. Those are the ones that are shaping the industry with which we come in. But we also have a strong touch to the boots on the ground, the mom and pops, the starters because that's where most of the innovators are, you know. And we've got a customer right now that I'm— I love that is they came from a different industry altogether that— so they've come into the waste industry with very different views. They came from a logistics industry, so they're treating everything from a logistics, but— and they're killing it, right? Because they're looking at that industry in ways that the traditional industry that's grown up over 100 years has either lost sight of or isn't trying it because it's, you know, I believe there is no change without pain. If you're not in pain, why would you change? So if you're a very comfortable industry and you're making really— I mean, if you think about even what happened during the pandemic, the waste industry ticked on. It was mission critical, right? Most of them grew, right? That feels like a very strong industry. We must be doing something right. And then here comes in another view going, yeah, but look how much brighter we could be with this. So that's bringing innovations into my department and it comes in through the product organization, right? What they're looking at is I can bring funding and take risks on a new product idea that our more mature product organization would have a hard time. It's in the backlog, but it sits at like a priority 11 or 12. I can start to take those, get them on the rails, hobble a team together real quick, and at least get the questions answered. Is there a there there? Get it to a stage that is oversight because it's their engineering department that's running it. I'm not inventing new code. And if I am, I have that architecture team like on that product, right? Once we're laying down the plumbing for our own hosted models and we're running down the plumbing for a lot of our innovations, architecture is right there. I might hire boots on the ground, external teams to be the guys that wrench it into place. Just for a capacity standpoint. But it is— it just comes in and feels like it was built from the product team. We follow the same standards in organization, so it's easy for them to adopt. It's not easy for them to direct energies at potentially what I consider high-risk, high-reward ventures and product features. That gives me the ability to run at it. And I— and I'm— my goal is how many of these do I get to fruition that have the ROI return versus how many do I run out and that crash and burn. And. And if they crash and burn, I need to crash and burn as cheaply and as fast as I can before, so we can refund that money back into the innovation budget. Is that, does that help out? That answers my question. So I'm like, now I'm gonna be a little provocative, which is sometimes my role. Sometimes Lee is the provocative one. How do you keep from, like, I feel like this is the part that everybody, the engineering teams, the product teams, like this is where like strong product Product managers thrive. Like, they love to solve hard problems. They love to innovate. They love to test ideas. How do you either involve them deeply enough that they don't get frustrated that you get to do the fun stuff, or like stop resentment from building? Like, how do you manage? They are doing the fun stuff. Like I said, they're deeply involved in every one of these channels. In all fairness, I'm going to say I do the stinky parts of the job, right? Your product manager wants to be inventive, do the mockups, understand it, talk to the customer, talk about how great it's going to be when this goes out. And then, well, yeah, but you realize we're going to have to carve out this new infrastructure. We're going to have to change our CI/CD pipeline. Okay, Evan, I need you and your team to go work that piece out, figure it out, and tell me that it's doable, do that. It can just drop into the CI/CD, it can get into our deployment platform, it hits all of our quality metrics, go hand handle, handle, and I'm just going to keep feeding you the use case. You go make it a real thing. You get it to a state. I don't take it all the way to the finished product. I take it to the end of the lighthouse. That's my job. My job is I have like a stable of 25— we're trying to get it up to 30 because we're in 80 countries around the world at various levels— tier 1, mid-level, and small— that are willing to travel the journey with it. They'll take an early adopted product. They recognize they're suffering this thing's an arrows. But, you know, we make it— maybe make it worth their while, right? They get, they get a lot of input, and they get some nice deals around the cost of this new thing. And they get a little bit of a runway in the market to see where the advantage is, right? So at the end of the day, it's, it's customer-led, product-driven. My job is just to drive the Matrix program, to execute on it, and then have eyes from SLT on the funding so that we can run fast to a point that it's not as much of a risky bet that I've got it to a known state, at which point I would not be able to run fast if I owned it beyond that point anyway. Now, I start to take on the drag of a product, but then they can take it in. There's a hypercare period between me and product where they would take that back in. And in fact, a lot of our— now I'm getting maybe into the weeds, but a lot of where we build the team, if it's so new, And AI has a lot of this as it's deeply embedded. Those members might have been contract for me, go to contract to hire and join the product team, and they kind of go with it, right? I mean, maybe part of the— maybe part of what you're getting from us is that both— like, my background is as a technical product manager, right? So I like that part, right? So I like the— I like the part that Marilyn described, but I also like the carry it over the line. And you're dealing with two product people who also lead engineers. And so who have— So you would be deeply involved in every one of these initiatives. I don't have, I don't have a, I don't have a product manager or product owners. I borrow and steal. Yeah. Right. Every program I work on is a matrix hobbled-together initiative. I need how many engineers can I get? How many outside resources do we need to hire new tech? From the outside because we don't have the skill set. Those kind of get a little marker above their name of we're going to have a talk with them at the end of this journey because I'm adding that new skills. Um, I'm, I'm a strong and ardent fighter from a skills-based organization lives in the engineering world and talent lives in the product world. I should be able to go to the market and buy a developer that understands React. I should be able to go to the market and buy a developer that understands cloud computing. I get nervous when I find that my developers have a lot of industry knowledge. That makes them really strong and fast. But we all— I'm trying to avoid building boutique tech that I couldn't go to the market and say, I need a guy that knows this because this is some proprietary platform technical solution. Not that I don't always get my way, but I still fight it, literally, right? And so, because I just don't believe that— I think the golden cows are in your world, not in the technical side of the world. Interesting. All right, so I'm going to disagree with you and then I'm going to change the subject. I was just going to change the subject, but now I want to like talk about this. I think that one of the ways to drive innovation at scale is to bring problems to engineering groups, not solutions. And where I've seen innovation at scale personally is when you have a really, like, small harmonious set of people, cross-functional, usually a product person that's very technical, usually a set of engineers that deeply understand the customer problem. And you bring the problem of the day, the problem du jour, which again has the elements of customer problem, the business wants to solve this problem, and the business wants to solve this problem now, to a team. And I've actually seen some of the most innovative work come out of engineers that just thought about the customer problem. So, I definitely think of it as a little less, personally, I think of it as a little less like skill for hire. And I look for those engineering pods that want to make a difference, that are deeply passionate about the customer problems. And then that product person that can bring the business lens to it, like the why should we solve this now? Because there's a million problems to solve. The question is why should we solve this problem now and what benefit should we as a business expect out of it? That's not actually the conversation I want to have. You've said two things that I'm really curious about. Well, I look, I just want to qualify and I'll defend your position is it is a hotly debated topic within our organization. Organization. Yeah, but I cleanly separate technical innovation from product innovation. I put those in two different categories. I think one feeds the other, but I, I think you can do technical innovation, which we do. We call it the GIC. It's a wholly separate innovative track under the engineering. So I don't want to think that we're stifling and everyone's just code monkeys. That's not the world. But those innovations are to solve the product innovative solutions that we're trying to solve, and that happens in the engineering department. You guys sound like you have a very tightly blended technical product organization where you guys are down into, you know, how is it stored, how is it encrypted, how is it managed and scalable. We're a little bit more product and then engineering driven. We have that middle layer where the engineering person would be you guys. So we, we call them our, our heads of engineer. I'm not gonna— I almost threw out names. I'm gonna be careful throwing out names because I don't want to play favorites, but we have head— heads of engineers that are very knowledgeable in what our customers do, how they do it, what their invoicing runs are and all that stuff. So we almost have 3 layers. We have that layer in the middle, which believes wholeheartedly you— they like their golden cows in there. But we've found it's very difficult to scale, to move as we're going into containerization. It becomes more difficult because we have very deeply rooted technical architecture that is not as mobile. It might be not mobile as in moving from one place, but one structure to another we get ourselves in trouble with. So I'm not going to say I'm right, but it's a hotly debated topic. But I like to have clean compartmental structures of who owns what. I think it's philosophical. Yeah, I think it's philosophical. And I'm like, I think Leah, you said you got a rash earlier or something. The word code monkeys immediately gave me hives. Wait, wait, wait. Hold on, I'm changing the subject now. Shift gears. Because I want to talk about something that I think you're deeply knowledgeable about. And I think is part of the unlock for companies that perceive themselves to have the challenges you're talking about. And I'm using those words specifically. You talk a lot about ERP transformations. I feel like there is this notion in the world that ERP is big and hard and flawed and will never move. I actually think there are ways to think about that differently. I don't personally believe that. I think ERPs are big. I think they're critical. I think they run critical workflows for the business. I do not think they will move and/or Like, you're not going to redo your ERP. No company is going to invest in that because it doesn't actually add a lot of value to the company and it's hard and expensive. But I do think there's ways to work with the tools in really innovative ways. But you actually post a lot on LinkedIn and other places about ERP transformations being hard. Why don't you talk a little bit about that and what your philosophy is there and then how you're approaching that? Sure. So I think that— let's, let's start with defining why I see the problem, and maybe it's not consistent. So the reality is, is I don't think this is a challenge for every single industry, right? I agree with— I think in some industries that they could either be swapped in place or they'll never leave and everything's fine. But in the industries that I've served, which I call the resource-intensive, or I've personally qualified them as wealth industries, industries where they're producing or recycling raw materials into the products and services we see every day. The forest industry, natural gas and oil industries, scrap metal, waste management, anything that's dealing with these services that have a lot of moving parts, high compliancy, and are working off of margins. I'm trying to get the maximum margin out of sourcing material into a manufacturing plant get it into a product, get it out the door, and get it sold and have it tracked. So, I have every one of these challenges and problems. Those companies are complex primarily between the handoff points from one to the next. So, customer service, onboarding a customer, handing it off to logistics to be able to get a delivered container, to be able to go through dispatch, to be able to get it into billing, billing and accounting, finance goes into, and you might touch a CRM. So, there's heavily integration between your sales system and your accounting system. So, There's a lot of touching points in there. And what customer— the number one problem I see is either they adopted a product years ago because most of these industries are slow to change, right? You could go back as far as 6 years and you would see almost no tech on a garbage truck. Today, they're mobile data centers, 10 to 15 cameras all the way around it, onboard computing, sensors, lift arms. Major digital revolution. If you go back further in the paper industry, that's guy, multigenerational, my great-grandpappy built that boiler type of thing. So the challenge there is that when it is forced upon them or they need to adopt a new ERP, most of the people that lived through the first transformation aren't there or are very close to on their way out. So you've got a lot of people that have only known the system they have, which means that over a decade, more often than not, they don't know why— they know what, but they don't deeply understand why they're doing what they're doing, right? So I, I cover stories and stories of that through my book, all the way across the board, where it was a mis-breakdown. Those are the things that cause the challenge. There's no— it's not technically hard. It is people, places, and things. You're moving data around, you're storing it, pulling it back up, and doing something useful with it, and then that impacts the physical world somehow, either in an inventory, a shredder, a loader, a finished product going out the door, and then money needs to change hands. You need to tie everything up. So, technically, the problem isn't hard. It's the processes around people adopting those that's difficult. So, where do I find most of the challenge? Very few companies, when they go shopping, have something that feels like a vision of what it is they're trying to do. Why are they going for a new one? In the customer journey, I'm saying, look, you're not going to find— if you were forced or need to replace your current ERP, you're not going to find something with that same custom fit feature-to-feature tracking of what you have today. You're not going to find it. It does not exist. You didn't have it when you got that thing 15 years ago. You grew into it over those years. It evolved with you. So now you're going to a net new vendor and expecting them just to drop in And more often than not, they start going down feature checks. Why are you doing it? Pick 3 good reasons that have ROI behind it and chase those. Eat that beast a little at a time. Take advantage of your connective tissue, but by God, know what your current as-is looks like. Really. Not, I think it is this. And then you find out there's an Access database in the corner that is wholly responsible for compliance reporting. And without it, we can't go forward. And now the implementation stops hard right there. Know what you have as best as you can, or bake in some kind of a tolerance in the rollout and discovery phase to get it. Then design your to-be. Can I jump in right there? Yeah. Doesn't that then require that they do that discovery and do it deeply and make sure that they do a gap analysis of what it actually does today and what they actually want it to do? And that would be the ideal. Circumstances to have it. Because I see businesses shopping for a new ERP without having done that. They have very soft, very weak goals. And I say weak as in they don't have any strong metrics. They want to increase revenue, but they don't really have a good sense of what this system produces from a cost-value today. In other words, if I want 20% more revenue out of the thing, what am I— what's your today metric? They haven't done that work. Work. Like, to me, let me just finish this piece here. So, um, with Smurfit Stone, we did that work. We did a full process analysis. They didn't have a system, and we saw with them that it was costing about $12 and change to bring a load of round wood across the scale, and they do a million loads a day. As we went and rebuilt the process and dropped in the ERP, that dropped to about $1.40. Per load. The total system cost them about $560,000 a year. Net gains on that is over $10 million a year. For a decade, that was the easiest budget for the champions on that product to get because it was easy math. And it's because they knew this is why we're doing it. So when things came up that didn't fit well, or maybe someone had to do a little bit extra work, That was the flagship vision that kept everyone going, and it covered the cost of the system and the initiative. If you don't have those, you're going to start having a whole lot of paper cuts build up across the rollout project, and you're going to end up dragging dates because someone's not going to go because they need this tick box. I see it all the time. So anyway, I just want to make sure that that piece is out there. So Leah, if you wanted to finish your thought. Braylon, did you have— were you gonna ask something? I mean, I was, but I would, I would like to hear the rest of your comment, Leah. Yeah, I was just gonna, I was just gonna say I think, um, one of the, one of the things that often happens in my— in like, at least in my experience, is that ERP systems lock people in and are very expensive. And then often companies that go in with weak you know, requirements. Sometimes the reason their requirements are weak is because there isn't anybody who understands it anymore. There isn't anything— anybody who can dig in. And quite frankly, those companies that sell those ERP systems know they're locking you in and are basically— they've got you arm wrestled into a corner and telling you like, you'll never get out of this, so I don't know why you would try. And but meanwhile, those— a lot of those— this happened a lot during the pandemic. Where companies were locked into contracts with companies that they were like, 'I can't afford you. We're not even doing any business anymore.' And those companies were like, 'Sorry.' So, I think there's also a bit of like the inflexibility of ERP companies makes it so that businesses get locked into stuff that they want out. And so, maybe their ideas are weak, right? But they're not wrong to want out. No, no, and I'm not advocating they're wrong to want out. What I'm saying is, if you're going to make— if you've made the decision to buy a new system or move into a new system, I think whether you can turn off the subscription or not is a really wholly different debate. Whatever the reason, you bought something 15 years ago, it was built on top of Windows XP, the vendor who built that isn't doing a good job at maintaining it, you need to go to a new software. I've seen it and seen it and seen it. That is a compelling reason, but it is not nearly strong enough of a vision to get you through a rollout of an ERP unscathed. Buckle up because if you're saying the reason we're upgrading because we have to, you're in trouble. You haven't— because you haven't done the work yourself. It's a customer journey because customers need to take ownership. Now, you're right. They might not know how. So they will need help. Knowing that you need that help is a really strong first step to someone going, guys, I don't know. Like even John in there, when I walked him through the customer journey, he's like, God, I wish I knew this before I walked through this with this other company. And now I'm paying for it because you said, yeah, it doesn't work, but I locked you into a 5-year contract. That company made a conscious decision to keep that. You signed a contract, you bought it. Buyer beware. That's a— to me, that's a terrible way to do business, but it's replete everywhere. So, customers are going to have to take a little bit of onus of what can I do to protect myself as I go into it. And my point is every bit of it's avoidable with a little bit of knowledge, a little bit of upfront work, making sure you're buying for the right reason. Even if the product you're buying doesn't fit all of your features and you're burdening some department, they have 15 clicks instead of one, or maybe they've got this manual process they didn't have. The reality is they would weather the storm if you can preach the vision and give them the why we're doing this from a company standpoint. People are— From my perspective, so from my perspective, this is like a sales pitch for anyone that has an ERP that they think they need to replace is to go hire some consultants and come up with two things. One, why exactly are you making a change? Because I don't believe that in a lot of instances, you need to change your whole ERP. I actually think that's a false assumption. And I think if you really understood the business problem you're trying to solve, there's probably 100 ways to solve that problem. And replacing your Oracle or SAP or whatever is a really, really, really, really expensive way and reason to do it. And to go hire someone to map your whole system before you touch anything or sign any contract and then look at alternatives to work and then shop, right? It's like, I agree with you. The very first phase of the customer journey I put together is before you buy, do these things. And if you can't do them internally, 100%, find someone that's been in this industry long enough that can go do this for you. It will save you so much pain. That German company wrote down $650 million. At what point Do you call foul? I mean, that same company I told you, Smurfit Stone, that used my old wood procurement system later tried to replace it with the same vendor. This German company tried to replace it. $75 million later, had to write it down. Didn't get there from here. Well, why would you? Why would you even upgrade your ERP? It works. Why would you innovate on top of it? If you've done the upfront work, maybe that's an outcome. There's no reason to do anything. Do nothing should be a viable, probable outcome is there's no reason for me to do anything. But there may be a compelling reason to do it. Think about what an ERP system does. It really sort of manages, like, it manages certain aspects of company operations. And so, if you think about this from an order to cash lifecycle, there are certain events that are true and canonical regardless of what ERP system you're using. It doesn't matter. You like have salespeople. They go sell stuff. They write a sales order. Maybe you manufacture. Maybe you don't. Maybe you just do consulting or whatever. You issue an invoice. You wait for money to come in. You record accounting transactions. Like ERPs are really good at what they do. But my point is, what you just described is the trap that most companies fall in. Because even across, let's just say, even the paper industry, they all say that. We buy in raw wood chips. We cook them up. We make paper. We sell. You can describe that. We will pay the supplier for that wood. When you get down into the ground level, you find out that that supplier is working from a landowner. That landowner has a consultant. Now, the wood company is responsible for not only paying the landowner for the trees, the vertical inventory, plus the consultant fee, plus the supplier to cut it, plus the skidder loader to load it, plus the hauler to ship it. Right. And then some of the wood on that land isn't viable for pulp. Some of it's hardwood. So I'm going to— ERP system doesn't care about any of that. But what you're describing— it has to manage that somewhere. It has to be tracked and it has to be accounted for. So it still has to be collected. It still has to be documented and processed through. I realize— maybe— no, not maybe. Why do you have to refit your entire ERP system? Why can't you innovate on top of a system Why are you adding that complexity into what should be a relatively simple backbone? Maryla, I'm not arguing with you. You might be. You kind of are. But let's do it. No, no, no. I'm saying— No, no, no. So, here's the part I am arguing about. It always sounds simple as you describe the big steps. The devils are in the details of how you operate. 100%. Do you have to replace everything? No. Exactly. But how do you know that until you've done the work? Exactly. Exactly. All right. We arrived at the same place. We're actually saying the same thing is that you have to have an as-is, define your to-be, and then you build your journey. This is where our editor is going to put in confetti. Yay! Because I think most people start at the to-be and try to work backwards. And that's the problem. Got it. Got it. Got it. Got it. All right. All right. I'm going to move us to the lightning round. It's time. The time has come. First question, what is the— this can— what is the longest implementation you've ever been through in terms of months? And what is the shortest implementation you've ever been through in terms of months? The shortest, the shortest has been less than a month. All in, beautiful. The longest never ended. Like it's still going. As far as I know, I'm not there, but it's still true. So it's 20+ years of making that thing. Yeah. Marilyn, what about you? Oh, fortunately, everything I've worked on has ended. I think maybe because eventually something's got to freaking end and you've got to reprioritize things. Shortest is days from customer concept and idea to product managers working with tools that sort of like produce working prototypes, and then a day to implement. So, like, very short iteration cycles is, I would say, probably a week and a half. Days is— I mean, that is days. The longest, unfortunately, probably took— it was probably one that you and I worked on together, my friend— that took a year and a half. And it was because we kept moving the goalposts. And not you and I, but the goalposts kept getting moved on us. So the definition, the definition was poorly defined, and it turned into a horrible death march. I actually would say mine were— the one you just described was the longest, but in the same exact group team structure, the— when we did the— when we built the business, uh, the Amazon Business stuff, that was the fastest. Justice. Awesome. Because we didn't use any of the Oracle backends that we had already. We said, nah, fuck that, and we built it ourselves. I built the architecture, the engineers built it. We got it up and running faster than anything. And it still went into the accounting system. So that's what I mean by like working with an ERP system rather than like redo the whole thing. Yeah. Okay. Second and last lightning round question. Whose books, in terms of business or, you know, this kind of tech, whatever, do you always read? Like, if they write a book, you read the book. Oh God. So I'm— am I going first? All right. So I like things that aren't that specific. I like things that you can govern your life with. So, um, I'm gonna I'm going to tell you this. I don't like the guy, but I like his messaging and his writing. And it's Grant Cordone. So, I think the guy's harsh in the world. But the single principle that he put out, if you've read his book 10X, and his thinking is this. And you guys sound like not only are you product managers and you're technical, you're also implementation guys. So, that's great. Is if you were to build a plan to generate $100, most people get about 60%. So, if you were to try to— all you do is change the plan. I want to now get $1,000. I still need $100, but I'm going to get $1,000. Your plan changes. You would create a fundamentally different plan to achieve $1,000 than $100. You still don't get $1,000. You might likely get $600 of that bucks, statistically speaking, but you're now 6x your original goal. And that's why it's called 10x. And I have found that to be useful across the board. Yeah, not really to 10x every single thing, but to just relook at the plan as an overshoot plan. What would I change differently to achieve the goal? And I'm— I found since I've read that book, I'm hitting my goals far more consistently since I've just made that tweak. Now, it's more nuanced than that, but that's, that's the gist of it in case you don't want to read the book. I mean, you know, you know my greatest hits, Leah. So like BJ Fogg, BJ Fogg put something out in there. I will tell you that Nir Eyal just wrote a new book that's on pre-order called Belief. Um, and I've started looking at a lot of his pre-read material, so some of his, like, um, the handbooks and stuff that come with the pre-order. This is not a sales thing, I do not get an affiliate link, but a lot of his thinking really aligns to that human behavior design. And I am super jazzed about this book, and I will be bringing it up in a future podcast. Um, we'll talk about it. How about you? Yeah, it's a good question. I mean, I think you got me onto BJ Fogg. So I'm a little bit on a reread of his work now. So that's something. But I mean, in terms of maybe it's not really as businessy, but in terms of how I think about leadership and how I show up, certainly I read everything Brené Brown writes. Oh yeah, she's awesome. She's terrifying. But yeah, she's terrifying and awesome all at the same time. Time. So yeah, awesome, which I love. Okay, well, we've reached the end of our, of our chat. Evan, thanks for joining us. We really appreciate it. Yeah, it was great. Um, we will see everyone on the next episode. Talk to you. Bye. Bye.