An MVP is a software development technique, first used by the American entrepreneur Eric Ries, that assures a first working version of the product, with all the needed requirements to make it fulfil its main goal. It is valuable for users as it is, and has much room for improvement through a set of features that are not considered for the initial version, but can be implemented in a later stage.
MVP is a concept so widely used, and yet, so hard to get right. An MPV is not a prototype, nor is it a pre-launch version of a product. It's not a beta version of any sorts, and it doesn't precede the real product. In software development, it's also not the most valuable player, which has the same initialism, but it's used in completely different areas.
The main goal of the MVP is to test the market and get feedback for further product improvement. Knowing that the effort to build an MVP is much less than what would be needed to implement all the initially contemplated features, all outcomes are positive, even in worst case scenarios.
If users adopt the product right away at this stage, you'll create a community around it and get room for further improvement with less pressure. At the same time, those same users will be the ones pointing out what they think the product is lacking, providing valuable input for the next round of improvements. You can then plan accordingly and even scratch a few features that were thought before launching the MVP, in some cases.
In the undesirable scenario in which the product isn't adopted, or fails to serve its purpose, it will still provide valuable insight to either adapt or drop the product, according to the gathered feedback. Maybe it was a UI or UX issue or maybe the problem that the product was supposed to solve was misjudged. Additionally, there are also external factors that influence the outcome of a product launch. With so much that can possibly go wrong, there's no reason not to play it safe from the start.
In any of the above cases, building an MVP proves to be the best pick. It can always depend on the available budget and on business goals, but nonetheless, the MVP is not a technique that should only be used for short budgets. Small startups do it as much as big corporations, and it's always more a question of strategy than it is of imposed constraints.
But how does one start to build an MVP?
It all starts with design. Going directly from the idea to implementation with minimum effort on design usually proves to be a very bad idea, regardless of the project nature. It's not as you can just get someone to paint a nice layer on top of the prototype once it's ready and call that the “design”.
When you work with product designers, you’ll understand that they're more like architects than painters. They need support from engineers in order to design, but the most creative part of their job isn't what the product will look like, but rather what it should do and why. And until actual users use the product, everybody's working with assumptions (some might just have more accurate assumptions than others).
With this in mind, we can try to answer the question: should an MVP be fast and easy to put through a reality check? If you have the team capable of delivering it in three days, why do more? If the idea proves to be welcomed by people, then you'll have confidence and full trust to invest in 3 months of effort and cash.
After that, you need money to continue growing to the full product, each time increasing the user base and not just sitting in your office hypothesising. At the same time, the product designer will be able to observe, analyse and interpret the evidence you gather from the reality check to help you invest your time and money wisely.
If you think that it's impossible to test your idea in 3 days, you are wrong. What you need is not a fully functional product, but simply a proof that your idea will drive some interest, which is something that can be achieved with a fraction of what you think your product should do.
Secondly, no matter how genius your idea is, its implementation needs to be preceded and managed by a real product designer. Good design will help you remove the fat of the idea, understand the core of your value proposition and deliver an elegant solution to test it faster.
Remember: more design means less development, and that's usually the focus of the MVP. It's not about stacking features on top of each other, but concentrating the efforts on what really matters to release a working product that'll fulfil a specific goal.
There are many ways to plan an MVP project, but here I'll focus on a specific methodology: Scrum, which is depicted below.
The concept was introduced by Hirotaka Takeuchi and Ikujiro Nonaka in the context of product development in 1986, and it has suffered several mutations in the following decades. Putting it simply, it's a process that aims to deliver small product iterations over time, instead of going through the whole product development in its final version before delivering any value. It is usually related to Agile development practices.
Let's now see how we can adapt it to building an MVP.
The product backlog and the task list, on the left side of the image presented before, represents the various features that you want to implement on your product. Those will be contemplated on several sprints that occur in fixed time frames afterwards. The conclusion of each sprint generates feedback that'll be used as input for the next round, and that'll happen as many times as needed to complete the project plan.
Imagine that the goal of the first sprint is to build an MVP. The product will be shipped as it is, and will get updated following the same process, according to established priorities in the project plan. The main benefit is the regular delivery of value within short time frames, and the chance to respond quickly to change.
Repeating this process will eventually lead to the project's conclusion, with several rounds of feedback in between. This is one the most important characteristics of an MVP. It enables you to have more checkpoints to go back to if anything goes wrong, and at the same time, you'll be rewarding users progressively over time with product improvements based on their needs.
This is just one of many possible routes to build an MVP and work from there, and the one that we take to develop digital products ourselves. It's based on an Agile mindset, in which the aim is to continuously deliver valuable software in increments. Other options are available, but the ideas that support the project will be very similar in every case. It's up to you to pick the one that best suits your needs.
Are you looking forward to build a new product? List your business goals, think about the various strategies that will enable you to get where you want to be and strongly consider taking the MVP route.
The main benefits that come from it are the reduced risk and the feedback gathering, and both will enable you to better plan the following steps. It's not the consequence of having no other option, it's a business strategy by itself, and many successful businesses keep doing it as a way to test the market before going all in.
It all starts in design, as that's the most important step in building an MVP. Product designers will be able to trim the fat and keep the product to its essentials before moving on to development. The project plan doesn't, however, end in the MVP, as that's usually the first step in a much bigger process.
The bottom line is that you can always dream big, but you should start with both feet on the ground. A minimum viable product is a promise of something bigger and better, and dropping the project after its completion would be a mistake as severe as not releasing an MVP at all.
Based on an article originally written by Nicholas Mandelbaum for Imaginary Cloud
Found this article interesting? You might like these ones too!
Content manager, text editor, and presenter of strategic ideas, along with being an avid fan of the cinematic arts and visual storytelling.
People who read this post, also found these interesting:
.png)
