The Built Right Mindset with Brandon Powell

0:00Season three of the Built Right Podcast is right around the corner, but we've got one big change coming your way. The Built Right Podcast is now the Talking AI Podcast, and we've got a lot to talk about in AI. In the Talking AI Podcast, we'll be having in-depth conversations with both AI experts and early adopters of AI. That way you can understand how the technology works and how early adopters are beginning to implement and, more importantly, get value from AI. Our guests range from AI research scientists to founders of AI products to industry leaders putting AI to work in their business. While you're waiting for season three, go ahead and subscribe on your favorite podcast platform so you don't miss an episode.

0:41And make sure to leave us a comment about the AI topics that you want to hear about. So get ready to talk some AI in the new Talking AI Podcast, coming your way August 6th.

0:58Welcome to Built Right, a podcast by Hatchworks where we help you learn to build the right digital product the right way. In each episode, we'll deconstruct the layers of successful product development, break down popular trends, and offer real advice to help make sure your product is built right. We may not have all the answers, but we've built a lot of digital products across a lot of industries, and we've seen a thing or two. Let's get into it.

1:33All right, today I am excited to be joined by Hatchworks very own founder and CEO, Brandon Powell. He's got 25 years of experience leading product and digital transformation initiatives across organizations like Accenture, Slalom, Amdocs, AT &T, Cricut, to name a few before starting Hatchworks to help organizations build the right digital product the right way. And that's exactly what we're going to get in today, Brandon, is the built right mindset and why you need it to build products your business and your users will love, aka those that create value. But welcome to the show, Brandon. Thank you.

2:11The 25 years makes me feel very seasoned at this. So thank you. Yeah, there you go. Season's a good word, a good way to put it. We'll stick with that. I feel like I'm getting some seasoning in my hair with some gray hair as the years go on too. But yeah, so let's just start off. This is our first episode of Built Right. In the, you know, thinking in that Built Right mindset, who's it for? Tell us who should be listening to this podcast. Well, really, you know, in today's world, I think it It really touches a couple of key users and stakeholders. And that's obviously any product leader, technology leader, or even a business leader who's building a digital solution, whether it's, you know, it could be a brand new solution that doesn't exist.

2:51It's on the back of a napkin and it automates things for your business, or it could be modernizing existing business. We're seeing a lot of customers, you know, take a 25, 30 year old system and make it new again. So it could be any of those. And now in this kind of digital world, you know, we're seeing our main customer, what used to be almost always a technology leader, then became a product leader. And now it's really creeped over into the business side. Yeah. And you think about it, too. We're at like that 10-year anniversary of Marc Andreessen saying software is eating the world, which was kind of a hot take then.

3:26But now software is basically eating the world, cleaned their plate, and, you know, finished there. And McKinsey, I think, just did a study recently saying that 70 % of top economic performers are using their own software to differentiate from the competition. So that's compared to just half of their peers. But it's just no longer enough to build something, take something off the shelf, bolt it on. Digital and your digital solutions have got to be actually part of your strategy as a business today. Yeah. And I mean, I was reading that report as well and a couple others where it's, you know, it's software is the world.

4:00It's no longer kind of gaining ground. It is the world. If your business doesn't have some software component to it, whether you're in manufacturing or regardless of your industry, digital and software specifically has become a key part of businesses. Yep. And as we get into this built right mindset, so there's two things that keep our customers, our users up at night. And it's, am I building the right thing? And am I building it the right way? And the first part of the built right mindset is building the right thing. So take us through this. There's three components of this valuable, viable, and feasible.

4:38Take us through that first component of built right, Brandon. Well, I mean, in my career, obviously over 20 years, I've seen this as probably the key problem. I mean, yes, I've seen my fair share of not building things wrongly, but in terms of building the right product, you can build a beautiful product, but no one wants to use it. And one of the biggest things that I think is around is the product valuable. So when you look at valuable, is it valuable to the user? And when I think about my own problems, is it a problem big enough that I would use your product to solve that problem? It's easy to identify.

