Detailed Notes
In this episode of Building Better Developers, Rob Broadhead and Michael Meloche share how to create a minimal viable product that wins customers — without breaking your budget. Learn how to launch faster, prioritize smarter, and avoid costly mistakes. Subscribe for more strategies on building better businesses!
00:00 - Introduction: Building Better Businesses 02:15 - What is a Minimal Viable Product (MVP)? 04:30 - The Importance of Solving the Core Problem 06:00 - Budget Constraints and MVP Development 08:00 - Building Backward From Deadlines 10:00 - How to Save Projects When Behind Schedule 13:00 - Prioritizing Features for a Minimal Viable Product 16:00 - Launching MVPs: Real-World Tips and Strategies 19:00 - Episode Challenge: Trim Your Feature List 21:00 - Importance of Testing Early and Often 24:00 - Continuous Improvement After MVP Launch 26:00 - Final Thoughts: Focus on Value and Stay Agile 28:00 - Outro and How to Connect with Us
#MinimalViableProduct #StartupTips #BuildingBetterDevelopers
Transcript Text
[Music] and I clicked record. So, here we are. Um, first off, apologies if the last couple episodes were a little too much because we we changed up our beverages a little bit. That doesn't mean it won't happen again, though. So, just uh keep an eye out. They might be fun in the future. Um, also, uh, if you don't know, Remastered Oblivion dropped the other day, like yesterday, depending on when you do it. So, it's probably, you probably have already solved it if you're an Oblivion person. If you haven't, take a look. Pretty cool, old school game. It's now 20 years old, basically. It's just almost, it's crazy. Um, and I probably have 23 years of play time on that. Um, so topics, uh, there's a couple that we threw out. I think one I think I want to do I think I want to tackle first the like an MVP. How do you provide a customer with a solid MVP? And then and actually it's as much about that as it is about let me put in my notes as it is about the budget is about making sure that you can get a MVP that meets their budget including you know that's money time all that other good stuff. So you got they've got resources are in place for an MVP and making sure that we can do that because that's something we do very regularly and I think that's a pretty good topic for like how to do that better. It's a little bit more of a developer kind of thing but I think it's definitely a business. It's like really figure out how to meet your your customers needs when you have a you know a service or an open-ended kind of contract like that. And then I like the other one. It's sort of like how to avoid chasing your tail, but I think it's like a I think it's going to be a don't panic kind of a topic is like what do you do when things are going off the rails is how do you like bring it back on because I think that is something that we have to deal with and it's um it's helpful to do it for ourselves and it's helpful to do it for our teammates, our bosses and people like that as well. So without any further ado other than I'm going to adjust my camera a little bit. We will get into the Oops. Do I have water? I do have water. Good, good, good. And we'll do a little three, two, one. Hello and welcome back. We are continuing a season of building better businesses. Even though we are building better developers, the podcast also known as developer. Actually, it was developer 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 Broadhead, one of the founders of Development, 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, your where you're at, not only today, but 6 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. H this is this is a different way. I'm trying to like trying to think cuz I've had a pretty good string of good. So, the bad we'll have to see how that one goes. Um, I'll give you 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. I'm probably going to It wasn't, you know, 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. And 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 got to bail out on this. So now I 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 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 felt like uh 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 uh it's a slow burn movie if there ever was one, but it's actually really good. And uh Ramik, whatever his name is that did Freddy Mercury in the the movie, and he's done a couple of these. Little oddl 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-h hour drive. Well, what should have been about a 4-hour drive, 5 hours once you had the time zone change at about midnight. So we got in about 5:00 a.m. local time. And part of that was it took longer than normal. Uh 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. Especially if the person sending those are Michael, who is now going to introduce himself. Hey everyone, my name is Mike Malashsh. I'm one of the co-founders of developer building better developers. I'm also the founder of a company called Envision 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 your software is just 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. Uh it we've had some nice warmer weather. It's been nice. I've been able to sit outside. Uh 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 figure I got about another two to 3 weeks before I'm done with the pollen. Little other bad thing with that because it's warmed up, the stupid bores are back. And I have I I almost called the pest company to come out and spray this time, but I got some spray and I actually sat outside uh the last few evenings with a little uh flice water and bminton and we've just been bashing the heck out of these bores that are driving us nuts. So, that's been good and bad. All right, pro tip. Um whatever you call them, uh also called like carpenter bees and stuff like that. uh Exterminator gave me this trick a while back and it has turned out to be phenomenal is what you do is you wait until sundown till it gets like you know so they because basically they 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 WD40 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 not 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 uh 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 uh there's a lot of stuff that doesn't kill them, but that stuff will. And it's uh it's it's sadistically fun to sit there and watch them like try to you know because they'll come out and try to get after you but their their wings are shot so there's nothing they can do and you just like sorry bud you came to the wrong house. All right but that makes sense though. 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 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 because 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 ne necessarily version 8.0 No, 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 then 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, you know, 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 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 that the customer has a 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 they're usually not going to say don't give me something you know too high a quality because it's really it's time you know especially it's resources time and and quality are your three legs of your stool quality is sort of like always going to have a that's one they're always like ah 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 you're like if it's a deadline we have to have this by, you know, 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 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 cut off 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 time frame are going to be things probably like deployments. Uh there may be some sort of uh fulfillment or something like that. There may be servers that you have to like spin up or uh domains that you have to get going or maybe there's mail-in 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 get 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 at 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 say well 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 have start you started three weeks ago. Then it's like, all right, I got to, you know, 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 uh 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 date, it's also in some points harder because you have a hard date and there's a lot of stuff that you can't work with. So, quick question for you there. Yeah. So, for those listening, you've laid out kind of the way to back the way to figure out that the road map, 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 started 3 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've missed the mark and they're off track I like to think of like and I can't think a movie where it's got it specific, but there's there's probably several movies you've seen where and probably even in cartoons where, you know, 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 you know 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'm going to throw a couple ideas out here because I'm going to see what your thoughts are on these. There are usually um 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. Uh sometimes there's certain um 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, uh 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 reindex it differently just for the migration, then you can make a world of difference. Um those things can always been 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 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 guard rails, just make sure you're driving a lot better so you don't go over the edge. Um, one other thing you can do is the 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 bas say okay 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 that would take a week, we can deliver something that's a little bit lower quality or maybe not as good a user experience or, you know, 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, you know, if you look hard at it, I guarantee you you will find uh opportunities that are in there." Now going 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 of the project how are 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 I think about is what all is required to build the system that is required for the MVP. I look at it like okay we need servers we need backend 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 uh or do you have missing areas like testing or are you building something that requires a um a content expert you know are you in a area where you need someone with more legal experience to cover backend 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 one sec. 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 it pretty it up for them. So MVP to me could be almost wireframe web applications. Like you are getting the ugliest application. It's 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 uh 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 a 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 one 100 steps between A and B, but we only need 30 of them to get from A to B to be an MVP. You it is an art and 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 system 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 6 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 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 barebones 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 WD40. 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 delivery without breaking your budget too bad? You know, at the end of the day, we all have to get paid. You know that 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 bid 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 up front. So, you can't quite do the contingency planning up front. And maybe as you're building the road map or you're building out the project, as you're going through stages, maybe divide it up by four. Say you have a 16week project. You divide by four. Every four weeks you have a pause. Okay. At the end of this phase, where are we at? Is the road map or what we perceive as the road map 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 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 It's hard. I 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 uh when you to help you with some of these things. Um sometimes you're going to know up front 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 week 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 drop down 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 underpromise and overd deliver and I'm going to be able to get this done maybe in six months for $100,000 or you know, 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 inline, you have already delivered an MVP. Now you're doing a uh 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 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 might 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 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, you know, 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 customers requirements or not? is a very useful challenge for you to go through. It's a very useful skill for you to pick up just like writing emails. And to practice that, you can send an email to [email protected] 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 realize 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 developer.com. You can leave us feedback on any of that, any of the blog posts or anything that's out there. ever you get podcast love to hear review get anything back from you there uh YouTube there's a developer her 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 of video content out there as well as long as go along with the and the bonus what and the bonus material and the bonus material that happens on almost every podcast uh except for sometimes I just spill the beans early or Michael I think has once or twice and we've gotten the bonuses in a little bit early But usually you're going to get you will always get something extra, even if it's just looking at our pretty mugs a little bit, you know, after the fact. Um, 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 they like that. They love having a team that they work with that is getting better. you know, maybe it's not as fast as they want it, but still getting better is 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. All right, your turn for bonus material since I already just like blew that out. Sorry for no bonus for me. So hopefully I'm just putting the pressure on Michael now. So one of the things we didn't really talk about through the MVP is when you're looking at a project or in your project there's really a couple categories musthaves what is the minimal you know what is required to get the project functioning to build the basic infrastructure to get the application to work. Then there is the um so that is the uh must haves. Then you have the need to haves. These are things that the customer really wants. They really need it to do their work but it is not the must-haves. The must haves are what you need to have the application working. If you don't have the must haves, the application won't work. The need to haves could be things like, oh, I need an additional screen to do this or to do something extra outside of the core functionality. So, must have core functionality need to have things that are a little that are still required for the business but are a little outside of the must-haves for the core application. And then you have the wish list or the nice to haves. These are things like, oh, I would like this to be very polished. Oh, I'd like this to work on my mobile app. or oh I would like this to work on multiple browsers. These are things that can be pushed to the very end. 90% of what you need to have for the MVP is in the musth have or I'll even say 80%. The other 20% is the need to have and I would say maybe well all right so to keep this within 100%. So 80 19% 1%. 1% is the like to have the, you know, would like to have. Keep it in that core. Get that core done. Make sure that is solid within your requirements. If you don't have that, your MVP is going to fail. I think that's pretty good way to stop to wrap this one up is yeah, you got to look at it. Really does. MVP comes down to requirements. It comes down what and literally the definition of that word, what is required. And a lot of times you're going to hear something is required, but when you dig into it a little bit more, you're going to find out that that's not actually what's required, but something else is. I I hearken back to a story I've used a couple times where somebody needed this really fast way to view this millionpage report and they really didn't. They just needed to know the number of records in the page. So all of this work that went into trying to do this complex paging and caching actually was not needed at all cuz the only thing that they really wanted to do was run this huge report jump to the last page so they could see a total at the bottom and almost killed a customer over that one because we spent a lot of times before we finally got to that was like really that's all you need? It didn't occur to you didn't occur to you that maybe even they didn't even occur to them like maybe we put the total on the first page so they don't have to page through all the others. But that's why we're here and that's why sometimes we drink during episodes but we haven't this time or at least not anything other than water and caffeine. And I had caffeine free tea so I'm probably if I peel over at some point now you know why. At any point thank you guys as well. Thank you for your time for hanging out with us. We'll be back with another episode. We are just cranking along. We got some more fun stuff to deal with. So, go out and have yourself a good one and we will talk to you next time around. [Music]
Transcript Segments
[Music]
and I clicked record. So, here we are.
Um, first off, apologies if the last
couple episodes were a little too much
because we we changed up our beverages a
little bit. That doesn't mean it won't
happen again, though. So, just uh keep
an eye out. They might be fun in the
future.
Um, also, uh, if you don't know,
Remastered Oblivion dropped the other
day, like yesterday, depending on when
you do it. So, it's probably, you
probably have already solved it if
you're an Oblivion person. If you
haven't, take a look. Pretty cool, old
school game. It's now 20 years old,
basically. It's just almost, it's crazy.
Um, and I probably have 23 years of play
time on that.
Um, so topics, uh, there's a couple that
we threw out. I think one I think I want
to
do I think I want to tackle first the
like an MVP. How do you provide a
customer with a solid MVP? And then and
actually it's as much about that as it
is about let me put in my
notes as it is about the budget is about
making sure that you can get a MVP that
meets their budget including you know
that's money time all that other good
stuff. So you got they've got resources
are in place for an MVP and making sure
that we can do that because that's
something we do very regularly and I
think that's a pretty good topic for
like how to do that better. It's a
little bit more of a developer kind of
thing but I think it's definitely a
business. It's like really figure out
how to meet your your customers needs
when you have a you know a service or an
open-ended kind of contract like
that. And then I like the other one.
It's sort of like how to avoid chasing
your tail, but I think it's like a I
think it's going to be a don't panic
kind of a topic is like what do you do
when things are going off the rails is
how do you like bring it back on because
I think that is something that we have
to deal with and it's um it's helpful to
do it for ourselves and it's helpful to
do it for our teammates, our bosses and
people like that as well.
So without any further ado other than
I'm going to adjust my camera a little
bit. We will get into the Oops. Do I
have water? I do have
water. Good, good, good. And we'll do a
little three, two, one. Hello and
welcome back. We are continuing a season
of building better businesses. Even
though we are building better
developers, the podcast also known as
developer. Actually, it was developer
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
Broadhead, one of the founders of
Development, 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, your
where you're at, not only today, but 6
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. H this is this is a different
way. I'm trying to like trying to think
cuz I've had a pretty good string of
good. So, the bad we'll have to see how
that one goes. Um, I'll give you 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. I'm probably
going to It wasn't, you know, 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. And 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 got to bail out on this. So now I
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 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
felt like uh 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 uh it's a slow burn movie if
there ever was one, but it's actually
really good. And uh Ramik, whatever his
name is that did Freddy Mercury in the
the movie, and he's done a couple of
these. Little oddl 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-h hour drive. Well, what should have
been about a 4-hour drive, 5 hours once
you had the time zone change at about
midnight. So we got in about 5:00 a.m.
local time. And part of that was it took
longer than normal. Uh 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. Especially if the person
sending those are Michael, who is now
going to introduce himself. Hey
everyone, my name is Mike Malashsh. I'm
one of the co-founders of developer
building better developers. I'm also the
founder of a company called Envision 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 your software
is just 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. Uh
it we've had some nice warmer weather.
It's been nice. I've been able to sit
outside. Uh 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 figure I got about
another two to 3 weeks before I'm done
with the
pollen. Little other bad thing with that
because it's warmed up, the stupid bores
are back. And I have I I almost called
the pest company to come out and spray
this time, but I got some spray and I
actually sat outside uh the last few
evenings with a little uh flice water
and bminton and we've just been bashing
the heck out of these bores that are
driving us nuts. So, that's been good
and bad. All right, pro tip. Um whatever
you call them, uh also called like
carpenter bees and stuff like that. uh
Exterminator gave me this trick a while
back and it has turned out to be
phenomenal is what you do is you wait
until sundown till it gets like you know
so they because basically they 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 WD40 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 not
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 uh 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 uh
there's a lot of stuff that doesn't kill
them, but that stuff will. And it's uh
it's it's sadistically fun to sit there
and watch them like try to you know
because they'll come out and try to get
after you but their their wings are shot
so there's nothing they can do and you
just like sorry bud you came to the
wrong house. All right but that makes
sense though. 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 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 because 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 ne necessarily version 8.0 No,
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 then 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, you
know, 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 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 that the customer has a 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
they're usually not going to say don't
give me something you know too high a
quality because it's really it's time
you know especially it's resources time
and and quality are your three legs of
your
stool quality is sort of like always
going to have a that's one they're
always like ah 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
you're like if it's a deadline we have
to have this by, you know, 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 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 cut off 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
time frame are going to be things
probably like deployments. Uh there may
be some sort of uh fulfillment or
something like that. There may be
servers that you have to like spin up or
uh domains that you have to get going or
maybe there's mail-in 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 get 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
at 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 say well 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 have
start you started three weeks ago. Then
it's like, all right, I got to, you
know, 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 uh 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 date, it's also in some points
harder because you have a hard date and
there's a lot of stuff that you can't
work with. So, quick question for you
there. Yeah. So, for those listening,
you've laid out kind of the way to back
the way to figure out that the road map,
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 started 3
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've missed the mark and they're
off track I like to think of like and I
can't think a movie where it's got it
specific, but there's there's probably
several movies you've seen where and
probably even in cartoons where, you
know, 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 you know 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'm going to throw a
couple ideas out here because I'm going
to see what your thoughts are on these.
There are usually
um 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. Uh sometimes there's certain
um 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, uh 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 reindex it differently just for the
migration, then you can make a world of
difference. Um those things can always
been 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 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 guard rails, just make sure you're
driving a lot better so you don't go
over the
edge. Um, one other thing you can do is
the 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 bas say okay 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 that would take a
week, we can deliver something that's a
little bit lower quality or maybe not as
good a user experience or, you know,
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, you know, if you look hard
at it, I guarantee you you will find uh
opportunities that are in there." Now
going 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 of the project
how are 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 I think about
is what all is required
to build the system that is required for
the MVP.
I look at it like okay we need servers
we need backend 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 uh
or do you have missing areas like
testing or are you building something
that requires a
um a content expert you know are you in
a area where you need someone with more
legal experience to cover backend 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 one sec. 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 it pretty it
up for them. So MVP to me could be
almost wireframe web applications. Like
you are getting the ugliest application.
It's 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 uh 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 a 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 one 100 steps
between A and B, but we only need 30 of
them to get from A to B to be an
MVP. You it is an art and 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
system 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 6 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 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 barebones 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 WD40. 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
delivery without breaking your budget
too bad? You know, at the end of the
day, we all have to get paid. You know
that 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 bid 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 up front. So, you can't quite
do the contingency planning up front.
And maybe as you're building the road
map or you're building out the project,
as you're going through stages, maybe
divide it up by four. Say you have a
16week project. You divide by four.
Every four weeks you have a pause. Okay.
At the end of this phase, where are we
at? Is the road map or what we perceive
as the road map 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
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 It's hard. I 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 uh when you to
help you with some of these things. Um
sometimes you're going to know up front
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 week 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
drop down 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 underpromise and
overd deliver and I'm going to be able
to get this done maybe in six months for
$100,000 or you know, 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 inline, you have
already delivered an MVP. Now you're
doing a uh 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 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 might 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 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, you know, 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 customers
requirements or not? is a very useful
challenge for you to go through. It's a
very useful skill for you to pick up
just like writing emails. And to
practice that, you can send an email to
[email protected] 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 realize 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 developer.com. You can leave us
feedback on any of that, any of the blog
posts or anything that's out there. ever
you get podcast love to hear review get
anything back from you there uh YouTube
there's a developer her 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 of video
content out there as well as long as go
along with the and the bonus what and
the bonus material and the bonus
material that happens on almost every
podcast uh except for sometimes I just
spill the beans early or Michael I think
has once or twice and we've gotten the
bonuses in a little bit early But
usually you're going to get you will
always get something extra, even if it's
just looking at our pretty mugs a little
bit, you know, after the fact. Um, 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 they
like that. They love having a team that
they work with that is getting better.
you know, maybe it's not as fast as they
want it, but still getting better is
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. All right, your turn for bonus
material since I already just like blew
that out. Sorry for no bonus for me. So
hopefully I'm just putting the pressure
on Michael now.
So one of the things we didn't really
talk about through the MVP is when
you're looking at a project or in your
project there's really a couple
categories musthaves what is the minimal
you know what is required to get the
project functioning to build the basic
infrastructure to get the application to
work. Then there is the um so that is
the uh must haves. Then you have the
need to haves. These are things that the
customer really wants. They really need
it to do their work but it is not the
must-haves. The must haves are what you
need to have the application working. If
you don't have the must haves, the
application won't work.
The need to haves could be things like,
oh, I need an additional screen to do
this or to do something extra outside of
the core functionality. So, must have
core functionality need to have things
that are a little that are still
required for the business but are a
little outside of the must-haves for the
core application. And then you have the
wish list or the nice to haves. These
are things like, oh, I would like this
to be very polished. Oh, I'd like this
to work on my mobile app. or oh I would
like this to work on multiple browsers.
These are things that can be pushed to
the very
end. 90% of what you need to have for
the MVP is in the musth have or I'll
even say 80%. The other 20% is the need
to have and I would say maybe well all
right so to keep this within 100%. So 80
19% 1%. 1% is
the like to have the, you know, would
like to have. Keep it in that core. Get
that core done. Make sure that is solid
within your requirements. If you don't
have that, your MVP is going to fail.
I think that's pretty good way to stop
to wrap this one up is yeah, you got to
look at it. Really does. MVP comes down
to requirements. It comes down what and
literally the definition of that word,
what is
required. And a lot of times you're
going to hear something is required, but
when you dig into it a little bit more,
you're going to find out that that's not
actually what's required, but something
else is. I I hearken back to a story
I've used a couple times where somebody
needed this really fast way to view this
millionpage report and they really
didn't. They just needed to know the
number of records in the page. So all of
this work that went into trying to do
this complex paging and caching actually
was not needed at all cuz the only thing
that they really wanted to do was run
this huge report jump to the last page
so they could see a total at the bottom
and almost killed a customer over that
one because we spent a lot of times
before we finally got to that was like
really that's all you need? It didn't
occur to
you didn't occur to you that maybe even
they didn't even occur to them like
maybe we put the total on the first page
so they don't have to page through all
the others.
But that's why we're here and that's why
sometimes we drink during episodes but
we haven't this time or at least not
anything other than water and caffeine.
And I had caffeine free tea so I'm
probably if I peel over at some point
now you know why. At any point thank you
guys as well. Thank you for your time
for hanging out with us. We'll be back
with another episode. We are just
cranking along. We got some more fun
stuff to deal with. So, go out and have
yourself a good one and we will talk to
you next time around.
[Music]