[0:00]Chances are as a programmer that you are, you've had product or business ideas that you really want to build. A SAS, a platform, whatever. And if you've been in the industry, you understand that the best way to go about building a product is to first build an MVP, a minimum viable product. By definition, it's the version of a product with just enough features for use to validate a product idea without investing a lot of time and resources upfront. But what if I told you there's a right way and a wrong way to go about building your MVP? Well, along with some famous real world examples, that's what we'll be discussing in today's video, the real way you should build an MVP, not the misconstrued understanding that many people have of it today.
[0:47]So what are the problems with MVPs? Well, the overall idea of an MVP is sound. Being able to ship a strip down product, test with real customers and measure its success in the marketplace without building a full-fledged application, that's a developer's dream. And in the early 2000s, this idea of MVP was widely embraced. They soon started to reap the benefits of saving time and money and getting user feedback quickly. But over time, a problem emerged. Instead of using an MVP for the aforementioned reasons, product managers, developers and designers decided to use MVPs as a reason to be lazy. They cut corners, removed necessary features and sacrificed the user experience in the sake of staying lean and shipping. That comes from the common misconception that an MVP is all about stripping down a product to ship as quickly and cheaply as possible. They run into the issues of, oh, what about this feature and that feature, gone. The user experience design? No, don't have time for that. Barely functional will do. What about the code? I'll just string together some spaghetti code, you can refactor it later. This is exactly how products fail. And while I do believe that perfection shouldn't be the enemy of progress, you're going to be at a disadvantage as opposed to doing it the right way. The most effective MVP still maintain a high quality of code, of design, of user experience, of content. They simply limit the scope, but you can see the difference between these two approaches. The wrong way is more like just slapping something together and hoping for the best. The right way to build an MVP is just building a limited scope version of your product that solves at least one problem for one audience in a unique way. Otherwise, there's no point in anyone caring about your product at all. I mean, the whole point of an MVP is just to conduct an experiment, right? You're essentially doing usability testing to see if your hypothesis is accurate, and to test its accuracy, there are a few key parameters or characteristics in that your MVP needs to satisfy. You want to see if it serves at least one specific, targeted audience, addresses at least one key problem or pain point for that audience, has a distinct, well-designed user experience that's functional, usable, and comfortable, and can be built and launched quickly. But there's a specific reason for this because even if one of these four key characteristics is off or missing altogether, then your test results are going to be skewed. They're going to lead to biased decisions and potential product failure because they're not actually getting what you want to provide. So with all that being said, and actually building the MVP, how do you know what features to include and what features to exclude? Because sometimes it's not as cut and dry as it may seem. And to do this, you have to answer a few questions. Who's your audience? What are their pain points? Which is easiest to help with the most impact? Can they afford a solution to their problems? Let's hop into the sponsor of this portion of today's video, AWS Amplify to serve as an example and to maybe build a little MVP of our own. AWS Amplify is a set of tools that brings the power of AWS to front-end web and mobile developers using JS frameworks like Vue, React, and Next.js for web or native iOS or Android, or Flutter, or React for mobile. With Amplify, you can enable backend resources like data storage, authentication, file storage, hosting your app, and even adding machine learning models to your front-end web or mobile application to easily build full stack apps on AWS. It really is a beautiful tool for building an MVP, one that's ready to scale alongside the growth of the business and dev team. But how about I quit talking about it and show you how it works and maybe we can build a little MVP of our own? To get things set up, we're going to go over to Amplify Studio, and I'm going to create and build a new app. While that builds and deploys, let's talk about the product. So what's the product? Well, I like learning about computer science. So what if I created a website that has you answer a computer science question every day in the style of Wordle where everyone in the world is answering the same question on the same day. The full-fledged application would have an automated process that displayed a new computer science question every day, pulling it from the data storage. Some would be multiple choice, others you would just type in the answer, and what would really be nice is to be able to embed a code editor so you can answer it using code. It'd allow users to look at old questions, have an account to look at their progress, and so on. But there's no point in doing all of that just yet because those things aren't necessary for the MVP. So I whipped up something using Figma that kind of solves this problem in how I see the simplest way. It tells you what this product is about, displays today's question, and allows you to answer it. And I could have easily built this using Amplify Studio's UI builder, but I built it in Figma to show you how it can convert to React code by syncing Figma with Amplify Studio, which imports the design. And inside Amplify Studio, we can create our data model for our questions, create a library of content, being the questions themselves, and export what we have here into our actual React application. You just create a new React app, install the Amplify CLI, install the Amplify libraries and UI React components, configure Amplify in your React code, and then wrap your app in Theme Provider. And to use a component, you just Amplify pull using your app ID, import the component to where you want to use it, and then render the component just like you would in any other React component. And that's it. You can still change your theme and components inside Figma, just sync it in Amplify Studio afterwards. Now your React application is integrated into the rest of the Amplify ecosystem where you can add authentication, storage, functions, and the rest of the tool set. Everything in one place to easily build, ship, and scale. That's the benefit of AWS Amplify. It gives you what you need, when you need it, so check out AWS Amplify by using the link in the top of the description and get started building your MVP. And now that was just a simple example because I wanted to show you how to use AWS Amplify, not because I have an actual business that I need to create an MVP for. So we did skip a few important aspects of building an MVP, I understand. Like, for example, when you're in the development process, new features and ideas are bound to come up where, oh, this could really help, and that could really help. But you need to ask yourself before you ship, can we ship without these features? Did your limited scope expand in that process? So you want to make sure you re-ask that question. Remember, you're asking it from a user's perspective, not a developer's or designer's or product manager's perspective. If we launch without this feature, will we still be able to solve the primary problem? This right here, and the entire development process itself, could mean that you're going against things that you think save you time, but don't. Not yet, at least. For example, automation streamlines processes and saves time, right? I mean, yeah, in the long run, but it takes a lot of time and resources to build out that automation to save you time down the line. So if you're on a, you know, strict timeline, maybe you forgo the automation for the time being. It's okay to include features in your MVP that don't scale. And I know, I know, it may seem counter intuitive, but building it manually at first adds the value that you're looking to provide without incurring additional development time and resources. In my example, instead of automating the process of displaying a new question every single day or emailing it to somebody, I could manually do that at a specific time. So it still seems automated to the user, but it's not. If the concept works, now you can automate. But enough with the hypothetical, how does this work in action in the real world? One of my favorite examples is of a company that this year in 2022, just sold for $44 billion. Yeah, you guessed it, Twitter. In fact, it started as an in-house project by Odeo employees, if that's how you pronounce it, and it offered one core functionality. Posting status updates through SMS. They didn't have all the features you know today, how they didn't even have a a web interface. But since they found they were using it so often, they decided maybe other people will like this, so they launched Twitter for a larger market and eventually created a web interface instead of SMS and grew Twitter to, you know, how you know it today. Uber is another example, they had a beta launch in 2010 for their iPhone app, but it didn't do what it does today. Especially in 2010. I mean, you're just going to convince a bunch of strangers to sign up to the app to drive their cars around and picking up other strangers and expecting those strangers to happily get into a stranger to them's car. Yeah, that's not going to happen right out the gate. The application, which was at the time known as Uber Cab, offered one service, connecting users to cab drivers, monetizing via in-app purchases and an extremely simple UI. This tested the idea that people needed easier access to rides, which from there they built into the Uber you know today. And I could go on and on about these examples, like Shopify and Dropbox and Zappos and Buffer. They all have their unique journey of becoming what they are today, but they all had one thing in common. They built an MVP to prove their idea would work. And you can take these lessons into building your own MVP. Just remember, it's less about building a product that makes a big splash right out the gate, and more about doing one thing really, really well. And there's always more to learn, but I hope the information I shared here today can help you on your product journey. Now go, go build an MVP of that idea that's been floating around your mind, the right way. Till next time.
