MVP, does it ring the bell? It stands for Minimum Viable Product and if you work in the startup world I bet you’ve heard about them a few times. If you don’t know what I am talking about, you may want to take a look at the Lean Startup first!
Before you read the text version of the post, you may want to take a look at this genially. Click on the elements on Jeff Bezos’ office to learn more about Amazon’s story and how to use the MVP mentality in product validation.
How can an MVP help me?
When we start working on an idea, it’s easy to get carried away: adding a bunch of features, imagining advanced interactions, integrations and intelligent processes, of course with a little pinch of social interaction and, why not, stories. Everyone is doing stories after all! Enter the Ferrari:
Ferraries are great and we can make a lot of money selling Ferraries, but as soon as we start refining requirements and looking into what is needed to create working Ferraries we will realize what seemed like an easy thing to sell, is also a complex product to build, that will require technical knowledge, materials, infrastructure, time…
…and money! Turns out building a Ferrari and paying all the people you need, for all the time you need to design, create and test the cars (not to mention compliance and administrative tasks) cost a lot more money than you have in the bank.
Before we invest all of that money (well, even before we figure out where will find it), we should dip our toe in the project, and validate it’s the right bet.
MVPs: beyond the stakeboard
Enter the MVP (Minimum Viable Product): The simplest product you can deliver to validate your hypothesis before you invest in The Real Thing. MVPs usually work as a way to discover hidden requirements, too. In the classic product literature, the MVP has been typically represented by a skateboard, that then becomes a bicycle, then a motorcycle, and finally a car.
While this is a great analogy, I’d like to invite you to challenge it and look beyond this image. Some MVPs (the best ones, if you ask me) don’t involve building anything at all. Moving on with the transportation example, let’s imagine a customer hires us to create a transportation solution. One for a group of people in a city that needs to get to their work every morning in a faster way.
Our initial research may uncover that users are having a hard time finding the shortest way to reach their destination. To begin with, we could try giving them a map of the area. The equivalent to a map is a consulting session, a document or a training session, things that can be validated with a relatively low budget.
Perhaps we figure they know the fastest way, but they walk there with high heels every morning, which is making their feet sore. Selling them fashionable yet comfortable shoes may be a way to address this pain point. I have not looked into the costs, but I suspect trainers are cheaper to produce and move around than Ferraris! Trainers could represent things like upgrading a customer’s current tool instead of building a new one from scratch. We all love creating products from scratch, but looking into improving current solutions could be an interesting opportunity.
Some distances are too long to walk, so if this is what we observe, a very cheap way to fix the problem may be to provide our users with public transport tickets. We could still add value by recommending the best tickets, for example, but using the infrastructure of a third party eliminates a lot of work on the operational side, which is great for MVPs. Build vs buy is one of the toughest decisions product managers face. Third party solutions can help in the early days.
If after all of this our users really, really need a personal means of transportation I am sure you will jump to researching about Ferarri Factories. After all, your research proved you need a personal way to move and everybody loves a Ferrari, as you’ve been saying since forever!
In an attempt to validate this, you may do some research and discover, to your surprise and deception, that the city you’re working in as huge parking problems, traffic jams that last for hours, and a gas price that has been rocketing for the last few months.
Happy about not owning a Ferrari Factory, you may decide to go for the famous skateboard, or to level-up to a bicycle since the beginning. Bikes have the advantage of allowing for personalization and accessories, so they will let you formulate and validate upgrading options as a next step. What I mean with this is that you don’t need to take the MVP method SO seriously: feel free to jump a step in the process if you feel the outcomes justify it. You are the captain of your destiny and the master of your soul – not your methodology.
As you put your bikes in the hands of real users, you may realize there is an interesting niche of users that you want to tackle that have unexpected needs your solution does not uncover. Very few people think of accessibility at the beginning, but as you progress on your iterations, you may develop a product line that looks more like this:
As you progress, you may discover this is actually an interesting niche where the numbers actually look better than you had planned in your Ferrari models. Congratulations, you’ve effectively pivoted! make sure you update your Business Model Canvas accordingly!
After all, sometimes the world has plans for us and our products that are better and more appropriate for the real world than what we had in mind. Working iteratively and using MVPs is a cost effective way to learn. Useful as a way to keep costs low in our way towards product-market fit!
Wrap up
Don’t look at research, prototyping and MVPs exclusively as validation tools. I love the surprise factor in them, and celebrate the discovery of unplanned possibility. And the best part? All for a few coins. An MVP that requires no code is the safest way to iterate. Time is money, and working on MVPs, instead of jumping on to build our Ferrari Factory, may save our products a lifetime!
