Why do it twice when you can get it right the first time? Founders ask themselves this a lot. You have a fantastic idea, an airtight spec, and, as any start-up, a very limited runway. So why bother with an MVP and then spend precious weeks on refactoring it, if you could just skip all the duct tape and go for the real thing. But look at it from a different angle. Think of an MVP not in terms of functionality or infrastructure, but as a way to mitigate risk.
Start-ups are, by definition, incredibly risky. The industry mantra says the most important task at every start-up is not dying. The combination of limited resources, novel ideas, and pressure for very fast growth in a very short period of time means that any potential risks could derail your business overnight. That’s where the MVP (Minimum Viable Product) comes in. To eliminate the biggest risk in the early stage of your business.
Mind you, risk comes in many shapes and flavours and so do MVPs. It’s your job to figure out the riskiest threat and to focus on it relentlessly until you have found a viable solution. It can be part of your product, or your go-to-market strategy, or even depend on external factors. One common scenario for start-ups is targeting a market that just emerged. The strategy is to capture as much of this new opportunity, as quickly as possible. The biggest question mark - your main risk factor - is whether you can make it on time. You’re in a race. You need to get the few key things about the core product right and put it in the customer's hands. There is no point tinkering precious time away to improve usability by 3% or find the perfect shade of green for the sign-up button. And yes, it is important to deliver a delightful user experience. But that’s not your biggest threat. In fact, it’s just a distraction from your biggest threat - being too late.
If you look back at Foursquare, for example, being early was pretty much their only defining feature. The first version of Foursquare that launched in 2009 was basically a check-in app adorned with goofy badges. That was it. A slew of clones launched shortly after, but none of them repeated Foursquare’s success in its category. Why? Because Foursquare was right on time. Foursquare Founders, Dennis Crowley and Naveen Selvadurai, capitalised on the emerging market for apps at the junction of mobile and social and brought their project to SXSW to show it to thousands of geeks excited to explore any and all new gimmicks.
But perfect timing isn’t always the make or break for your product. In a different scenario, you might be working on a completely new concept or an untested approach to a known problem. It’s perfect in your head but, sadly, that’s not where the customers live. So your main uncertainty is about whether people will understand what you’re selling. To de-risk, you only need to put your concept in front of potential users. It doesn’t have to be hooked up to an API and a database. There are a lot of code-free solutions that allow you to drag & drop customisable elements. It’s a hassle-free way to create crude but fully functional prototypes of apps and websites. And in some cases, you can even get away with your MVP being a sketch on a piece of paper. Whatever works to put your concept in the hands of a pool of users and gauge their response.
Treating an MVP as a way to mitigate risk has other benefits, too. It will cushion you from the impact of mistakes. And let’s not fool ourselves, there will be plenty of those. The most successful Founders are not those who make the fewest mistakes, but those who recover the fastest and learn the most. Launching a start-up is bouncing off from one mistake to another until you reach the mythical product-market fit. Your role is to minimise pain and maximise learnings from the mistakes you’ll inevitably make. Remember, you can only find out if people want your product by letting them try it and listening to what they say. There is no silver bullet. Just a lot of trial and error sprinkled with luck on top. But you have to understand that the main output of each trial is not a product, but knowledge. You want to minimise the pain by spending the least amount of time on building, but still maximise what you learn.
Sometimes, you will learn that you’re not even building the right thing. That’s fine. It sounds like a big deal but it’s just one type of risk Founders face all the time. Business plans change. Products pivot. YouTube started as a dating site, Groupon began as a consumer activist site, and Instagram was a copy of Foursquare called Burbn. The list goes on. But imagine you have this epiphany after you spent three months building a sleek, responsive app and people didn’t know what to do with it. All you got is an A+ for an elaborate coding exercise. But if it was only a rough sketch of your app, you can throw it away, take your notes, and go back to the drawing board. At worst you lost an afternoon and gained a wealth of knowledge. Minimised the pain, maximised the learning.
It may be tempting to try and get it right from the start. After all, code is where one can prove their technical excellence. But don’t let this temptation lead you astray. In the early days, no one cares how elegant is your API or how modern the framework you’re using. More often than not, this beautiful code would need to be scrapped at some point anyway.
Don’t worry about being right from the outset. Be right about what your customers want and identify the biggest risk that can stop you from delivering it to them.