5:16We all have problems that we want to solve. But is that problem big enough that if it were solved with the software product or solution, is it going to be valuable enough for me, the user, that I'm going to use the product to solve the problem? So that's valuable. And when we look at viable, viable is a little bit harder because viable is all about your business. Is the product viable for your business? Many times as a software solutions company, we come in and the client tells us this is why this product needs to be built and this is what it's going to do for us. But at the end of the day, we're product experts.

5:54We know how to build it right. And they know their business. And so we're typically going through them and helping them make sure they understand, like, is your current business model going to be viable when you have this product that's now part of it? A few years ago, we had a health care client that had us spend, we spent a lot of time and they spent a lot of money building a product that at the time was valuable for the market. But within 12 to 18 months, it was no longer viable. So they didn't look further down the line was the product viable, not only now, but is it going to be in the coming months?

6:29And then we have to look feasible. And feasible, at the end of the day, does it have the right components to it? Is it feasible that it can actually be developed by the engineering team? I've been lucky to have some really strong technologists, engineers throughout my career that pretty much anything we could come up with on the product strategy side and design side was feasible. but that's not always the case. And making sure that you've got the product is feasible enough that can actually be built. And where I see this a lot of times is we do a lot of work in fintech and they might look and they want 10 different integrations to all these.

7:07And yeah, it can be done, but is it feasible to within, just to validate a product and get it to market to integrate with all 10 of those providers and spend a lot of time and a lot of money doing that without first seeing if the product is going to be actually valuable to the company. Quick break in the pod. If you're listening to this podcast, chances are you've been thinking about how to actually use AI inside your business. And that's exactly why we built the AI Opportunity Finder. It's a free tool that helps you uncover high impact, tailored AI use cases based on your business, your goals, your pain points, and your industry.

7:43No fluff, no generic use cases, just real ideas that fit your business. and they're ranked by ROI potential. It takes about three minutes to run and it's like having your own personal AI strategist for free. If you want to try it for free, check out the link in the show notes or go to hatchworks.com backslash AI-opportunity-finder. So feasibility at the end of the day is one that you really have to figure out upfront versus getting down the line. You know, you're well into the project realizing this actually is not feasible from an engineering perspective. Yeah, that's where some prototyping and some different techniques come into play to really be able to get under that in a cost-effective manner.

8:22But you mentioned like the healthcare solution that changes in regulation completely flipped their whole business model. And you think about valuable to the user as well, that definition changes. Like you look at when the pandemic hit, how people valued solutions and how solutions solve problems completely changed. Like I know we're a big proponent of the tool Miro. It became foundational to how we work because everybody was remote. And you look at our business at Hatchworks, our nearshore business became hyper valuable with the fact that you no longer needed to be in the same location, but you needed to be aligned by time zone.

9:02So that's critical that you're always keeping a pulse on how your users view valuable in terms of the solutions and problems they want solved. Yeah. And I think valuable is one where, I mean, I hate to use like even an old example, like a blockbuster, right? Where, you know, you can be really valuable to your point for a long period of time. And then all of a sudden a Netflix comes along and you're not valuable anymore because they solved the problem differently and better and made it a better user experience that was better for you. and really it was a better business strategy that was more viable.

9:40I think on the valuable thing, to your point, especially with COVID, what a shift in market. I don't know the exact numbers, but if you ask who's purchased their groceries online and then gone and picked it up, if you ask someone pre-COVID and looked at the data post-COVID, you had grocery stores and all kinds of retail scrambling to if they didn't have a good e-commerce experience or if they had kind of an all right one, it quickly got broken. It quickly got exposed in that. And now that's become a common thing. You see parking places now outside of Target and outside of any of your major retailers that are for online shopping pickup besides getting it shipped to your door.

