I have a theory, that every first version of a product should be treated as disposable. Your MVP should be something you go in expecting to trash and start all over once you’ve validated. An MVP, or Minimum Viable Product, as the term is defined is the cheapest/simplest version of your idea you were able to build and get to market in order to learn from.
Why an MVP should be trashed.
If you go into building an MVP but plan out how to scale it, or architect it to handle insane loads of traffic or sales, you’re likely over engineering your MVP. If you think, what is the absolute bare minimum I can build (including planning) for my MVP, you’ll likely get to market quicker, and be able to test faster. Forgoing extensive architecting or over engineering of your product allows you to save money up front, and use that money to market your product.
Your MVP should be designed for learning.
The goal of your minimum viable product should not be to make a ton of money from it, or serve hundreds of thousands of users. Only extreme outliers ever succeed in those efforts at the outset, so don’t waste your time with fantasies that you’re going to be in this boat. If you do end up being an extreme outlier, great, you can now afford to build a better product.
The purpose of your MVP should be to gather as much data about your customers as possible. It should be treated as a customer development laboratory. Each of your customers should be providing you with data and insights into what works and what doesn’t.
That extra feature you want to add which is going to delay launch by two more weeks (really 4, let’s be real), is not going to make your MVP that much better. That extra feature is not going to be the deciding factor between getting a customer to pay for your mvp or not.
Version 1 is where you scale
Assume your minimum viable product is a version 0. The version you build after should be your first full version. Version 1 as we’re calling it, should be the compilation of everything you learned from your customers and from their spending patterns. Only after applying this newfound knowledge should you care if your NoSQL database can handle five million records, or if your page load time is under 3 seconds, or if your app is built in Rails or Node or Scala. Prior to Version 1, none of that should matter. All that matters prior to version 1 is learning absolutely as much as possible.
Can you charge for your MVP?
Absolutely. You should have a price anchor in place from the very beginning. You can give people money back guarantees, or offer refunds to anyone who is unhappy, but absolutely do not give away your MVP for free. I don’t care if you think it’s not good enough to charge for, what you consider mediocre might be amazing to your customers. They don’t have your total product vision in mind, they don’t know what it is missing, and they only know what it does now. So get rid of that bullshit mentality of “well its not worth paying for yet, because its missing a certain feature” or some other excuse. That being said, you should absolutely start with the easiest billing tool you can, if its paypal or gumroad or stripe javascript embedded. If you have to reauthorize a customer later when you build out a better billing system just offer a discount for them being loyal customers. Ultimately the key is to not overthink your minimum viable product, get it out there quickly and efficiently.
Where to start building your MVP?
There are tons of tools out there that help ease this process. Steve Blank, arguably the father of lean startup concepts, has a great page. Also try tools like QuickMVP or Unbounce.
*photo credit for “minimum viable cake”