We're here to talk about minimum viable products or MVPs. When you're building a minimum viable product, that means you're building the smallest thing possible that you can launch quickly with a goal of getting feedback from users, taking that feedback, adjusting, and then building again. This graph here, it's a tweet by Mike, but it illustrates the idea of a minimum viable product really well. If you look at the 1998 side of the graph, this is the way software is built. So in cycles of 6-9 months. First, you develop the software. Then you test the software. Then finally, you deploy the software. After that amount of time, you get feedback from users. The more modern way to build software is to invert that process. To deploy your software first, then write your automated test, and then develop. The key part here is you're doing that feedback cycle daily. Once you get the software out there in prod and users are using it, you take that feedback and put it right back into the cycle and improve. The idea here is that you haven't delivered any value until you do ship to prod. So let's ship to prod as quickly as we possibly can, so we make sure we're delivering value for our users. Some of you might have seen this diagram before or a variation of it, but this for me really helps to drive home what an MVP is. Imagine that we're building a car. There are two different approaches that we can take to building a car. We could build the wheels, and then the platform for the car, and then the body, and then finally the passenger compartment. That would be like that top row. But if we think about that, we haven't delivered any value along the way. So what is a customer going to do with a wheel, or a platform, or a car without a passenger compartment? We haven't delivered any value for our users until step 4. It turns out maybe the customers don't even like what we've built in step 4. A much better way to build software is to learn along the way. The idea is that we want to break down our problem into small increments and have the product that each one of those increments be useful in a way that we can get feedback from users, take that feedback into consideration, and build something better. If you imagine we're building a car for a person, what we really want to do is break that down and say, what's the problem that we're trying to solve for this person? The problem that we're trying to solve is transportation. The simplest thing that we possibly could build might be a skateboard, and it's not going to give the users a big wow moment. The users aren't going to be too excited about using a skateboard when they thought they were going to get a car, but they're going to give us feedback. Maybe they don't like the color of the skateboard. Maybe they want some other features. Maybe the wheels are squeaky. They'll give us feedback, then we can go and build the scooter. Give that to more users. It's more along the lines that they were thinking, they can give us some more feedback. We'll go back to the drawing board and build the bike. Bike actually might solve most of the use cases that people need a car for. So some of our users might be fine with the bike. Maybe we're okay stopping there. But if not, we can iterate. Maybe build a motorcycle, get more feedback, and then go on and build our car. If you notice here, the car that we ended up with in that second step when we're iterating, getting feedback as we go might not be the car that we had in mind at first. In this case, the car is a little bit different, and that's the real power of focusing on an MVP, is you get feedback along the way from your users and you might end up or hopefully you end up somewhere totally different than where you thought you might have, but somewhere better than where you thought you might have. You end up with a better product and, good news, you've delivered value along the way. I'd encourage all of you to take this approach when you're looking at the projects for this course. Make sure before you do anything else, you get something working. Get something that you can deploy to a production-like environment. Test out, maybe get some feedback, send it to some friends, and then iterate on that. Continually improve it and make sure that it's useful every step along the way. It'll be helpful in your projects and further on in your careers as you start to build more and more software. Thanks and good luck.
