How to Build a Minimal Viable Product Without Blowing Your Budget

Welcome to Building Better Developers, the Develop-a-Nour Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are continuing a season of Building Better Businesses, even though we are Building Better Developers Podcast, also known as Develop-a-Nour. Actually, it was Develop-a-Nour first and then now known as Building Better Developers. That's a story from another distant podcast episode way, way back there. I happen to be Rob Brodhead, one of the founders of Develop-a-Nour, also a founder of RB Consulting, where we are what they call boutique consulting. We basically sit down with you and craft a custom recipe for your business, how to move forward, leverage technology through simplification, integration, automation, even innovation. We help you wrangle that technology sprawl, give you a good understanding of what's out there, what will work for you, your budget, where you're at, not only today, but six months, six years down the road and beyond. Putting together basically a technology roadmap so you can make the best use of your investment in technology for as long as your business exists, basically, because technology is always going to be around. Good thing, bad thing. This is a different one. I'm trying to think because I've had a pretty good string of good. So the bad, we'll have to see how that one goes. I'll give you a fun one. So good thing is I had a day that was going to be full of driving. I was like, I'm going to be spending the day driving. It wasn't, it's basically like, I'm going to be chill. I'm going to be able to just like hang out and stuff like that. It turned into almost a better thing because I had, my daughter was going to go with me who had to work. And so we're like, all right, we've got to bail out on this. So now I've suddenly got a free day because I was going to be driving. Now I'm going to be driving at the middle of the night, foreshadowing of the bad thing. But it managed to essentially be forced into a free day. Now some unknown people actually hijacked that day and I ended up in like 18 hours of meetings it felt like. But I did see a good movie at the end of the day. If you haven't seen the amateur, I highly recommend it. It is a, it's a slow burn movie if there ever was one, but it's actually really good. And Ramek, whatever his name is, it did Freddie Mercury in the movie. And he's done a couple of his little odd looking guy, but he's, he's like just right for this kind of part. So really fun movie. And then of course, the bad thing, the really bad thing was then we started our drive, a six hour drive, well, what should have been about a four hour drive, five hours once you had the time zone change at about midnight. So we got in about 5 a.m. local time. And part of that was it took longer than normal. It was not a quick trip because we had all kinds of like flood issues and stuff like that. So moral of the story is once you have a free day, do not take any calls or texts or anything else because they might just blow you up. If the person sending those are Michael, who is now going to introduce himself. Hey everyone, my name is Michael Molloch. I'm one of the co-founders and developer, building better developers. I'm also the founder of a company called Invision QA, where we help businesses really understand if the software is working for them. If you're having problems with your software stack or just your day to day processes, your software is not helping you run your business. We come in, we help you analyze your systems. We help you define your processes and we will either build you something custom or help you really find the solution you need to really improve your business and make your customers happy. Good thing, bad thing. Good thing we survived the storms. We've had some nice warmer weather. It's been nice. I've been able to sit outside. Bad side of that, my allergies are back to killing me again because a few more trees have not come in yet. And so I figured I got about another two to three weeks before I'm done with the pollen. Little other bad thing with that, because it's warmed up, the stupid boar bees are back. And I have, I almost called the pest company to come out and spray this time, but I got some spray and I actually sat outside the last few evenings with a little fly spotter and batminton and we've just been bashing the heck out of these boar bees that are driving us nuts. So that's been good and bad. All right. Pro tip. Whatever you call them, they're also called like carpenter bees and stuff like that. Exterminator gave me this trick a while back and it has turned out to be phenomenal. There's what you do is you wait until sundown until it gets like, you know, so they, because basically they go out during the day and they come back at night. So you wait till they're all home and then you go find their little holes that they've drilled in their little nests and you take some WD-40 and you shoot it up in there. And basically it totally messes with them and ends up, they end up basically, I don't know if it's, you know, suffocating or whatever it is, but it eventually kills them. And mostly it'll kill them in there. They don't come flying out and it will screw it up enough that nobody's coming back to that nest or anything like that. And I have, I had a lot of trouble with that in my last house. I probably have, like if I had little tats, I'd probably have like 4,000 tats down my arm of all the little bees with little tears or whatever they would be that I took out. But it does work. It's there's a lot of stuff that doesn't kill them, but that stuff will. And it's sadistically fun to sit there and watch them like try to, you know, cause they'll come out and try to get after you, but their wings are shot. So there's nothing they can do. And then you just like, sorry, bud, you came to the wrong house. All right. Makes sense. So that's a good tip because we've tried that, but we've never done that in the evening. We've always done that during the day. So that's a good trick. Yeah. You got to wait. It's sort of fun to sit there and have a glass of wine while you watch them come back saying, this is your last trip home, buddy. So the violent portion of this, now you can go get their kids and they can watch the rest of the show because we're going to move on from that. Hopefully depending on, cause this topic could actually introduce some vulgar language along the way, depending on how we go with those stories. We're going to talk about MVPs and I'm not talking most valuable player. This is not sports. I'm talking technology, software, things like that, actually producing any kind of physical product even these days, which is a minimally viable product, which is what is the least you can do that creates a product or service even, I guess, that you can sell to customers and it brings them value so they give you money and you give them an equal or greater, preferably a greater value for their money based on this. Now that doesn't mean that it's like, it's not necessarily version 1.0. It's not very necessarily version 8.0. It is literally give them something that solves their problem. Don't go nuts. No bells and whistles basically, or very, very minimal bells and whistles. And we'll talk about that a little bit, but essentially giving them something that solves their problem. They say, yep, I take my money. That solves my problem. And then that allows you to take in money. The whole idea is that you can bootstrap it from there because now you have revenue, you've got a product, you've got customers, you've got feedback from those customers. You can build better product, whatever that is, or you can also go out and do things like get funding and things of that nature. MVPs are very nice to have because it's basically saying, I now have a product and I spent as little time and money as possible to get to the money-making portion of my business plan. Now a challenge for this is when you are doing it for a customer, when you are trying to get to a point that the customer has a limited budget, and this is honestly, even if it's not an MVP, sometimes you're going to have a customer that needs to solve their problem and they have budget constraints of some sort. And that budget may be money. It may be time. So those limiting factors are the ones that are usually not going to say, don't give me something too high a quality because it's really it's time, especially it's resources time and quality are your three legs of your stool. Quality is always going to have a, that's when they're always like, I want a lot, but do what you can with the other things, which is the time and money. Time is the easiest one to work with because basically if it's a deadline, we have to have this by January 1st, December 31st, something like that. Then you know what the time is and you just figure out as much as you can get done, but you need to make sure, and this is a trick with that one, need to make sure that you are complete in a way that you can deliver it on that date or before. So it doesn't mean that you're going to write code up until if it's December 31st, it does not mean you write code until December 31st. It means that you need to make sure that your code cutoff is sometime before that, that allows you all of the things that need to be done to make sure that that thing can go in and be production ready going on December 31st. And that's yes, sometimes testing, but the harder things that are in there as far as like a hard deadline or a hard timeframe are going to be things probably like deployments. There may be some sort of fulfillment or something like that. There may be servers that you have to like spin up or domains that you have to get going or maybe there's mailing lists that you have to warm up. There's all kinds of stuff like that that can go into these things that you need to make sure that those are taken into account. And what's typically done is it's called backward scheduling and contingency planning when you do that, which is essentially you have your deadline date, you know how far you've got to get there, and then you start basically building out milestones saying, okay, well, to get to this end date, I have to be at this point, you know, at this point, have this much done to be at this point. And then you roll that well, then that means I have to have this much done at this point. And you roll back, so I have to have this much done at this point. And you go all the way back to basically right here and now where you're at and go, okay, can I do that? Or if now you had to start, you know, started three weeks ago, then say, all right, I've got to cut some stuff out. And the contingency planning thing is you just did a happy path to get you from here to completion. But now you've got to be sitting there going, all right, this is a very hard, firm set of milestones and deadlines. So we need to make sure that we have built in whatever planning and whatever wiggle room we need to ensure that we really can hit that date. So while it is in some points easier because you have a hard day, it's also in some points harder because you have a hard day and there's a lot of stuff that you can't work with. So quick question for you there. Yeah. For those listening, you've laid out kind of the way to back the way to figure out the roadmap, the contingency planning. What happens when you miss that or you did not plan for that and you now are reaching a point where it's like crap. Now we're three. We're supposed to be starting three weeks ago, but now we're say two months from the end and we're a month, you know, where how do you handle when you reach a point where you've missed the mark and things are way off track? When you miss the mark and they're off track, I like to think of like I can't think of a movie where it's got it specifically. There's there's probably several movies you've seen where and probably even in cartoons where they're like in a boat and something's chasing them and they're trying to get away from it. So they're just throwing stuff off the boat to try to get the boat light lighter and faster. That's effectively what we're doing at that point. And this actually is going to occur possibly regardless what your resource constraint is. So this could be in money, too. It could be that. And this happens a lot. So it may be your fault or it could be, for example, you've got a customer that thinks they have a budget and they are sure they're going to get to this certain point and everything's funded and suddenly some of the funding falls through. And now suddenly the six month runway you have turns into one month or it's like, well, you can do more than a month's worth of work, but you're not getting paid after that, which is usually pretty heavy incentive to get it right. So this actually goes to that whole idea of minimally viable product. And honestly, when you have something like that, when it's like we're off track, but we still have a deadline, we cannot get all this stuff done. Guess what? It's time to make some potentially hard choices. Now, there is usually and before I throw this to Michael, I mean, I throw a couple of ideas out here because I'm going to see what your thoughts are on these. There are usually I'm going to be like mean about these and call them. There's like fluff items that are involved in projects. There are things that we do and there are processes and procedures and red tape and all that kind of stuff that we do have that definitely help us with quality and communication and things like that. But they also are things that aren't actually necessarily getting the work done. These are often meetings of some sort. Sometimes there's certain there may be a flow or something like that. For example, maybe we have our we've set everything up with CI CD pipelines, but it takes six hours to do a deployment because they have to go through all these steps and hoops. So maybe instead of that, we need to shut that down for a little bit or turn those things off. It could be constraints we have on the system. For example, if you're moving data or migrating data, sometimes there's things where it's like it's really slow. But if you drop all of the indexes or all the constraints or you re-index it differently just for the migration, then you can make a world of difference. Those things can always be cleaned up, too. I've known several times, including one I'm on right now, where I create indexes on a regular basis and even temporary columns and some stuff like that to move the migration very quickly through, knowing that I can always come back after the fact, blow those guys away, clean everything back up and make it pristine when we get to production grade. So it's a little bit of a instead of let's make everything do everything exactly right. It's a little bit pushing it, which I don't always recommend this, but it's pushing it to say we're going to worry about getting it right when it goes to production. But before that, we're going to like we're going to find a way to streamline some of these processes. And that means that we may remove some of our normal barriers just so we can do that. Now, I do want to say be very careful when you do that, because you may end up putting yourself in a worse situation than you would have been otherwise. So you need to be very intentional about where you decide to get rid of, you know, when you get rid of guardrails, just make sure you're driving a lot better so you don't go over the edge. One other thing you can do is the obvious thing is do less. So look at the tasks. And if honestly, if you're off and you don't actually know what all has to be done to get there, the first thing is figure out what you need to do to get there. Get yourself a list and just basically say, OK, how do we complete this? Here's all the tasks and then look at those tasks and say, which of these can we live without? And there may be mitigating circumstances and stuff like that. So you may look at and say, well, these three tasks, it would take a week. We can deliver something that's a little bit lower quality or maybe not as good a user experience or maybe there's a bell or whistle or something like that. And we can take those, we can roll them into one, get it done in a day and boom, we've saved some time. It's literally like. It's like any other budgetary process is look at what's there, figure out what you have to have and then start figuring out where you can say, well, we don't really need this or we can save a little money here, a little time there. We can do this. We know if you look hard at it, I guarantee you, you will find opportunities that are in there. Now, go with those. And then, you know, first, I guess a little bit your thoughts on those. And then what are some of your additional thoughts on this? Yeah. So when we're talking about, you know, minimal viable product, to me, when you think about taking on a project from the beginning, like starting the project, how what are you conceptually thinking of the MVP? To me, it is, you know, what is, you know, how do we solve the customer's problem? Right. You know, what is the end product going to be to solve the problem? Interestingly enough, when I sit down with customers and talk to them, the first thing thing I think about is what all is required to build the system that is required for the MVP. I look at it like, OK, we need servers. We need back end. You know, what is the minimum you need to put this application together to build it for the customer? Because that right there tells you, do you have the skill sets you need? Do you need to go hire someone? Do you need or do you have missing areas like testing? Or are you building something that requires a a content expert? You know, are you in the area where you need someone with more legal experience to cover back end stuff? Because there's things that sometimes when you build these systems or you hear it, it's like, oh, this is easy. I can build this. And then you get into it and you find out, oh, crap. You know, there are way more things to think about than what we initially thought about. So. MVP to me is. What is the to what? All right, let me back up. So when I think MVP. I think what is the minimal, not necessarily most viable product, but what is the minimal requirements? What is the minimal features I have to put in place to get this working for the customer, then add all the bells and whistles and UI and pretty pretty up for that. So MVP to me could be almost wireframe web applications like you are getting the ugliest application is functional. It works, but we need to pretty it up. To me, as long as you get an application out that covers everything the customer needs and it is usable, it is user friendly enough, you have an MVP. Then you can add all the prettiness. You can go get a UI expert to say, hey, you really need to be doing all this or, oh, here's a quality, some quality of life improvements you can make to the application. Typically, when we take on projects, we are not thinking quality of life. We are thinking we have an image in our head based on what the customer said, and we have conceptually. Figured out how we can go from A to B. But there might be 100 steps between A and B, but we only need 30 of them to get from A to B to be an MVP. It is an art and it is something none of us get right the first time, the second time, the third time, or possibly ever. MVPs are very hard to get right on a deadline because there's always that little wiggly thing in the background called the unknown. Right. Those are the things we don't know. It could be government regulations. It could be features that the user doesn't understand that their current system does or that they need to do to be compliant. So you have to be very careful when you think about these MVPs. And you may give a deadline or a, hey, we can do this in six months, but you run across one of these and you immediately have to say, okay, we are cutting the fat. Nice user interface. Gone. You are getting the bare minimum to get what you can have just so we can get everything in some it's it's very hard. Especially for me. And I think it is for you too, Rob, because we always want to deliver something to our customers that our customers will enjoy. It gives them quality. It gives them, it improves their lives. We don't just want to give them the bare bones application to meet their needs. We kind of want to make it a little more polished, but sometimes when we're dealing with an MVP, the polish goes out the window. You have to literally get it done. So you are going to duct tape WD 40. You are going to do whatever it takes to get it to the bare minimum application. And like Rob said, you know, sometimes budgetary constraints happen. Oh, customer suddenly loses funding. How can you still get them from where you're at to deliverance to the delivery without breaking your budget too bad? You know, at the end of the day, we all have to get paid. You know, we don't do this for free unless you're a nonprofit. But even then, you're still getting funding from somewhere. The problem is there is always a budgetary constraint to doing these things. And that unfortunately is one of the biggest struggles we have because you may quote one thing, but if it's a fixed bed, you're stuck. So anytime after that, you are losing money or you are, it's costing you money and time to get this product out the door. So I like how you brought up the contingency planning because to me, I try to think about that upfront, but it's one of those where sometimes you don't have everything upfront. So you can't quite do the contingency planning upfront. And maybe as you're building the roadmap or you're building out the project, as you're going through stages, maybe divided up by four. Say you have a 16 week project to divide before every four weeks, you have a pause. Okay. At the end of this phase, where are we at? Is the roadmap or what we perceive as the roadmap on track the next four weeks at 16 weeks at the halfway point, you should be more than halfway to completion on this. You should be almost ready to put a product in front of the customer or do some type of user acceptance testing, especially when you get to the in-between point after that, because you don't want to hit the end and be like, oh, we have no testing. User hasn't seen this. There's no training. So you've got to make sure that somewhere between the beginning and the end of the project, that you go through the process of including the customer, doing user acceptance testing. You know, I always talk about testing, but the problem is when we get into these projects, any project I've worked on testing is always, there is some form of testing, but the full testing is unfortunately limited or thrown out to the very end because we're too busy trying to meet the constraints or the deadlines that we have within budget. Every company has this. It is hard. It's that's why. If budget permits or you can add to the budget, get that tester in at the beginning because you really need to be building that as you go so that by the midpoint, you have all these testing point where the developers can say, okay, I've made code changes. I push a button. Boom. Oh, something broke. I can go fix it. So you don't waste time on manual testing or tracking down bugs later, which is more expensive. What do you think Rob? Now I want to give a, I guess a, a little secret that you can use when you to help you with some of these things. Sometimes you're going to know upfront that you're going to have a, you're going to know what the limits are. Often you're not, there's going to be a point where you, and this is, this is where honestly, this is where agile and sprints actually comes into focus is it's the whole goal of this is that we are going to periodically in very short period, you know, two, three, four weeks sprints, however it is, we're going to have something that is deliverable. It's not necessarily an MVP, but it is moving towards an MVP, something that they can use the whole point. If you look at the, if you go back and read the agile manifesto is it's like, we want to deliver working software. So there should be testing in there. There should be something that provides some use to your users. The use may be, and we've talked about this before, but the use may be that it's just exposing them to what you're building so that the UAT process can start. So they can do things like say, I hate that color or I can't stand buttons like that, or I don't know how to work a dropdown or whatever it is that will help you sort of pull the UAT process forward. Now, if you go into the project saying, I want to, no matter what their budget is, I want to get them to a solution as fast as possible with quality and all of the things that make a, that make, so I'll be proud of what I put in front of them. That does help because what you're going to do is you're going to say, oh yeah, you can give me a billion dollars in a year, but I know I'm going to under promise and over deliver and I'm going to be able to get this done maybe in six months for a hundred thousand dollars or whatever it is. That's where you need to be going. I think too often there's this whole like, let's get this budget and then let's build something to the budget as opposed to let's get the requirements and let's build a solution that meets the requirements. Because if you build a solution that meets the requirements, you're honestly looking at the MVP all along because somewhere along the way you're going to give them an MVP and then since you still have room, then you're going to be adding bells and whistles and improvements and all of those other things. But somewhere along the way before the end line, you have already delivered an MVP. Now you're doing a more valuable product instead of a minimally viable product or something along those lines. And so that is the little secret that I'm going to give you. We're not, you don't even have to listen to the YouTube side this time to get this bonus material. Now the challenge for this one gets to that point. Whatever project you're on, whether you're on track ahead of schedule, behind schedule, take a look at what is on the backlog or the to-do list or the feature list and just take a critical eye to them. This a lot of times is something that won't take you that long, but to just sit down and look at a critical eye and just say, do we really need these things? Now you may not be able to answer that, but I think it is worth it, especially if you're part way, you know, even a quarter of the way or beyond into a project is to go to the customer with those or whoever the end user is or the product owner or whoever that is and say, here's some things that I don't think we really need. And this is why. And just see if you can reduce the scope a little bit. So you're basically pretending like we've suddenly changed the game and that we now don't have as much runway. And you're going to adjust for that. Even if it doesn't work at all and everything stays the same, that's okay. The process of taking a critical eye to what you're building and sitting there and saying with each feature, essentially, is this really important? Does this serve my customer's requirements or not? Is a very useful challenge for you to go through. It's very useful skill for you to pick up, just like writing emails and to practice that you can send an email to info at develop a nerd dot com and let us know what you think. Where are you at? What do you like? What don't you like? What are some requirements that I would love to hear? This would be a fun little thread at some point. What are some requirements that you had that you suddenly realized we don't really need? Because those are fun stories. Those are the kinds of things that developers sit around going. You would not believe what these people wanted. And we finally talked them out of it or you would not believe what these people said they could do without. And we finally convinced them that, no, you do need that. So those are fun stories in and of themselves. If you enjoy these stories, and even if you don't, you want to learn some more, you can always check us out at development or dot com. You can lose feedback on any of that, any of the blog posts or anything that's out there. Wherever you get podcasts, love to hear review, get anything back from you there. YouTube, there's a developer in our channel, so you can check this out. You can check out all of the other stuff we've done over the years. There's lots and lots of video content out there as well, as long as go along with the And the bonus. What? And the bonus material. And bonus material that happens on almost every podcast, except for sometimes I just spill the beans early, or Michael, I think, has once or twice. So we've gotten the bonuses in a little bit early. But usually you will always get something extra, even if it's just looking at our pretty mugs a little bit after the pack. All of that to be said, thank you for your time. We appreciate you and all that you're doing. Your customers appreciate you too, because you're getting better as developers. And trust me, they like that. They love having a team that they work with that is getting better. Maybe it's not as fast as they want it, but still getting better as always good. Go out there with your better self and have a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. Thank you.