Sweating the Small stuff and Creating an MVP

http://www.fastcompany.com/1798504/to-create-something-exceptional-do-sweat-the-small-stuff In this article, Box's CEO states that perfection is everything in a startup. Does this contradict the idea of releasing an MVP as soon as possible? Why or why not?

I think Getting Real would have similar advice. The important thing is to not try and release a product that does everything. Release early, but what you release should work well and be very polished. Don't release a piece of crap, or something that looks terrible, or has a bad user interface. It's imperative that what you release be quality. But get something, even if limited in features out early.

There is no one answer that is right for all cases, so the question shouldn't be "does MVP contradict sweating the small stuff" but "in my specific situation, what is more important: releasing fast to get feedback or delay release to add more polish"?

The first question is: can you afford polish? It's easy to point to Apple's iPhone or Box and say "they polished and it worked for them hence you should polish". You don't have the Apple's resources (engineers, interface designers, cash for funding long dev cycle). If you have 3 engineers that are already overworked just building features, you might not be able to afford polish.

Then there are different markets.

For example, an iPhone app is usually shallow in features and hence relatively quick to write. You better polish the max out of those features or else you'll be slammed with bad reviews that will scare away future users.

If you're working on a web service or desktop mac or windows app that is deep in features and it would take you 5 years to implement all of the features and add all the polish you want, there is a different dynamic. You can't possibly fund 5 years of development and even if you could, you have a huge risk of misreading the needs of users and developing a very polished, feature-full app that doesn't meet the needs of users and hence doesn't sell.

In those cases you have to release before you implement your full vision for your product, the only question is how early.

Also, the web has less memory than an app store. If you're just starting and have a product, only few people will know about you anyway. You can take advantage of that by releasing less than perfect product and use early users to learn and improve the product in ways that matter to users. People who find your company a year from know will only see the latest version, not the much worse version you had year before.

MVPs are also much less risky. If desired functionality is there but no polish, people will use your app anyway and tell you how to improve it. If you have highly polished undesirable app, people won't use it. If you get the traction, you know you should double-down. If you don't have the traction, no amount of polish will help. It's preferable to find out in which category your app falls before you spend too much time and money building it.

Personally I strongly believe in logic of MVP. That doesn't mean I'm against polish: if you have enough resources and willingness to take risk, polish away, it can only help.

The thing is: in real life you don't have infinite time and resources and have to make tough choices. If I were making a choice between releasing feature-full but unpolished app today or polished app 6 months from today, I would probably release today. I believe that in early days features beat polish.