A voiceover of this article is available here
Minimum viable product (MVP) is a term that gets thrown around a lot in the world of app development, especially where startups are concerned. Hopefully the name itself helps understand what it is and why it’s needed, but let’s take a look at those questions in a little more detail so that we can fully understand the role of the MVP in the development process.
What is an MVP?
You’ve had a great concept for an app, perhaps you’ve found your core team or even got some investment. What you don’t have yet is something to actually sell. Your vision is big and includes a lot of features, but developing it will cost a lot of money and time and it’s not 100% certain that it will catch on the way you envision.
What you need to do is build a version of your app which includes only the absolutely essential functions. Once you’ve got this minimal version made, you put it out on the market and get key feedback and insight into whether it’s marketable and what features or changes to prioritise as you develop further. This bare bones app will help you and your investors understand (and even more importantly test) the true potential of your idea.
This then is an MVP. It has two defining factors:
- Minimum – Nothing is included that’s not essential. This is how you ensure you get your most important feedback for the smallest possible investment.
- Viable Product – Your MVP is not a model, it’s an actual product and it must be operational, sellable and usable. You might choose to sell your MVP at a reduced rate or even give it away free to get hold of the vital info. you need to create the polished version of your product. Even so, the MVP must provide value to your users.
Minimum viable product case study
Let me give you a quick example of what an MVP might look like:
Let’s suppose that you want to build an application which amalgamates all of the different messaging platforms. It’s aim is to give users one portal for checking messages from a wide range of sources so they don’t need to check them individually. Your vision is for a global product that works with any social network at all and has hundreds of features.
Creating the integrations (including UI) to handle all of the possible messenger apps is a big task. For your MVP however, you would research which messenger services are the most popular (probably within a specific geographical target area) and then develop integrations for just the top 2 or 3 services. Given that that’s the core function of the app, the majority of those 100 features you’ve got planned are probably “nice to have” rather than “must have”, so they should not be included just yet.
By releasing this cut down, simplified version of your overall vision you can begin to test the market. If the MVP proves popular with your target audience, you can then develop further on the basis of actual user data and feedback.
How long does it take to make an MVP?
How long it takes to make an MVP is very much dependent on the project. The main variables would be the complexity of the MVP and the context of it’s creation. When these factors are taken into account MVP estimates could range from 200 to 2000 or even 20,000 hours.
Complexity – Sometimes (as with the example above) a complex app idea can be simplified a lot for the MVP. With other ideas, a high level of complexity is integral to the app’s core function and needs to be included in the MVP. This will obviously require more work to create.
Context – A completely new startup, bootstrapping their way forward, needs to get their hat in the ring as quickly as possible and not worry too much about a few rough edges in their initial MVP. For an established brand on the other hand, part of the MVP’s viability is that it protects and develops the brand’s reputation. So they may choose to invest in more extensive closed beta testing to get initial feedback and create a slightly more polished MVP before they go public. This again requires more work hours.
Note that even the biggest of brands still require an MVP for a new product – they can’t be certain of a product’s success before it hits the market, so they’ll release their initial, basic version and then tweak and improve it from there. Investing a lot of money to create the full version of an unproven app is a risk no rational business takes on.
Which technologies are needed to build an MVP?
There aren’t any technologies specific to MVP’s. The technology used in your MVP will be the same as that used in your product in general. This in turn will depend on the nature of the product you’re planning to build and likely on the specialisation and experience of the vendor you choose. Typically you’d expect the development company you’re talking to to help you identify which technologies best fit your specific brief.
Managing user expectations
Releasing an app with the bare minimum of functionality doesn’t mean that it’s ok for it to have bugs. The included features should work fully as intended. What it might mean is that you don’t spend so much money and effort on adding “nice-to-have” things. As your main focus at this stage is to build out the core technology and main functionality, and give it to the public to test.
When you do make it available, make sure you manage the expectations of your users. They should understand going in that this isn’t the final product. Call it an MVP, a working prototype, version 0.5, a public beta or any other language you feel appropriate to indicate that this is not it’s final form. Not only does this help your users to have appropriate expectations when they download your app, it also sets the stage for you to ask them questions about their experience. You don’t need to hide the fact that this is an MVP. Users are used to this process. Many of them seek out the hottest new apps all the time, and they’re familiar with the practice of testing a product, sending feedback and then seeing how their experience helps form the app’s ongoing development.