10:22So I just think that's a great example, like you said, that one little thing can change how valuable a product is or is not to a customer. Yeah, it's funny you mentioned that. So we've got our quarterly planning coming up this week. My wife's out of town for work and my parents are coming in to kind of help with the kids. And they were just texting back and forth, like what food can we get in here for you? We're on Instacart getting it ordered, like such a valuable thing. You don't have to spend the time in the grocery store. You can use technology to do that for you. So that's a, that's a great example.

10:53Uh, and there's the team component to this too, right? You talk about valuable, viable, feasible. Uh, there's this concept of the product trio and a lot of this, you know, Marty Kagan's kind of the disciple on this, these, these three components and product trio, Teresa Torres is a really good resource as well. But these three components of the product manager, the designer, and the technology expert, the solution architect, talk us through these critical roles and why it's important that they're working together. Yeah, Matt. So for us, and I, it's some clients I see this and some clients that don't, but we believe that you've really got to have this three-legged stool going in, right?

11:31So you have your product owner, your product strategist. They're providing the direction on the strategy. What are the priorities? They're critical to the roadmap. Like what's most important that we should be putting in the first version of the MVR or the MVP first. Then you have the product designer. They're providing the insight into the user experience, the usability. This is about making sure that it's valuable. When you're talking to the customer and trying to understand the users, we get a lot of clients that like to skip the research part and go straight to wireframes. They take a UXer and say, let's start mocking out what this is going to do, but they skip the research part.

12:09That is critical because many times the problem that the customer thinks they're solving is may or may not be as big or as small as they think it is until they start talking to the users. Or we also see when we talk to the users that what we're building actually will solve multiple problems, one of which the customer was not even aware of. And so that design leader is very important. And then the third part is engineering. So yes, the engineering is very important to feasibility, but I think the engineer and what we call the technical architect or product architect provides a lot of direction in terms of where is the architecture going to go so that to your point earlier, when there was a shift in the market and maybe the value changed, the value prop changed, how quick can you pivot?

12:54Many times a customer sees what's about to happen and wants to pivot, but they're constrained by their infrastructure and their technology stack, meaning it wasn't done in a way that's super scalable. And I know we'll talk about that in a second. And so the engineering piece is very, very important to get it right up front in terms of the feasibility, but not just looking at, can I get the MVP, but what are we going to do past there and making really strong decisions up front with how we're going to make sure that this product is built in a way that's feasible, not just now, but long-term. Yeah, and it's critical that these three folks are working together, right?

13:32You see so many times where the requirements are defined, it gets thrown over to the designer, they design the thing, And then it gets thrown over to the technology folks and they're not working together. They're missing those components of the why. And the architects can bring just as much to the table on how to solution something as your designer or your product person. So you save so much time, money, and effort having them work together versus in kind of a siloed approach. And, you know, CICD, that's something that's you hear on the technology side, right? Continuous integration, continuous delivery, automating that and doing all that.

14:06But on this building the right thing side, it's continuous discovery, right? It's making that part of your process and going from, you know, problem space to solution space, figuring out what's the right solution to build, having that user feedback in there. That's critical to this product trio in a lot of ways. Right. And I think one thing that you kind of mentioned there too, is that we see the trio, we get two things. One, we see customers that'll start out and say, well, this is my product development team. And it's literally like four engineers, product owner. I mean, it's a huge team and that's fine, but that's more of a, almost kind of a third grade soccer approach where everyone's chasing the same ball and you're, you know, you're, but you're, but you're burning a lot of calories or money, whether they're your employees or it's a partner.

14:53when you really haven't set up things to really get rolling. And the other thing we see is the trio is brought in and we see this again, you know, even with some of the other solution providers, they bring in their trio, their A team, their lead architect, their lead product owner, their lead strategist, and then the lead designer. And then all of a sudden they get through the first couple of sprints and those people go away. And so when you mentioned like, this is a continuous process. And so if you lose the trio that really got the thing started and they pull out completely and they have nothing to do with the rest of the process, that's a recipe for failure.

