This means feature set not quality.
Stop using MVP as an excuse for your poor quality software. If you didn't have time to polish the features maybe it wasn't minimal enough!
.
(Note: This is all based on my meandering experience. Take it with a grain of salt.)
For me, a MVP tackles a single sub-problem of your targeted userbase and execute the heck out of it. This should be a gem of a small solution you create that is beautiful, usable, and magnificent.
Your goal is to get those initial users to feel that heady emotion (Wonderful word: "frisson"), that sends chills down their backs when they realize what you have created.
.
Not taking advantage of graphic design is stupid. Remember, when users see that MVP, they don't consciously think, "ok, this site does X, but it has a graphic design quality of Y, but I don't care". They take in the MVP as a whole and they put it through their binary evaluator.
You need to take advantage of everything at your disposal to make sure that evaluator lands on the right side. To do anything less would be doing yourself a disservice.
You don't want to be sitting a few days after sending out the MVP and wondering if people aren't converting because it looks crappy or because its useless.
(A big caveat is if you don't have a designer on your team. At this stage, it is time consuming (and expensive) to hire freelancer designers to render the vision you have in your head. I would try to make do. I come from the school of thought that having a designer cofounder is essential, and better yet, you have a designeer on your founding team.)
.
Remember, all I am talking about is just one small aspect of the bigger problem you are trying to solve. The bet here is that with your identified subproblem, the costs for producing it will be relatively low (at least compared to the overarching problem you are solving).
.
It is easier for people to see a tiny, tiny bit of something absolutely wonderful and imagine a lot more of it than it is to see something crappy and imagine something beautiful.
.
What ends up happening is:
1. Potential users try out the MVP and appreciate its straight up utility.
2. Potential users see the quality and craftsmanship of the tool (even though its tiny) and you start gaining a fanbase. These users expect more wonder from you.
3. It becomes very natural for you to grow out your userbase along with your feature set.
4. You tackle more subproblems with the same amount of polish and voracity and in the end you get a wonderful product with a huge fanbase.
.
jiggity's personal mvp pathway to new products
Research -> Identification of one pressing subproblem -> Build the heck out of a solution to that subproblem -> Polish, make it beautiful, put in emotive triggers -> MVP release -> Userbase reacts with astonishment -> Identify pressing subproblem #2 -> Built solution for that subproblem -> Polish -> Release -> Use fanbase from earlier iteration to grow much faster -> Repeat
If the purpose of the application is met, but the app is otherwise ugly, hard to use or what have you, then you have an MVP.
The point of an MVP, generally, is to determine whether or not there's a market for your application, and whether it actually fills a need.
If you can put out an ugly, half-working application that saves me real, tangible money, then I'm probably going to use it. If there's better-looking or more highly regarded software in the same space, you're out of luck, and shouldn't be launching an MVP... the market's been proven by the competitor. But if it's a new space, in an unproven market, that solves a real problem, then yes, I will accept an app that hasn't "had time to polish the features", so long as the one core feature that I'm using it for works.
I've seen people use MVPs as a fund-raising tool too, while making their pitch to potential investors.