MVP is not an excuse to make shitty software
We work with a lot of startups—companies who are anxious to get their great idea built and delivered to the world. One of the biggest challenges startup entrepreneurs face is figuring out exactly what to build and when. Startups don’t have endless capital, like larger corporations, and they can’t explore every idea or build their complete vision into version 1. No, the startup entrepreneur has to take this dream she’s been dreaming and immediately pare it down to be in line with her bankroll.
This is hard. Really hard. And it seems like more often than not, it doesn’t happen the right way. You can pare down your app by delivering 100% of your feature set, shittily, or you can pare down your app by delivering 50% of your feature set, really really well.
My concern is that in our industry, a lot of people feel that doing things the right way just doesn’t matter as much when you’re building a Minimum Viable Product (MVP). I’ve heard too many people excuse the sad state of a feature because “it’s good enough for an MVP”. We’re putting too much focus on the ‘M’ and not enough of the ‘V’.
If you’re an established company with millions of users, you can afford to put out a new feature that’s only 80% complete. You’ve already got those users. They’re not likely to up and leave your service just because this new feature doesn’t work as smoothly as it should. If you’re a brand new company that doesn’t have any public trust, though, the second a user starts to hit the smallest barrier, she’ll up and leave your app faster than you can say “command-w”.
Don’t get me wrong,we’re huge proponents of agile and lean, but, to us, that doesn’t mean cutting out quality! Instead, we work with our clients to identify the minimum feature-set required to deliver on the core value the application is to provide and then, using our proven process, we develop those features until they’re perfect.
Would it be nicer to have feature X? Sure, but if it isn’t required to perform the core value, it’s off the list. That’s what future iterations are for.
As developers, I think it’s our duty to our clients and our industry to help entrepreneurs choose about which features are key and which ones can wait. This means pushing back and saying “no” sometimes. And once we’ve helped them make those difficult choices, then it’s our job to build the hell out of the remaining features to give our clients the best chance at breaking into their niches. If we can all agree to spend as much as the ‘V’ as on the ‘M’, magic can and will happen.