I agree with this to an extent, but I also think there's always room to cut features. When I launched my MVP (after the usual no-product-yet-but-sign-up-for-this-mailing-list stage), the feature set was pretty barebones, there was no admin dashboard (it's an API product) and because it was so limited I quickly discovered pain-points that were causing users to drop off, namely not having an admin dashboard. I would of never known that if I just plowed ahead and built everything.

So sure, you can't really get away with an ugly "MVP" that's missing your core feature-set (and I'd argue you couldn't really get away with that in the first place) but you can cut features until you have something barebones that you can start getting in front of users.

Yep. True MVPs only work if you are solving a problem with no other effective competitor.

So it's either your MVP (to solve their problem) or nothing.

That's extremely rare.

If you are making "a better ___". Some basic ugly MVP is not going to get you far.

People will just be like "Ok we'll use one of these 10 other competitors until your product catches up to them".

And yes, I know you will differentiate in some aspects, but a lot of solutions are nearly useless until they cover a large critical set of features. If you implement 5 differentiating features but you lack a polished UI/UX and 100 other "basic" features that other established competitors have, you can't win anyone over because of the differentiation alone.

I think some of the challenges to keeping MVPs really MVPs is that the users being presented with an MVP often can't see past its bare bones nature.

If it's not pretty or the UX isn't as good as other apps they have used then that's all they get hung up on. On the other hand, you can't really expect an end user to find something useful unless they can actually use it with some level of comfort. I think that's where the more and move polished MVPs surface.

Very much so - I'm stuck on the periphery (operating the environments the system touches for data) an endless MVP...1.5 years when the initial sprint was 6 months. Management keeps adding more features before wanting to release it to a test group yet keep calling it an MVP. New teams are being brought in and have to be retained. New management is brought in each time with more ideas of what is "minimal". Yet they keep throwing money at it...

That's what I was wondering too.

But also: how many people found really, really crappy MVPs to actually work and make sense. e.g.: not scare users.