DEV Community


Minimum Viable Product (MVP)

al_karlssen profile image Al Karlssen ・3 min read

A special form of the Lean method for startup is called " MVP - Minimum Viable Product ". MVPs should help founders, product managers and growth hackers not to develop products that no-one needs in retrospect.

How to develop a real MVP

Of course, again with the earliest possible market entry with the aim of getting real market feedback as quickly as possible. However, as an extension of the Lean methodology , MVP not only validates the startup
, but directly a working mini version of the product. Properly done, then the product can be extended on the basis of user feedback with always new functionalities and features.
Initial development times can thus be significantly shortened. However, the analysis effort increases. Is there a market for my product? What features do customers really need ? Which features are the most important after the MVP? A few MVP examples.

The big challenge of the product developers is to define in advance exactly which functionalities are really necessary for the user to generate enough benefits. It must not be too low a benefit, because then the user is probably lost immediately and above all forever.

A few examples of MVP features that are frequently discussed in product teams . Features that are often omitted in the first MVP because they do not ad hoc affect the user experience:

  • "Reset Password"
  • Payment function
  • Legally secure data protection and GTC texts
  • Automatic tests of the source code
  • Highly scalable staging environment
  • No "nice" design
  • Long loading times

Functionalities that, from my own experience, should always be included in the MVP:

  • Very good and easy usability
  • Ability to submit user feedbacks
  • Imprint

"If you are not embarrassed by the first version of your product, you've launched too late." Reid Hoffmann - Co-Founder of Linkedin

Tight schedules often stress the implementation of a good MVP, so that later the user is offered a not yet finished version instead of a very well working version 1.0 of the product. The product can not be finished, but the user must never notice this, especially not in the user experience. And please do not forget that especially the loading time of the application belongs to the user experience.

A phenomenon that can happen more often, especially in companies with multiple products. Assumption: The market is moving rapidly and the competition has presented a good feature. The product developers must therefore follow suit to equalize the lead of the competition as quickly as possible. The MVP is defined, implemented at record speed and put on the market. The sales department is congratulated and sent on the journey with the sale of the MVP. The work of the product developers seems to be done and you start directly with the next project or even the next MVP. From the perspective of sales people everything is optimal. They got their feature and win the sales pitches again. Everything so far, so good, or not?
No. This development is fatal for a company in the medium to long term, as it completely neglects the validation of the MVP at the customer. For a company, the worst case scenario is that it has many features and products only in the MVP status in the product portfolio, but none of them really impressed users. In the long term, users will not be satisfied with "unfinished" or "non-mature" products. At least not if the competition has only one product on the market, which is much better than the MVP version of this product.
For this reason, there is today the theory of the MLP - ie the minimum Loveable Products . This should certainly, that one does not just a small prototype on the market, which is then not further developed, but the core requirement that the users already like the product or might even love a little bit.

Discussion (1)

Editor guide