15:30Because no matter how good you are at knowledge transfer and yes, this team's going to go on and they got to work on a different project or a different solution. As soon as they peel out, I don't care how good the documentation is and agile, obviously you minimize documentation. There's stuff that's lost there. If that designer that talked to the customers up front is not there or still in the mix as you do the build and you're continuing to iterate on that design, it gets lost. And so those are the two things we see. I mean, what we like to do and recommend is start with the three, the trio, the product trio, get through your first couple of sprints, especially definitely sprint zero, and then any additional research and work that needs to be done, then you can bring in the Calvary.

16:14Then you can bring in the three, four additional engineers, all the other pieces to your product development team that you need. Yeah, so a great recap of that. So that's that first part of the built right mindset. Am I building the right thing? So it's got to be valuable, viable, feasible. The next component is, am I building it right? Right. You know, it'd be awful to build this awesome solution, solves a real problem, viable for your business, and it doesn't work or it goes down in the middle of the night. So take us through what does it mean to actually build the thing the right way? So we're going to dig into at least one of these deeper, but at the end of the day, is the product maintainable?

16:50And I think that's the one we'll go in a little further because there's a lot of components. Maintainable is kind of a high-level bucket for being able to continue to own the product. So a lot of times a customer, they build the product, but then they think, well, I'm going to get it to market. But they don't think post MVP and where they're going and the cost of ownership around software. And then the second thing besides maintenance is it's scalable. I think people say the word scalable, but they don't think about, it's not just infrastructure. You know, in today's world, especially with all of our great cloud providers, you know, the infrastructure scales on Q and scalable infrastructure isn't as much of a change.

17:36But scalable is also about, you know, if you build it the right way, that you can lower the cost as you scale. Is it scalable and is it scalable in a way where your maintenance costs, you get lower cost of ownership per customer over time? And then is the user experience scalable? We see a lot of times where maybe it's slow after you get a certain number of users. So performance plays a big role in the scalability. The third component is secure. In today's world, it seems like every day there's a major hack. Yeah. We deal a lot with fintech and healthcare data. So there's a lot of scrutiny around security and making sure that we're doing the right thing, you know, in a work remote world where a lot of people are spread out and working, logging in remotely and building great products.

18:28Security is a big thing and it's only going to get bigger. And a lot of times because they tend to say, I got to get this to market. I just got to get this to market. Well, if you get your product to market and you skimped on security and you have a breach, it's over. I don't care how good your product is. I don't care if you're in that infancy stage where if you don't nail it and customers immediately are going to lose trust because you're a new product to begin with, they don't know who you are. And so building trust and being secure is a very important component and not something to take lightly because you're rushing to market.

19:02And then there's usability. You know, the solution has to be usable. You know, we've seen this before, unfortunately, where we just, you know, customers just starts building. And then, and this is not just the UI that I'm talking about. It's got to be back to that three-legged stool, the product trio. It's got to be architected in a way where it's going to be usable. There's not going to be friction. An example might be where, you know, what are you going to use for your authentication provider? What's the architect designing? I get what the UX flow needs to be, but what technology are you using on the integration for your authentication?

19:42And is that the best experience that's going to make this application usable going forward? So those are the four components is the way we see it, Matt. Yeah. So maintainable, scalable, secure, usable. That last one's really interesting. So I've started following Dharmesh, obviously a creator of HubSpot, built this huge business and he's playing with this new, creating this new tool called ChatSpot. And you think about the usable component, it's being kind of flipped on its head with this introduction of and proliferation of AI. And it was interesting the way he talked about it, right? There's this imperative approach, which has just been, you know, done up until this point where you have a user that comes in, they click here, they drag this, they touch that, they swipe that to get to their outcome.

