Minimum viable product (MVP)
What does MVP mean?
MVP stands for Minimum Viable Product. It’s become quite the buzz word in the last few years. It's supposed to be about delivering the core features which make your application unique. The point of the MVP is to strip away everything that’s not the core functionality, this leaves you with something game-changing hopefully. Which you then build in a much shorter time and allows you to test quickly and make changes even quicker.
An MVP can be seen as multiple MTPs (Minimum Testable Product). An MTP is seen as a way to break down your MVP further and test features with a small group of people. Track and analyse their feedback and then build new features from their feedback. It becomes an MVP to be released to the public when the testers would feel comfortable paying for it. This is when you know the feature set of your product for its initial public release.
That's the point of an MVP, its to get your core idea out there and tested with real people to see if that is something groundbreaking, something that is worth building. Something that people will pay for. That's the key, what is the least amount of product that people will pay for or at the very least be interested in using, that is the key.
The true value of an MVP lies in bringing the least amount of functionality to the table so that you can test it with real people and then build from there. It might very well be that when you build this amazing feature people hate it, or it doesn’t work nearly as well as you think it will. What's the point of spending hundreds of thousands of dollars on a mobile app for instance and then finding out that people hate it and no one uses it. What often happens is that the founder spends so much time and energy on making it pretty and the smaller features that they forget about the core functionality, the features that make your idea truly unique. Then when it comes time to launch, people see this beautiful app but it doesn’t have any substance. The other typical founder is the one that must have every feature be perfect before they release, these are the worst because they end up never releasing anything or if they do, it goes way over budget and time.
The smaller the better
When it comes to initial release do one thing well and everything else can wait. This might mean a calendar app that can add and remove events in a calendar but looks terrible. Users will forgive an ugly application that does what it wants over a beautiful application that doesn’t do anything. There's no point building a calendar app that’s beautiful but you can’t add or remove events, it doesn’t do anything. The point being, create as small of an MVP scope as you possibly can. The smaller the better, you must cut down everything that isn’t necessary, only including the absolute one true feature and whatever it takes to get it to work. One of the best ways to do this is to say to your development team “Hey take whatever shortcuts you need to, to get this released in the next week.” However, when you say this you have to know that this MVP product must be rewritten, this sounds terrible. Why would I build something and then throw it away? To answer that check out my article which will come out in a few weeks called “Why you need to throw away your MVP”
Defining your MVP
Alright so I’ve told you how small the MVP should be but how do you define it and how long will it take? Well, the length depends on what you want to deliver. The more you want to deliver the longer it will take obviously. So how do you define what you should and shouldn’t deliver?
Well, it's pretty simple, what makes your product unique? If you're a dating platform it might be how two people interact that’s completely different to everyone else on the market. In this case, you would define your MVP as: “An application in which two people can interact in my unique way”. Your scope might be hard coding everything like the matching of two people, the date location whatever isn’t unique about your idea and then make the only variable that is not faked or hardcoded your idea. In this situation your idea might stipulate that two people can’t see or know anything about the other person before they go on a date, a date is preset by the two of you and you have to meet for the first time without ever seeing each other. To define your scope you would say “A user can use the app on their phone to hit a button that will match them randomly to another person. They then agree on the date, they can’t even see a picture of each other beforehand”. This makes it pretty easy for your team, they have a clear goal of two people being matched and then a date is set. You can then send this application to a few test subjects and ask for them to then rate how they liked your idea.
As you can see the scope is small, eliminating such things as profiles and pictures make it easier for your development team as well as allowing you to test them not being included as a selling point. When you get enough users to test your concept you can analyse the trend of responses. They might, for instance, say I liked not knowing anything about my date, I liked the blind date aspect but it was to blind, I didn’t always have anything in common. That would mean your next feature would be to add a proper matching system along with a few questions for each person to answer when they sign up.
Once you have gone back and forth a few times you will begin to see your Minimum Viable Product, the product that a user will pay for. This user testing is what reveals the core features that a user will start to pay for. Let the users define the scope and build it for them, its who will pay for your product.
Deliver your MVP
One week/month for each iteration and no longer than 6 months to deliver the product to market. You don’t need designs, you don’t need proper signups you don’t need a payment system you just need the one core features and some people to test it for each iteration. This one core feature should at a bare-bones level take you no longer than a month or two to complete. The shorter the better, the more rapid you make your testing and feature additions the better. After a few rounds of testing and feature additions, you will begin to see what needs to be in your day one public release. What you release to the public will be what you call an MVP, it won’t be the prettiest thing in the world, it probably won’t be the fastest but it will do the main thing you envision it to do.
Delivering to market your MVP shouldn’t take longer than 6 months. The first few rounds of testing will reveal what your users want so that when you go to the market you have something that people will pay for, more importantly, something people will use!
Test your MVP
Getting your idea into peoples hands is the best way to see what works and what doesn’t. Ideally, you should be delivering your MVP in 6 months to the public, but in the meantime, you should be getting a test build-out to a small group of people. These people will tell you what works and what doesn’t, with this information you can then add or remove features. When people start saying “I’d pay for this” you know you have enough features to release. This isn’t time to release you just know that you have the feature set to release.
Each release you do to these small groups, you must ask them several questions. These can be anything from “What do you like about the app?”, “To what did you hate?”, even, “What feature/s would you love to see?” There are many more questions but these are just a sample. You must ask as many questions as possible and analyze the results. You must take the results and change the direction of the next MTP. For instance, if many users want a certain feature, add it and then retest. That one extra feature might turn them from un-paid to paid customers and it might be something extremely simple that you didn’t even think of.
These test phases are critical to getting your product into the market quickly and effectively.
Where to next?
This gets you set up with how you test features with users and how you take the feedback from those tests to properly scope out your MVP.
You should now be a little more familiar with the process of getting your MVP into the market, next up is planning features post-MVP release.