How to build a successful MVP

An MVP shouldn't be just an excuse to launch a shitty product with half-backed features and a bad experience. That has zero chances of success whatsoever in today's market.
Daniel Andor

Before launching an MVP, you should clearly define what you want to learn or validate. What part of your solution is critical for the product / business to exist?

That way, you can figure out what that MVP should be in the end - it's a landing page? a prototype? a part of a product?

If it takes too much time to build - mostly because you go straight to code - and leaves you with no resources or possibilities to iterate fast, you have most probably overdone it. You'll end up in a very sensitive situation, betting everything on one card, with a very high chance of failure; almost like playing the lottery.

So, no - not every MVP is a coded something. Especially when it takes 6 - 12 months to launch it.


Also, keep in mind that there is a general misunderstanding about what an MVP is. Hence the many names — MLP, MMP, Mxx — you name it.

It might sound simple, but in the end, it can be a very costly misunderstanding. Because it's not just about the name — what you call it, it's not even that important. It's about what you do next. In this case, test and validate your critical assumptions about your product.

With this in mind, the MVP is not necessarily a coded product with an overall bad experience, but it can be:

  • a landing page to test your UVP
  • a prototype to test a user flow
  • a video to explain the product
  • the critical part of your product put together in a no-code / low-code tool

I'm a big fan of Marty Cagan's version of MVP - Minimum Viable Prototype - arguing that companies are wasting too much time with developing their MVP.