In this episode of Solving Problems with Technology, host Xalt Solutions’ Robyn Aaserude, with guests from Corbins Electric and Nox Innovation, discuss best practises to take and mistakes to avoid when designing solutions for your business.
RA: Hello and thank you for tuning in to this episode of Solving Problems with Technology on HxGN Radio. I’m your host, Robyn Aaserude. Today we’re going to be talking about yet another key component within digital transformation, which is solution design. In this episode, I am speaking with JD Martin. JD’s VP and partner at Corbins Electric down in Phoenix, Arizona. We also have Nate Unruh, who is the business solutions manager at NOX Innovations, also down in Phoenix. And Geoff Wakefield, our continuous improvement expert here at Hexagon Xalt Solutions. With that, welcome back to the show. Thanks for joining us.
All: Yeah. Thanks for having us, Robyn. Good to see you again.
RA: Yeah. Quick recap for our listeners. In episode one, we discussed the importance of digital transformation. That’s what’s setting the stage for the rest of this. We compared digitising versus digitalising versus digital transformation. We talked about how the people within your own organisation actually responded to that, that message and the changes that that brought about. Great episode. Episode two, we discovered the importance of gathering requirements. You know, what we learnt with that process, who collects the data, who is involved with those steps, pitfalls to avoid. Make sure to cheque out that episode. And today, we’re spending more time within the digital transformation topic, specifically, as mentioned, solution design.
So, with that, let’s get started. I’d like to begin with defining what is solution design. Nate, I’ll start with you. What is your definition as it pertains to somebody on their journey of digital transformation? What is it, and maybe why is it important?
NU: Yeah, so solution design especially for an individual or a company going through digital transformation is particularly identifying and actually building the solution that you’re going to present to your customers, right? And a lot of times your customers are internal, but they can also be external depending on what you’re using this application for. But it’s really solving the stakeholders’ problems with the solution that you are creating and making sure that and the design process of ensuring that all the requirements are satisfied really kind of takes up all the efforts that go into a solution design.
RA: That’s perfect. You know, we do designs internally here, we’re constantly growing, so you have your requirements, how are you going to go about documenting and designing this solution? What’s the next steps here? What are some best practises to follow?
NU: Yeah, I’m actually going to let JD kind of take the position of what we used to do, going from an ask and our minimal requirements, gathering into a solution design. And I’ll talk about kind of what current state looks like.
JDM: Yeah, I think we’ve experienced this at Corbins. We kind of talked about this in the last episode too about gathering requirements, like how we used to do that. It was kind of loosey goosey. We would like use napkin sketches or like, you know, rough diagrams on dry erase boards and just like throwing ideas on there, going, yeah, I kind of want this to look like this and like that. But really the design solution is really talking about what the user experience is going to be like. How do we want to—I guess let me put it this way. When we first started out building mobile workflows or digital workflows, what we thought we were doing is solving a process problem within our own organisation, as in like, oh, yeah, this information needs to go from this person to this department. Then it goes on to the next one and they do something with it, and it ends up somewhere.
What we realised is that’s like the easy part. The hard part was defining the human behaviours, like how you want humans to interact with that thing, because they’re ultimately the ones responsible for putting in information, submitting it. So, when we go into solution design, we’re looking at, okay, well, so does all of this information need to be filled out before it goes to the next part? Are we going to give them an error message? Are we validating it against other real information? Are we going to give them a drop down? Are we going to let them type it in? I mean, all of these things are decisions that we have to make in order to make the user experience well enough that they use the workflow. We’ve identified a need. We think this will be valuable to our business. Now we have to make the user experience appropriate and nice, right?
So anyway, those are the kind of things that we think about as we are designing the solutions. I mean, obviously, there’s the data itself. Where is it going to live? How do we move it from one person or department to another? But I like to focus a lot on the user experience.
NU: Yeah, I think that’s you know, it’s really taken that user experience and comparing that to the requirements and saying, hey, what’s the best way we can solve all of these? Right. I guess one of the biggest pitfalls of solution design is when you’re having that handover of requirements to solution design, depending on how that happens, right, whether it’s the same individual gathering requirements and designing the solution or if it’s two separate entities doing those different jobs, a lot of times you’ll see that transfer of requirements to solution design, that’s really where things fall apart because the end goal, right, a lot of times you come out and you have this awesome solution that you really believe in, and if you go back to the original requirements, you only checked about half of them, right? It’s really easy to get carried away in some really cool solution, right, implementing a new technology or anything like that. But if the focus during solution design is not particularly on, hey, what are we actually trying to solve? And if that sometimes, it’s a really simple solution and, you know, as a solution designer, it might not always be the most fun, exciting thing in the world. But at the end of the day, the success of the solution is based off of the how well you solved the requirements at the end of the day. And so, when you come in with a heavy-handed approach of, I know what I want to do, this is what I want to do, and you’re not constantly referencing that back and forth, you will end up with a product that’s not very successful.
And as JD mentioned with the user experience, there’s a lot of different ways, and especially when we first started, we were looking at paper processes and we were trying to mimic those in terms of kind of just digitising a paper form. And the nice thing about a technical solution design and when you’re digitising and having that digital transformation is you have the opportunity to really mould those behaviours with your user experience. You can implement instead of just implementing hard cheques, you can do that through the UI design. You can understand how the users are going to interact with your application and keep them in mind, because whether I’m designing this for somebody out in the field or somebody that’s really technical and is really going to be able to figure things out, I might give them a little more permissions and flexibility, that kind of goes into that as well. We talked about the kind of, you know, designing with stakeholders in mind on the requirements side quite a bit. But again, it really folds into that solution design.
So just to summarise user experience and keeping close to that, those requirements that you gathered in the last section are honestly the biggest pitfalls that we’ve seen when we don’t focus on those two factors.
RA: This is—
JDM: Sorry, Robyn.
This is also one of those things where, like, the more you do with it, the more experience you have in exposure of going through different types of solutions for different scenarios for different groups of people. It helps you anticipate needs later on for other customers, for other scenarios, because you’ve seen this before.
So, I’m a pretty typical customer and Nate’s my workflow developer. And I go, yeah, here’s what I want. Right. And maybe at first Nate in the solution scene would be like okay, we’ll give you what you want. Now, we’re at a point because we’ve been doing this for five, six years, what Nate and his team were able to do is go, hey, that’s a good idea. And have you considered doing X, Y, Z? Because they’ve seen it done, right. They’ve helped other customers do that thing. And so that’s really where the value add comes in on like NOX Innovation, Nate’s group. And I know like a lot of what Geoff Wakefield does with his customers is like, hey, guys, here’s something. Have you considered this? And they go, oh, no, I haven’t considered that. And, you know, ends up making that that process or that thing better.
NU: Yeah. Yeah. And those opportunities, it’s what really pushes that experience and solution to the next level. A lot of times if we’re just looking at the process and saying, okay, as long as we cheque all the boxes were good, but, you know, looking at it as a full workflow and how we can connect it to other applications or other solutions. But again, the second you start going down that route, you always have to have that kind of voice in the back of your head saying, hey, is this really solving the problem that I’m trying to solve? Because the second you start getting outside and getting into that creative box, it is easier to kind of go off on a tangent and lose that core design. But it is also where that value add can come into play and really show a lot of value. So, it’s kind of a win-lose situation. You just have to make sure that the focus is still direct.
RA: Excellent. You know, more of a I guess where this leads my mind to is more of a tactical question, which is, you know, solution design structure, what does it look like, what are its attributes, what works well for you in terms of screen mockups or table structure? And I guess I would blend that into some technology that you’ve used to support your solution design effort. So, if you could expand maybe, Nate, a little bit with your team and what you guys have been successful, maybe some technologies that you use, I think that would be helpful to learn.
NU: Sure. Yeah. There’s a lot of a lot of different approaches that you can take. And a lot of times we kind of balance them based on the customer and the project that we’re using. Obviously, the first thing you take in consideration is the technology that you’re using. If it’s a kind of if it’s already existing application, you have a lot of those considerations of you’re just adding a feature, or if you’re completely focusing on a new complete solution, you have a little more flexibility, but you also have to consider the solution and technology that you’re using to accomplish that.
So going into that and looking at how we approach that again, it kind of depends on our customer and how our requirements gathering went. If we have the exact, we’re really confident and we understand the workflow, we understand those requirements, we can really produce a solution fairly quickly and get down to the end of the road. However, a lot of times when we’re in that requirements gathering, we get to a point where we say, hey, we understand the project, we understand what’s going on, but it’s hard for both teams to kind of visualise the end product because there’s a lot of question marks, whether it’s a new process that hasn’t been implemented either on paper or another solution before, or you run into the issue of, hey, honestly, we don’t know what we want that to look like, give us your best shot. And so, a lot of times when you get in those grey area scenarios, that’s where that prototyping really comes in and works really well in the solution design. You get down a path, you give them a minimal viable product, and you go and meet with those stakeholders again. They give you feedback, meet with the stakeholders again, prototype that out. And Robyn, as you mentioned, when you really are struggling to get on the same page with the stakeholder, what they want, that’s usually where we come in with, without even looking at the technology, coming in with kind of screen grabs or wireframes or other things, other mockups like that which come before a prototype in terms of, hey, let’s make sure we’re on the right track.
Now again, when those are necessary, really have the balance the scale of the project. If you’re looking at a two-week project, doesn’t really make sense to, you know, spend a couple of days on a wireframe or spend three or four days on a prototype. If you can build the whole thing in a week, you might as well just go the prototype route, build the thing in a week, come back, and go back and forth and see what’s going on.
So those are the considerations, if it’s a longer project then, absolutely, you want to make sure that, hey, if it’s going to take three or four months to design this solution, absolutely have to make sure we’re checking in continuously and having some steps, whether that’s minimum viable product steps or it’s wireframes and design, right database designs, whatever that looks like along the way to make sure that we’re on the right track. So, it’s kind of a combination of those, depending on the scale and the complexity of the project or the solution that you’re designing.
RA: Geoff, within our customer base and some of the projects that you’ve been a part of, what tools have you found useful to aid in what Nate was describing? Are you an X, Y, Z user? What have you found that is simple, effective, efficient, whether it’s a short project, long project? Is there something that you found that helps you as an engineer, as somebody that puts together a problem for somebody? What tools do you have in your tool belt?
GW: So, my go to tool for any solution design work is a process mapping software. So, whether that’s Visio or Jio or any numerous one, I feel like when we’re talking process, mapping it out, both the current state, which we’re hopefully capturing it in our requirements gathering, and then future state, that really helps clarify what we’re trying to do and gives us a good roadmap of what the technology we use for the solution needs to accomplish. So that process map really gets all the questions answered. We can see where things are going. And usually when you put something like that down in kind of a logical sequence, people will have comments or feedback on that and say, yeah, I don’t really want it to do that. Or what about when it gets here? Shouldn’t we have this type of loop? Some additional feedback. And I think it helps frame how we’re making the solution.
But it also could hurt because sometimes a trap I’ve fallen into and I’m sure others have as well, is instead of designing the solution around what’s the best way to do a process, we get stuck in designing it around the technology we want to utilise for that solution. And it kind of like limits our thinking to a certain mindset. So instead of giving an optimal solution design, we end up giving, you know, a solution designed around a particular tool or technology. So, I think that’s where some of that balance of having a good process map in that solution design, really understanding it, seeing how it’s bringing value, and then translating that into the technology that’s going to be used to solve that problem.
RA: Yeah. Thank you.
JD, you know, early on, I’m sure there’s been multiple iterations, but early on, how did you avoid the temptation to take a massive problem, right, because we want to remain within the scope. And I know that along the way, you guys will obviously continue to grow from failures and trials and things like that. But narrowing down the scope of the problem to solve, that’s actually in the solution design, how do you guys go about that? What are some things that you’ve learnt to avoid scope creep and extending the bookends of the problem you’re trying to solve?
JDM: Yeah, good question. I think for us, some of the best—well, first, I want to say that our team is really good about coming prepared now. I mean, we’ve learnt a lot in these last six years since we’ve been using Xalt as a platform, for example, for our workflow solutions. Because at first, we didn’t know what we were asking of ourselves. Like we said, here’s an idea. Let’s go with that. Yeah, inevitably, we’d have scope creep, figure, oh, you know what else would be cool? as we’re in the middle of the project. Oh, you know it’d be cool if we did this other thing, too. Well, you know, that would fundamentally change the entire design and we would have done it differently from the beginning. But we’ve learnt a lot. We had to exercise discipline in slowing down at first and really, really hammering through the details of the requirements gathering process, vetting out the process of does this already exist on paper? How successful is it? Are we getting what we want? before we try to digitalise it, right? And we by going slow, it allows us to actually go relatively fast on the actual building of the process on a platform, because we’ve already vetted out. And I’m talking we like hammer down and run it through the gantlet and beat up the process and go okay, why do we do that? Why do we do that? And if the answer is, oh, because we’ve always done it that way, we scrap that and start over. There must be a reason why, because if you don’t and you build the process and you roll it out, that’s when you are inevitably going to find, and you don’t want, but you’ll inevitably find the oh, yeah, actually, there is a special process that we didn’t account for that actually blows this whole thing up. And then you have rework and you have scrap and it’s just not very lean, and being lean is something, just like in manufacturing and construction, we care a lot about, right? We hate wasted effort, wasted labour, wasted resources. Our backlog of projects is so long, we absolutely must avoid rework.
NU: Yeah. And kind of going off combining those two points, you know, Geoff was talking about how using the process map and JD was talking about really getting down in the weeds of looking at that, one of the recent tactics that we really used is, as Geoff said, starting with the current state. But implementing a lot of the solution design on the process map side should not just include what happens in the solution. It should also include anything that happens outside of that. Right. A lot of times your technology solution or whatever you’re doing is not going to cover the entire workflow. There’s going to be somebody calling somebody in between there. There’s going to be, right, a truck that’s delivering some material out to the job site. And a lot of times when you include that in those process maps, even the stakeholders find new ideas that it almost becomes a sense, a type of prototyping where we say, okay, let’s take that current process. Let’s put in the idea of the technology solution but keeping all the external stuff that happens outside of that in place, because a lot of times we’re finding new decision trees that will have to happen. Oh, yeah, but what if it comes from this specific geographical location? Well, that kind of changes up the whole style that we’re looking at.
And like JD said, a lot of this focus when you’re looking at both solution design and requirements gathering is eliminating that rework. And that’s a lot of times where we’ve seen we roll that out and all of a sudden there’s a whole new decision tree, and if we had just put in hey, right, the tool or material comes from a different geographical location, and it’s even had that in there.
JDM: Let’s use a real example—
NU: Sure.
JDM: —I think of how we successfully implemented this. And that was when you guys helped us with our customer relationship manager. We built our own on Xalt’s platform what we thought would be cool. This is an example of how we avoided scope creep, guys. What we said you know what we need? We need a faster way for people, for our project managers and on small projects to be able to get a project number. It’s a very manual process in our construction accounting software. A human being has to go in and put a bunch of required information in, in order to produce a project number, which we then use. We have to have that in order to be able to issue POs, rent equipment against it, and all those things. Right. So, we said, yes, we need that thing. Okay. Then we took that little part. What could easily have been a scope, people said, oh, yeah. And as we’re building it, we go, okay, then it’ll bleed into accounting and then purchasing and to all of these other departments. And instead, we during the requirements gathering and design part of it, we go, okay, let’s compartmentalise this. Okay, so we need this part which is getting project numbers relatively quickly. Okay, what do we need to do in order to do that? Well, we need to actually have a database of customers with some of their information already gathered so that it’s an easy transition. We already have that information. We don’t have to request the project managers to type it in all at once. Okay, what do we need in order to do that? Oh, we need to be able to create opportunities tied to locations and projects and general contractors. And basically, we’re connecting all these dots that ended up being our customer relationship manager in order to get to a thing which was ‘let’s produce projects out of our accounting software spectrum really fast’. And then that actually transitioned a little bit further down the line. We’re able to create once a project is created, what we said was, you know what would be cool? A scope creep. Right. You know what would be cool is if the different department leaders also were notified when a new project started so they knew how to support those, you know, payroll, talent, purchasing, the tools department, shipping and receiving, all these things that it’s helpful for them to know when projects start and not when material or people or things start showing up. So, we said, okay, let’s talk about that. And then we defined, we built a box around that and said let’s define that and see how it can incorporate into this entire flow.
So that’s an example of how we could easily start out with one little thing without really running it through the gantlet. Let that scope creep go on continuously. Instead, we broke it down into bite size chunks and compartmentalising okay, which one do we need to start first? Do we need to start at the very beginning, or can we actually start in the middle and then build on both ends or do we start from the back and work forwards? It’s all of these decisions that we got there. We ended up—what did we do, Nate? We started in the middle and kind of built out, right?
NU: Yeah. And it’s a really good example of when you’re talking about solution design and you’re looking at a huge solution like that, you’re like, this is so overwhelming, right, it’s going to take six months to be able to finish this and deliver all of the functionality. This is where in the solution design step you really want to take a step back, look at your requirements in the workflow and say, okay, is there something that we could produce that solves part of the problem in either the most impactful part of the problem or the core kind of functionality part that will eventually lead into the rest of the solution, and can we get that released and then start releasing other things in phases? And a lot of times the answer is yes. There is even that, you know, minimal viable product that MVP that you deliver to the customer as a prototype, what we found a lot of times is we can get that to a point where we can actually get that launching, get some data rolling through so we can then, when we’re pivoting to the other sections, right, and this is where you have to be careful because you can still run into a lot of rework if you don’t understand the other sections. But like JD was saying, in terms of the notifications for when a job is created and who all that will go to and what the parameters are and other things like that, we actually didn’t need to go gather all those requirements to understand that because we knew what the core functionality and that wouldn’t affect our generic design. So that was one thing where we said, hey, we can push that to phase two of the project. And for phase one, let’s work on those core functionality pieces where we can get users in here, start data collecting, and then eventually we can add on those kind of extra bells and whistles that, you know, will really make the solution shine.
JDM: So, there’s a friend of ours in the industry, another contractor that we know, they instead of biting it off in bite size chunks like we did, like they helped us do, they went and bought Microsoft Dynamics, which is a great product. I’m not dogging the product. But what they did is they tried to map and workflow their entire organisation or as much as they could basically from call to cash, right. From your first opportunity to do a project till when you do the final billing. And they’re there, you know, they’re three, three and a half years into this process, because they can’t turn over anything until it’s completely done. They’re three and a half years in this project and it’s not fully baked out. And they spent a couple of million dollars on it already. So, that’s an example of like, hey, that elephant, you’re not going be able to eat that thing in one bite, right?
RA: Yeah. You’ve got to get the reps in. You have to take it in bite sized chunks. You have to learn from your mistakes and your failures. You have to be able to be willing to question at the beginning, middle, and end of a project the gauge levels of success. And I think it’s important for our listeners to know what have, maybe even internally, Geoff, what have we learnt from a bad solution design? So, I’d like to hear from Geoff, but I’d also like to hear from Nate or JD. Have you guys ever just totally abandoned a solution design for various reasons? So maybe starting with you, Geoff, let’s talk a little bit about some of our failures, so to speak, or bad solution design, because we’ve got to learn from it.
GW: Absolutely. You know, learn from our mistakes and don’t make them again. And in my time making solution designs, a couple of mistakes or a couple of failures that I’ve learnt from, one has been trying too hard to frame the solution design around the technology. It was a point I made earlier. So being too focused on what a technology platform can and can’t do and kind of missed the point of solving the problem. You know, another one is kind of the point that Nate and JD just made. Scoping is so big that it’s going to fail just because it’s too big to tackle and not making it into those bite size chunks. But probably the biggest one is not listening to those requirements and really those pain points and just inferring and making too many assumptions on what’s going to bring value. Because if we’re not solving the problem in a way that’s bringing value, if it doesn’t have a business case to go after solving it, then we’re going to waste a lot of time, effort, and energy on nothing. Right. And we could be doing revenue generating work or actually solving a problem. So, making sure that we actually listen and be open to addressing all of the problems, all the pain points, and using those as like criteria for success in our solution design and saying, am I covering this problem? Am I covering that pain point? Instead of just saying, hey, this is really cool, I’m just going to copy and tell you something that someone else had as a problem and a solution and put that out there. And so, those are kind of the three ones that I’ve seen. Nate and JD, I’m definitely curious of some of the things you guys learnt as well.
NU: Yeah, I mean, I think you hit it right on the head. You know, in terms of those top three, I mean, that’s really what we’ve seen as well. I think one of the biggest solution design issues that we’ve had, and I mentioned this a bit in the requirements, is as much as you try to understand the process and really think you believe in it, you can do process maps and all of that, but if you aren’t, I mean, outside of really embedding yourself in that process, you’re still making some assumptions. Right? And it’s always about what assumptions you’re making and when that becomes an issue. And when we’ve seen our solutions fail the most, it’s when we decided, hey, we made a big assumption, and we didn’t go back and cheque that with the stakeholders or against the requirements. So that could be anything from assuming somebody’s role out in the field, assuming somebody’s role in the office, understanding what somebody means by a certain acronym or by a certain action, or we didn’t dive into when someone says, hey, I approve this, what does that actually mean? So, some generic requirement that we make a lot of assumptions on. And it stinks, right, when that goes out and it or you show it to a stakeholder and you’re like, wow, this isn’t it. And while we haven’t actually experienced too much of that recently, a big part of that is, again, we’re a lot closer to the business and understand more of what that is. And so, expertise can definitely save you from a disaster, but it will never save you from those kind of slight misses and not having the perfect solution design is by jumping on those assumptions and not taking that 5, 10 minutes to go validate that with the user and say, hey, when you’re actually delivering this out in the field, is that the truck individual that is doing it or are there multiple people that are passing it back and forth? Oh, yeah. I mean, it shakes hands like five times. Oh, well, that’s a huge tip. Now we have three or four different people touching it. We can’t just end the process when it gets dropped off at the field. So, there’s a lot of different, again, you have to really toe the line there and say what is too detailed and what is too specific, and you’ll always be making some sort of assumptions. But validating those big leaps of faith that you’re trying to take is always the best way to protect yourself from those failures that we’ve seen in the past.
JDM: Yeah, I would say that we haven’t really abandoned anything at Corbins Electric in our workflows because, I mean, all the things we’re building are pretty important. But I can say for sure, because of lack of good gathering requirements and good initial solution design is we have certainly spent a lot of time on rework, redoing things, to Nate’s point, because we made assumptions or didn’t have all the stakeholders in the room. You know, you then end up having to go back and rebuild things. But we’re actually pretty good about things don’t make our list, our project list, for things to be built in Xalt unless it’s going to be pretty impactful to our business. So, yeah. We’ve learnt. We’ve still got a lot better. We’ve gotten a lot better on our rework because we’re being a lot more disciplined on the front end.
RA: Yeah, I appreciate the transparency there. And I think this is how people learn. You have to be able to share real world stories, be in a discipline and mindset that you want to grow, and use and leverage those experiences, in your case. We really appreciate the ability to share that with other people.
I want to round out the story today for the conversation. JD, I’d like to start with you. If there were some things that you know now about solution design that you wish you knew, are there things that you wish you knew when you very first got started? What’s a good nugget of wisdom here as far as experience learning, dirt under the nails, on this topic?
JDM: Yeah, like with a lot of things, when I get asked questions like, hey, what would you do different now that you know this? My answer is usually the same, which is like find somebody who’s doing it better than you and freaking copy them or at least learn from them, pick their brain, spend some time, go visit. People are willing to share information. That’s what I’ve seen. We’ve been able to do that. We’ve done that at Corbin Electric. I mean, we have contractors, electrical, mechanical, it doesn’t matter, like come and visit us to pick our brains about lots of things, mobile solutions included. But I would say probably in this thing is what I wish I knew then that I know now is it’s okay to fail. Just learn from your—learn from it. Right? It also helps if you have people smarter than you helping. That’s where I tap Nate to come help me. But, yeah.
RA: Well, we really appreciate the time today. And just for the audience, where can people learn more about you, JD, and Corbins Electric, and Nate, more about NOX Innovations?
JDM: Yeah, Corbins Electric, go look us up. Our website, we actually just launched a new redesigned website. It’s pretty cool. We’re pretty proud of what we do here. We’re one of the largest electrical contractors in the Southwest and we’re doing some pretty cool stuff. And we got great people, great culture, and we really live by our purpose statement. We are empowered thought leaders boldly changing the construction industry. And we believe that, and we’re trying to live that every single day. But, yeah, go cheque us out. You can look me up on LinkedIn and some other stuff, too, But, yeah.
RA: And Nate, NOX Innovations. Where can folks find out more information about what NOX offers?
NU: Yeah, absolutely. So noxinnovations.com, great place to start, kind of goes over the different offerings that we do. Again, the efforts of our team is just one small part of that. Again, it’s pretty aligned with kind of Corbins, but really just changing the industry for the better. And as JD mentioned, that includes teaching, that includes a whole lot of learning as well.
RA: Well, a big thank you to the guests today, JD Martin, Nate Unruh, and Geoff Wakefield. I appreciate the attention to detail on the topic.
Be sure to check out all the latest podcasts from across Hexagon at hxgnspotlight.com or on SoundCloud and Spotify. Thanks for tuning in.
