MVP is the short term for Minimum Viable Product. It describes a very simple product that’s still feasible and covering the fundamental components. In practice, an MVP is a version of a new product, service, or business idea that’s less comprehensive than the final product, yet fit to attract early-adopters.
Because of their shorter development time MVPs give early feedback and thus are optimal to test product and business ideas.
The development of the Minimum Viable Product is strongly tied to the Lean-Startup-Method by Eric Ries. The central concept of this method suggests you launch your product as fast as you can.
Following MVPs and a lean approach basically have the same goal: being fast and keeping it simple.
MVP development is also closely related to the Agile methodology. Since the agile methodology works by validating and iterating products based on user input, MVPs play an important role in Agile development.
A product with just enough valuable features to be functional to users, plus it will minimize the time and resources a company uses to build its product. MVPs also help facilitate the development process for software engineers.
It’s a simple equation: because it’s simple and minimum it allows for speed and low expenses.
Yet low costs and less development time are not the only advantages of MVPs. They also diminish the risk of failure and capital loss.
You want to start an online shop for custom-made bikes. You work months and months on the website and spend a considerable portion of your seed capital. When the website finally goes live, you get almost no sales.
During this whole process, you relied on your assumptions that there would be sufficient demand for your custom-made bikes, but you failed to actually test that assumption.
What if you had launched the website much earlier? With fewer features and fewer products? User feedback would have told you if customers are actually willing to buy your bikes and which of your assumptions were true.
Companies have to be willing to be flexible during the development process as new findings might change features of the product, or in the most radical case the product altogether. In that case, the MVP still saves you valuable resources that you otherwise would have spent on a final product that wasn’t going to work anyway.
The development phase consists of a constant trial and error cycle. Each new cycle you build new features and adaptions. And the feedback data that you get from that cycle allows you to learn what works and what doesn’t. In the next cycle, the development team applies these findings to improve the product step by step.
MVP is the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least amount of effort
Not the MVP itself is what will be valuable for a company, but much more the feedback and the data that you get out of it.
After each feedback cycle, the learnings are implemented. Features that passed the test can stay, features that failed to attract the user’s sympathy have to be dismissed.
MVPs are not prototypes! Although they both are a lightweight early-version of the product they differ in the level of commitment and their audiences. While prototypes are mostly intended for internal review the whole point of an MVP is to launch it to potential customers.
Also, a prototype is usually part of a process of trying multiple ideas thus you are less committed to it. An MVP on the other hand you’re much more invested in.
That confusion with prototypes also plays into another misconception about Minimum Viable Products. Not only customers but even software developers often misinterpret MVPs as being “lacking” or “incomplete”.
This might be the case for poorly realized projects, but if done correctly the customer shouldn’t feel like something is missing about their MVP. In fact, MVPs are to be understood as a fundament that is viable and functional on its own, and that you can add on later, step by step.
Maybe the biggest challenge of building a minimal yet viable software product is to always keep the balance between the two. As some have criticized MVPs “to be too M and almost never V” the task is to offer the customers added value through a Minimal Product.
The riskiest aspect of startups is whether customers will want to use your product and also pay for it.
Does my idea really work? Will users like my idea? Are users willing to pay money for the product? Which features should I include? What are the customers’ needs?
These are questions the MVP has answers to.
Before you even think about the design and architecture of your MVP, you have to start with identifying the purpose of your product.
Each new product has to solve a specific problem or at least offer an improvement to existing options. Without a solution for a certain problem, you don’t have any value to offer to your clients.
You should structure the solutions that you come up with in the form of user stories, epics, or features. This overview will be important as you can only include a fraction of functionality in your first MVP.
Make a list of all the features. You can categorize them into must-haves, should-haves, could-haves, and wont-haves. This tells you which features have to be included from the first minute on and which to add later.
To decide which exact part of the functionality you want to develop, you can consult the following aspects