It is a compelling concept for any product team: Work fast, get something out that works, see how people like it, then adapt. It is particularly appealing for new businesses or simply new products when there is no way to know for sure what prospective users will really like - or even IF they will like it.
It can even seem appealing for more mature organizations with less of an investment and time crunch because of the opportunity to accomplish something and get 'points on the board'.
It sounds great: You get to minimize risked time and capital, shorten time to market, and get users on board for word of mouth and other benefits.
So, what's are the problems? They generally come from poor application of the methodology or plain old laziness.
1) It does not meet the "Viable" part of the concept. Even getting an MVP product out the door requires some analysis on a coherent set of features that provide value to an intended user. If it is only a collection of technology proof points, users won't value it, it won't get used and the concept fails
2) It is often an excuse for not doing proper architecture work. This is actually acceptable in the MVP model. But it requires the discipline to plan to correct it later. Otherwise it ends up generating deep 'technical debt' from the beginning.
3) It is used to simply avoid doing the hard work of research, planning and decisions to place a solid bet. Frankly, this can be acceptable in the interest of speed, but the team has to be honest.
A colleague shared this link on this topic with me today. I really like the concept of "Early" product. He suggests that one should think of it as delivering the Earliest Testable Product, to be followed by the Earliest Usable Product and so on. This better maps expectations between developers and users and focuses on the idea of delivering something useful from which to get feedback