It might help to think of MVP as just one part of a bigger product development and go-to-market strategy. Consider it this way. If:
1) you begin with the end in mind,
2) you have a solid business model,
3) you have a product vision that isn't tied to really granular, specific feature-functionality that you aren't willing to change even when feedback indicates that something is wrong (I call this "founderitus", or in other words, "Don't let reality get in the way of a good idea"), and
4) you effectively communicate your strategy internally and to investors
Then MVP is often a wise approach.
Here is why: If you focus too much on the "V" in MVP, you might conclude that you product has to be viable upon your first release; which means the inherent challenge in is knowing exactly what will satisfy potential customers enough to continue using your product beyond their first experience. This viewpoint also causes irrational fear and consternation about whether or not you will make the right decisions for V1.
But you shouldn't worry too much. MVP isn't really a business goal specifically related to the first release of a product, but rather a philosophy regarding the incremental release of the fewest features necessary to drive adoption, decrease attrition, and get feedback for improvement at every release of a product. The point I am making is that if you do a great job of communicating your solid business model and product vision to your team, it doesn't mean the end of the world if you launch a very "skinny", inexpensive product and it fails to generate the traction you ultimately want to achieve. Rather, it usually means that you need to get some customer feedback, make some tweaks (sometimes major changes which you want to catch early), and continue releasing enhancements that are increasingly more relevant to the needs and requests of real customers.
The alternative is waiting longer to launch, making poor decisions about the core features of your application (the features that you just "know" customers will love), and then developing rich feature-functionality around those poor choices. Then when you finally launch and find out that you missed the mark you have no funding/runway left, no traction, no customers have a vested interest in seeing you succeed, and a product that is so "developed" that it is impractical to take a step back and rethink your approach.
By launching early and releasing often you will always be developing against real customer feedback, enhancing what's working and nixing what isn't, and you will be forced to deal with major systemic changes as early as possible.
If you are concerned about competition, failing spectacularly and getting a bad image early on, or something along these lines, try to keep in mind that MVP doesn't have to mean "publicly viable product". Focus on getting a small group of early private beta testers together, write to them often, don't abuse their generosity, thank them for their feedback, and eventually begin opening up the product to others. If you’d like some support, here is a link to a study that concluded that "The best results come from testing no more than 5 users and running as many small tests as you can afford." Show this study to your investors, then focus on getting 5 relevant users to participate in early testing.
I think MVP is common sense, the study supports MVP and the "release early, release often" philosophy, and I hope you see the wisdom in it as well.
Best of luck with your venture!