[heurisko]

MVPs hurt when you cut corners (don't write tests) and mock functionality, then show the result to the business.

Because often, they will like what they see and want to go full steam ahead, by which time it's too late to explain you actually need another couple of months to get to the position they thought you were already at.

[kaashif]

An MVP is supposed to actually work (be viable) and be something that you can actually put in front of users to test your business hypothesis.

If you present a demo where all functionality is mocked as an "MVP" to business and they think it really is an MVP, that is a reasonable assumption in my view. If it turns out it's not viable at all, can't be sold as a product to anyone, and doesn't actually work, that seems like you misused the term "MVP".

They want to go full steam ahead because at best there's been a miscommunication about the term "MVP". At worst they'll think you were lying to them.

It's really important to have clear communication and definitions of "accepted" terms which are sometimes used inaccurately.

[is0tope]

That's the distinction between an MVP and a Prototype. While it can be useful to put together a hack and slash version, it needs to be marketed as such. Shameless plug, but I wrote about this exact thing: https://www.machow.ski/posts/galls-law-and-prototype-driven-...

[Ensorceled]

> An MVP is supposed to actually work (be viable) and be something that you can actually put in front of users to test your business hypothesis.

Agreed, few of the comments in this thread seem to be throwing the 'V' of the MVP out the window.

It's not another word for a mock up or a proof of concept, and when did it start being a "process" instead of a "thing"?

[notahacker]

They can also hurt the other way when the business is sold on the concept, but the MVP implementation is a lot less impressive than the concept.