20:28It's very user-driven with the components of how the software is built. With the introduction of AI, it's changing the approach. It's getting to this, as he described it, a declarative approach to where you now can go straight to the AI and declare what you want or the outcome you need. And AI is doing all of that work and it's providing the outcome. So UX is, a lot of that's going to be flipped on its head with this new introduction of AI. And that's not the only area it's going to touch. I know there's going to be a lot of episodes where we go deep into this, but it's changing so many things right now.

21:04Yeah, no, I mean, I think AI could play a role in a lot of these areas. I also think that AI could be why you need to pay attention. Let me, like secure, for example. I think I saw over the weekend there was an AI-driven cybersecurity attack, right? So all this technology that can be used to do things well, like the example you gave, can also be used to do things bad and make things worse. And so I think a lot of this technology, especially the AI-driven stuff, could be a big factor in a lot of areas. But it all has to be guided and informed in the right way to be able to get there. And I think for us on the usability side, I think it falls into a lot of areas.

21:52I was thinking about this when we were talking about usability. I used to build a lot of products in the communication space and accessibility is a big thing. It's not really a UX thing, but, you know, you literally can't launch the product in the communication space because of the way it's governed by the government unless it's accessible for all. And if you think about what accessibility means, you know, to those that need to be able to access, it's a big deal. and it's a meaty thing and it's a lot of work. And so if you're not thinking about the usability of your application before you're looking to get to market and looking at those things up front, you're not going to be able to launch or if you do launch, you're going to be shut down or you're going to have a lot of negative feedback because of the way you did it.

22:43Yeah, huge component of user experience right there. And you mentioned maintainable, wanting to go a little bit deeper there. Maybe hit at a high level, just some of those core components that make your solution maintainable and why that's so important. Look, I think we could do a whole podcast on maintainability because maintainability almost takes into a lot of the components we already talked about. So for example, it needs to be modular. That architect up front needs to design the solution in a way that's modular because if it's modular, back to what we talked about earlier, where there was a change in the market that maybe you needed to pivot quickly.

23:19If you have a modular application or modular solution in the architecture, you can change one component without changing the rest of it, which allows you to pivot quickly. Your users have a change in their needs or the need got expanded. By building in a way that's modular, your solution's more maintainable. So therefore, you can pivot quicker on the business side. The second thing is, is it reusable? at HatsRoy, we believe a lot, you know, almost there's so many libraries out there. We try to automate as much code as possible and use as much code. That's just re that's already out there. That's already been tested.

23:54That's already there. There's no reason to invent the wheel when you don't need to. Um, it's like building blocks, you know, in the building blocks that you can build off of that are common stakes, use them and then spend a lot of your, your cycles and your calories and the more complicated parts of the application, the special sauce, the thing that makes your product different. And then the third thing is it analyzable. A lot of times we'll, especially when we're doing minimal viable replacement products, so that's our version of kind of changing, you know, modernizing an existing product. We go in to look at these applications and they're a mess.

24:29Like the code is a mess. It's got, you know, we'll run some diagnostics and it's just like almost impossible to analyze in parts of it. And, you know, when you build an application, making sure that the whole code base is built in a way that can be analyzed. A lot of times for us, we know we'll eventually hand that over to the client and for them. So we want the code to be easy for them that, you know, whatever, you know, depending on what we're building in, Node, React, whatever. We want to make sure we build it in a way that when we hand it off, they can quickly get in and identify if there's an issue or if they want to make changes because they're adding on to the application that they can see that.

25:06And then the fourth thing is modifiable. So making sure that the solution is not going to have any issues in terms of new defects, that when you modify the code, you're not going to break something else. And I hear this all the time. Yep, we made changes and then it broke 10 other things and they have no idea why. And so making sure that the code is simple to modify if things need to be changed. And then the final component, you mentioned CICD. We also believe heavily in testing automation. and making sure that everything that can be automated can be tested and automated through testing because that makes it more maintainable.