What do boxes, canoes and MVPs have in common?

September 27, 2018

In today’s episode, Joshua explores the concept of a minimum-viable-product in more detail and highlights the emphasis on focus rather than just doing less of a job. Both why you should build an MVP and what should go into it are covered.

• 00:01

  Hey there, welcome back to another episode of getting apps done, a -mostly- non-technical podcast about delivering applications.

• 00:09

  So in our last episode I talked about not building a minimum viable product. Today, I'd like to dig a little bit more into what an MVP is and how you can hone in on what minimum viable means for you.

• 00:22

  My name is Joshua Graham. I'm a technical consultant, which means I help businesses build software and then I help them deliver it and in this podcast I explained and yeah, sometimes I will go on at great length about how to get apps done.

• 00:38

  An MVP is really all about you getting your app done and doing an amazing job while you're at it. It's not about cutting corners. It's about focusing our effort (and our budget) on building the components of an app that are really critical and are going to provide the most value so we can do a better job of building those pieces.

• 01:00

  Instead of fitting in a lot of stuff. We're fitting in a smaller.... It's quality over quantity. In this case is what we're talking about because I would much rather focus on building two really critical parts of something and do a really amazing job of doing so and delivering them. Than to go build a lot of stuff that isn't as good and may not actually be used.

• 01:25

  So a minimum viable product is essentially the bare bones version of our application. It's the core value of what we're trying to provide and it is the smallest piece that we can build that's going to help either solve a problem or help people reach their goals or one of those things that we talked about, that are the cores of why we built it applications and what it takes to build an application that works well.

• 01:48

  So we're talking about identifying our target audience and figuring out what they think is the minimum for this to be a product that provides value that they want.

• 01:57

  A really great example of this, and I run into this every single year at Christmas. I run into the same problem. You would think that with as much as I talk about validation and improving and iterating upon things that I would get this right, but every single year it's exactly the same. I go out and I tried to find the best present ever for our kids and I will buy them whatever they want. It might be this amazing Playmobil thing they want or whatever it may be. I spent a lot of time and money trying to find that thing and get it for them.

• 02:29

  And every year I'll be, if I don't find them, while I'm putting together the amazing Playmobil or whatever it may be, canoeing down the hallway in the boxes. So I spent a fortune on this present. They begged me for for months prior to Christmas and they are in the hallway playing with the boxes that the toy came in... and it happens every single year.

• 02:50

  You would think something would clue in here that I'd be thinking, actually that's my minimum viable product, right? They're just boxes. Why wouldn't I just out and instead of getting these really expensive toys, get them some boxes and put some more effort into just the box, not the toy.

• 03:08

  I could build them a fleet of box canoes and put Nerf guns on them. All sorts of crazy things that they would think is amazing and it wouldn't cost me anymore, but I would have increased that core piece of value. They think they're getting out of Christmas. If it's the boxes they want to play with, why don't I give them boxes and better boxes, more boxes instead of getting them, or putting a lot of money into, some playmobil toy that now just sits in a corner and collects dust in their room. And um, every year left here thinking, where did I go wrong?

• 03:41

  And really I should know the answer to this because I run into this with software all the time. People are asking where did things go wrong when they want to know why their software has gone over budget or it wasn't delivered on time or whatever it may be. And it's all the same sorts of problems.

• 03:57

  Without focusing on the MVP. You're really opening the door for a lot of throwaway. There's potential that you're either building things or buying things that you don't need and you haven't fully validated and it's very easy to get into that situation because scope creep is so difficult to avoid.

• 04:15

  Otherwise you can't.... You're so focused on building something amazing that you are losing track of the core, focus on the value of what you're trying to build and in the long run that puts projects at risk and in some cases they just may not complete or they fail outright or at the very least, they cost a lot more or they take more time than you really expected them to.

• 04:40

  And it's no different than the boxes, when it comes down to it, because you're building things or buying things that aren't a part of the core value that the person that you intended it for is getting out of it.

• 04:51

  So what I could do before Christmas and what you should be doing with your software, is identifying that core value proposition. What is it you're building and what is the minimum you need to build that? And be very specific about it. What are you going to build to produce that value? And write it down on the list. Don't lose it. Keep track of that. What is that piece? And boil that list down to just the things you absolutely need because even if it's a really important feature or function or whatever it may be, or in the case of Christmas, they were absolutely desperate for these toys.

• 05:27

  If it's not part of that core value proposition and you don't absolutely need it for that, it doesn't go in.

• 05:35

  And a lot of people lose track of that because it's very difficult to understand the concept of something really important, actually not being really important. And that's what we're talking about here. It may be important and it may be valuable and it may be great, but if it's not a core part of that first piece, it's not important to getting your mvp done and that's where things go off the rails a bit.

• 05:56

  That's where scope creep really starts to get in and that is what extends projects and means that you aren't focusing and you're not doing as good a job as you could be building that one core piece you're spending or you're spreading your budget and your resource out over things that you didn't need.

• 06:13

  And that's what this is really all about is making sure you're not building things you don't need.

• 06:18

  You're not buying things that you don't need, but you're focusing in on those things that are really beneficial and really valuable to your end user because you can always add in things later and you should be. You should be iterating and improving and incrementing upon what you've got, but you've got to get that core piece first and the quicker and the cheaper you can do that. The better job you can do.

• 06:41

  It's not about building something that's inappropriate or incomplete. It's about the focus and really working to build an incredible version of your smallest piece. Instead of trying to spread that out over more.

• 06:57

  It's about looking at your application and deciding what you really need for it to provide value. And for it to be amazing, and I'll bet you it's a lot less than you initially think.

• 07:09

  Transcripts for today's episode will be up on gettingappsdone.com.

• 07:13

  Please be sure to check out my website as well to learn a little bit more about me at joshuagraham.info.

• 07:20

  Please don't forget to subscribe and check out our website, drop me a line I'd love to hear from you.

• 07:24

  And if you're building an MVP or you're getting ready to build an application and you're not sure about an MVP, let me know what you're up to. I'd love to have a chat with you.

• 07:32

  Until next time, thanks for listening.