A minimal viable product (MVP) is the smallest possible thing that you can build to tackle a core need, problem or goal that your product is trying to address. Other definitions include something that delivers customer value or something that allows you to learn more about your customers. In fact, an MVP is probably a mix of all of these things.
Sounds simple enough? However, these definitions can result in confusion about what practically constitutes an MVP. The key message though is that it shouldn't be the end product that you envision and it can’t be so basic that it doesn’t do anything.
Why start with an MVP?
An MVP is a good way to validate what your customers and users really want. They have something tangible to see and play with, and then you can get feedback on what's good or bad and what else needs to be there. You solve their core problem or need, so you make them happy.
Did you know that research shows that 80% of features in custom applications are not used? Imagine spending a whole ton of money on functions that just sit there untouched? What a waste of your precious time and money!
If you're constrained by time or money, then an MVP allows you to build something that can give you a foothold for you to grow from.
"My competitors do 'xyz'. My product needs to as well."
It's so tempting to look at what your competitors are doing, and want to replicate it in order to attract customers and users. I totally get it! Remember though that your competitors probably didn't have all of that to start.
It comes back to your strategic competitive advantage and your value proposition. If the core of what your product is trying to address is included in the MVP, and even if this is only slightly better than your competitors, then you're already ahead of the game.
If the market is so mature that you need all of those features to launch, then I predict a tough ride ahead. Remember that your competitors may have deeper pockets than you, so if you release a new feature, they'll likely copy it. You don’t want to go down that rabbit hole! Ultimately, you probably will need to build all of those features, but not for your MVP.
"My customers or users are going to expect more. "
In the world of software and product development, the word “launch” is actually a bit of a fluid term. At the point of releasing any new product, you're at the introduction stage of the product lifecycle. You're not dealing with thousands of users or customers.
You want a core group that are going to sing your praises and get you the momentum you need to grow. This group of early adopters understands that your product is evolving and they want to be one the journey. At this stage, you have the opportunity and time to add the extra features that you need. Then, when you’re ready, you can put all of your marketing efforts into getting all of those customers and users, so you can hit the “growth” stage of your product.
Why go even smaller?
All of the above is said with my product manager hat on. Now, I’m going to talk about it from a software development perspective.
Here’s the thing, if you’ve never built a platform or app, then you’re dealing with a lot of unknowns. This means that there are a lot of things that can go wrong. When things go wrong, it costs you time and money. You want to do everything you can to mitigate that risk.
So, in the process of building your MVP, why not start even smaller? Start your development experience by building a small part of your MVP. Get it done – whacked out in a couple of weeks and all of a sudden you've got a product. A very rudimentary and non-commercial thing – but it works. All of a sudden, you’ve completed something that you’ve never done before.
This is very important. In this experience of creating the first part of your product, you’ve also learned how software development really works. It’ll now be a lot easier to add to what you have built. Having a project to build all of the bells and whistles carries a lot more risk, than building something small and then continually adding to it. Something finished within two week or a month is way less risky than something that takes three months to build. Starting small also gives you a chance to test out your developer. If you’re not happy with how it all went, you can kick them to the curb with minimal impact.
When you’ve built enough stuff to have an MVP, you can then “launch” it to your early adopters. In fact, why not try and get some of them involved even earlier? They can help you to prioritise what should be added to your product and they’ll be invested in its success.
What next?
At the end of the day, building an MVP is just one strategy for product development - albeit a very popular one right now. It’s not a blanket “must do”. Like anything, there are going to be exceptions to this. There are other strategies for building new products that you can choose from - people have been following them for years with success.
As you take your platform or app idea to the next step, think about your approach for building it for its first release. How much do you really need it all on launch? How much risk is involved? Would you be better off starting small and continually enhancing your product until it’s ready for your big launch? Remember, sometimes it's worth going with small in order to grow big.
Are you ready to turn your good idea into a great product?
My idea to launch checklist is your plain-English guide to getting there.
It’s available now for only $24.