Welcome to episode one of the Built Right podcast – a podcast series that explores how to build digital products the right way.
To kick off our first episode, we invited none other than HatchWorks CEO Brandon Powell to set the scene. Brandon and host Matt Paige break down the different components that make a great product strategy and team – plus what not to do when building digital products.
In this episode, you’ll hear about the different product experts you’ll want on your team, the importance of building a flexible infrastructure for your product, and how to scale your product effectively.
You can catch the episode in full below or keep reading for Brandon’s takeaway tips on building products the right way.
Introducing…the “built right mindset”
In today’s world, software is king. It doesn’t matter what industry you’re in, software has the potential to automate processes, save time, save money, modernize your business, or even find new customers.
In fact, a McKinsey study found that 70% of top economic performers are using their own software to stand out from the competition. It’s no longer enough to just build something or buy digital solutions off the shelf. Digital solutions should be a fundamental part of your business strategy.
But it’s easy to get it wrong, and that’s something that keeps our users up at night. The top two concerns our users have are:
• Am I building the right thing?
• Am I building it the right way?
Let’s take a look at the first part…
Am I building the right thing?
To determine whether you’re building the right thing, Brandon recommends asking yourself these three questions:
1. Is it valuable?
One of the most important things to establish is whether the product is genuinely valuable to the user. Value in a digital product comes from solving a problem. But it’s not just about that.
The product may solve a problem, but is that problem big enough for the user that they will seek out software to solve it? If not, then it may be time to head back to the drawing board.
2. Is it viable?
Is the product viable within your current business model? Will it be viable in a few years’ time? The last thing you want to do is confirm that it’s viable now and then 12 months down the line, find out that it’s not.
3. Is it feasible?
Does your engineering team have the resources, time, scope, and knowledge to pull it off effectively?
Feasibility is something you should bear in mind from the start because, without it, the rest won’t be possible. By considering feasibility early on, you can save yourself from investing time and money into a project that could be unrealistic from an engineering perspective.
Why you need this product expert trio
To help you work out whether you’re building the right thing, Brandon says you need a product expert trio that includes a product strategist, a product designer, and a product architect working together.
1. Product strategist/owner
A product strategist/owner provides the direction on strategy, sets the priorities, and is critical to building the roadmap from idea to MVP to finished product.
2. Product designer
A product designer provides insight into the user experience, the usability of the product, and ensures that the final product is valuable to the customer. They may spend more time speaking with users to understand their needs, priorities, and pain points.
3. Product architect
The third part of the product trio is responsible for the engineering side of things. A product/technical architect provides direction on the infrastructure and technology stack.
This trio together can help to meet those targets of value, viability, and feasibility when it comes to building your product.
Are you building it the right way?
You may be set on building the right thing, but are you building it the right way? You could have the greatest digital product idea that you know customers will love, that’s both viable and feasible, but still get some things wrong.
For a product to be built the right way, these are the top things you need to consider:
Brandon says a common thing he sees is that businesses will build a product but won’t think too much about its life beyond the MVP. They don’t consider the cost of ownership long-term or how the solution will need to evolve in the future.
To make your solution easily maintainable, Brandon says it should be:
It should be modular from the get-go so that when there are changes in the market or user expectations, you can pivot as necessary.
Reusability is also important. Not every solution needs to reinvent the wheel. If you can automate code effectively or use code that’s already been heavily tested, this can help to save time – freeing your team up to focus on the more complicated parts of the product.
When you build an application, you should make sure that the code base is built in a way that can be easily analyzed. That way, if there’s an issue, it can be resolved quickly because the code is easy to analyze.
Making the code easy to modify is another component of good maintainability. If the code is tough to modify, any bug fixes, changes, or upgrades you wish to make will be more difficult and time-consuming.
Finally, Brandon is a firm believer in testing automation and making sure that everything that can be automated can also be tested, and then automated through testing. This is vital for making adjustments easily and also scaling effectively.
Scalability is key to any successful business so it’s important to ensure the infrastructure is designed in a scalable way. If you build a product the right way, you can minimize the cost of scaling the product as well.
Brandon suggests asking yourself whether your maintenance costs are scalable so there’s a lower cost of ownership over time and if the user experience is also scalable. In other words, as your user base increases, will the product suffer any performance issues?
With cyberattacks a common feature of headlines, security planning should be an essential part of building digital products. There might be a temptation to rush a product to market, but it’s better to iron out the security side before users see the final product. The last thing you want to do with a new product is damage trust with your user base if there’s a security problem.
At the end of the day, your product needs to be usable. It needs to be built in a way that limits friction and prioritizes good UX flow.
This isn’t just about the product itself, though. If you want to feature integrations with other apps or complex functionalities, they all need to be designed in a way that’s simple to use.
All of the above is key to developing a “built right” mindset, and it’s the approach we like to take at HatchWorks. For more information and insights into building better products, listen to the full episode. Stay tuned for upcoming discussions on the Built Right podcast!
All 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, and Cricket, 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. The 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. And in the, you know, thinking in that Built Right mindset, who’s it for? Tell us who should be listening to this podcast.
Really, in today’s world, I think 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, it could be a brand new solution that doesn’t exist, it’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 take a 25, 30-year-old system and make it new again. So it could be any of those. And, now, in the digital world, 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 crept over into the business side.
Yeah, and you think about it too. We’re at that 10-year anniversary of Mark Andreessen saying, software’s eating the world, which was kind of a hot take then. But now software’s basically eating the world, cleaned their plate, and finished there. 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, off the shelf, bolt it on. Digital and your digital solutions have gotta be actually part of your strategy as a business today.
Yeah, I was reading that report as well and a couple of others where software IS the world. It’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.
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. Take us through that first component of built right, Brandon.
Well, 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 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 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, we 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. We know how to build it right and they know their business. 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 healthcare client that 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 gonna be in the coming months?
And then we have to look at feasible. And feasible at the end of the day is it doesn’t have the right components to it. Is it feasible that it can actually be developed I’ve been lucky to have some really strong technologists and 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, you know, 10 different integrations to all these, and, yeah, it can be done, but is it feasible, 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 customer. And 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 is actually 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. But you mentioned 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. Look at when the pandemic hit, how people valued solutions and how solutions solve problems completely changed. We’re a big proponent of the tool Miro. It became foundational to how we work because everybody was remote. 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. 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 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.
I 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 asked 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. So 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 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. Such a valuable thing! You don’t have to spend time in the grocery store. You can use technology to do that for you. So that’s a great example.
And there’s the team component to this too. All right. You talk about valuable, viable, and feasible. 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 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, some clients I see this and some clients I don’t. But we believe that you’ve really got to have this three-legged stool going in, right? So 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, 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 gonna do, but they skip the research part. That is critical, because many times the problem that the customer thinks they’re solving 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 gonna 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?
Many 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 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. You 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 a siloed approach.
And you know, CI-CD, that’s something that’s here on the technology side, right? Continuous integration, continuous delivery, automating that, and doing all that. But on this building the right thing side, it’s continuous discovery, right? It’s making that part of your process and going from 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.
All right, and Mattm I think one thing that you kind of mentioned there too is that we see the trio. We get, okay, 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 almost kind of a third-grade soccer approach where everyone’s chasing the same ball and you’re, but you know but you’re burning a lot of calories or money, whether they’re your employees or it’s a partner when 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 mention, like, this is a continuous process. And so if you lose the Trio, that really got the thing started completely and they have nothing to do with the rest of the process, that’s a recipe for failure. Because no matter how good you are at knowledge transfer, and yes, this team is 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, in 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 do the build or 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, then 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 gotta 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? And I think that’s the one we’ll go in a little further, because there are 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, that’s my, you know, I’m going to get it to market. But they don’t think post MVP and the cost of ownership around software.
And then the second thing besides maintenance is scalable. I think people say the word scalable, but they don’t think about it, it’s not just infrastructure. And in today’s world, especially with all of our great cloud providers, the infrastructure scales on queue and scalable infrastructure isn’t as much of a change. But scalable is also about, 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 a lower cost of ownership per customer over time? And then is the user experience scalable? We see a lot of times where it’s 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, I mean, it seems like every day there’s a major hack. 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. Security is a big thing and it’s only gonna get bigger and a lot of times because they tend to say, I gotta get this to market. I just gotta 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.
And then there’s usability. The solution has to be usable. We’ve seen this before unfortunately where the 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 that’s 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, 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? And is that the best experience that is going to make this application usable going forward. So those are the four components as the way we see it, Matt.
Yeah, so maintainable, scalable, secure, usable. That last one’s really interesting. So I’ve started following Darmesh, 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 to 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. It’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. is a lot of that’s gonna be flipped on its head with this new introduction of AI. And that’s not the only area it’s gonna touch. And there’s gonna be a lot of episodes where we go deep into this, but it’s changing so many things right now.
Yeah, 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 of 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, right? 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, you know, for us on the usability side, I think it falls into a lot of areas. I 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. That 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 to those that need to be able to, 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 upfront, 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.
Yeah, a huge component of user experience right there. And you mentioned maintainable, wanting to go a little bit deeper there. Maybe hit it 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. If 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 HatchWorks, we believe a lot… there are so many libraries out there, we try to automate as much code as possible and use as much code that’s already out there, that’s already been tested, that’s already there. Don’t reinvent the wheel when you don’t need to. It’s like building blocks, you know, and the building blocks that you can build off of that are common stakes, use them and then spend a lot of your cycles and your calories in 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 modernizing existing products, we go in to look at these applications and they’re a mess. Like 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’re eventually hand that over to the client and for them. So we want the code to be easy for them. Whatever we’re building in, whether it’s Node or React, 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.
And 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 the code is simple to modify if things need to be changed.
And then the final component, you mentioned CI-CD. 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. It’s easy to make a change if everything’s automated and your regression testing and everything’s done. We still see clients that push back on our standard team, we like to include an SDET, software development engineer and test. Their job is to write code to automate all the testing possible because if you do this up front, as you scale and you add your entire code base already has automation testing built into it.
And so Matt, those are the five things for us. So under maintainable, you know, you could categorize this ever how you want, but it is modular, reusable, analyzable, modifiable, and testable, it’s mouth mouthful. But those are all components that we believe if you take those together, you can build a great maintainable application that you can scale
Yeah, it’s such a big component. You mentioned that SDET, that’s like the unsung hero of the team. But yeah, so that’s the, am I building it the right way component of Built Right? Just to recap there, you have maintainable, scalable, secure, and usable. Those are the big four components there. But Brandon, take us through, kind of wrap it up. Who’s somebody that’s doing Built Right now in the market? Who do you see as somebody that’s doing this the right way in terms of the Built Right mindset?
Yeah, so there’s a, I have a one-year-old now, and I was talking to someone about kind of fintech and banking and what things are gonna be like. And they were, the person started talking about Greenlight. And I think that Greenlight is an incredible case study on building a product, the right product the right way. For those that don’t know, the Greenlight product really focuses around the younger market. So I didn’t realize this till I dug in a little bit, but the cost of acquisition for banks is very high. And typically when someone joins a bank, you can think about yourself, for example, you stay with that bank a long time. I mean, they really have to piss you off because it’s such a pain to move all of your data and everything. And so these guys are going after the younger generation, you know, that, you know, these kids, if you, you know, if you’re a parent out there and you have a kid, and you want to control their spending, but you can, you can get them a card. And this is a still a SaaS product where they have a monthly fee and different rate cards, but you are able to see what they’re spending on. And then there’s this educational factor. And so they’ve really focused on one target customer. They’ve made sure that their business model is viable. And then they’ve talked to a bunch of parents, the people that launched the product. They were solving a problem they were well aware of. They talked to other parents. They’re like, yeah, I have that same problem. There’s not a real easy way here to get my child into banking, but at the same time, be able to control what they’re spending. And they launched the brand. And they’ve been in the market for years. I think their market valuation is like two and a half billion or something. But it’s a perfect example where they started, they got out there and then they, I think they even expanded kind of their services and their offerings once they got out there and made sure that the product was going to be feasible and everyone saw the value in it. And I just think it’s a great example where a customer kind of went in and looked at it and said, this is the right product. And now, I don’t know if they built this in-house or they outsourced it, but they built it the right way clearly it’s scalable as they’ve continued to add more and more users over time.
Yeah, I think they’re up to over 5 million users now. You hit that viability component with the extreme cost to acquire a customer. So that business component spot on there too. So they’re hitting both sides of it. You know, we’re using this with my daughter right now trying to get her to read more. So if she reads a book every day, we got her set up with Greenlight and she gets five bucks. And it’s just like, it’s like gamified this for her. And the cool thing is like, they get to design their debit card. Like it’s just like every component of it’s so cool. She’s got her face on the debit card. She’s starting to understand what it means to save money. And there’s other components with investing and learning about financials. So they’ve really hit it in a lot of ways from what it means to have a built right product.
And you talk about another angle too, like one of our customers, MyFloc, it’s interesting. They’re hitting the other side of it as well. So it’s an interesting component. They’re hitting it from the senior side with helping manage your aging, whether it’s parents or family members’ money, similar kind of concept around there, taking this same kind of built right mindset approach.
Yeah, I think, MyFloc, shout out to them. They’re one of our customers. And I think they’ve done this right in terms of they built their MVP and now they’re getting a lot of research and kind of looking at their customers. And they’re also… their marketplace is very wide because so much of the United States is aging, right? We’re an aging population. So I think they, they play in a beautiful spot where, where people are getting older, they’ve built their base product, minimal integrations, those pieces. And now they’re in that phase where it’s like, do I have the right feature set that my customers want before I keep adding more and more and more features? And I really love their approach to kind of getting out in the market and kind of resting, making sure that they’ve got this thing dialed in before they pump more spend into it in terms of taking it and making it bigger. It’s already very scalable, it was built the right way. A nice minimal set of features for what they’ve done the research on. They talked to customers before it was built. And it’s a really great application. And I think they’re one of the next Greenlight opportunities and I really like their product and where they’re taking it.
Yeah, so I think this is a perfect spot to wrap it up. So to recap the built right mindset, you got to build the right thing that’s valuable for users, viable for your business, and feasible from a technology standpoint. And it’s got to be built right, something that’s maintainable, scalable, secure, and usable. I appreciate you joining the show, Brandon. Where can people find you if they want to find Brandon Powell?
Well, I took a hiatus from Instagram. So the only place they can find me right now is on LinkedIn, Brandon Christopher Powell. I’d love to connect with you out on LinkedIn. And I love to hear stories and learn more about great products that are out in the market. And we’re always learning. And I love learning. And so connect with me out there. And I’d love to chat with you.
Yeah, Brandon’s got some great stuff on LinkedIn. So thanks for joining the show, Brandon. We’ve got some exciting episodes coming up around how you modernize a digital solution the right way, and there is a right way to do that. The user experience, the product strategy component. We mentioned emerging technology with AI, just a lot of good stuff, and a lot of awesome guests and experts coming up as well. But thanks for joining Built Right.
Thank you so much for having me, Matt. I greatly appreciate it.