“What we need is an MVP” declares the fresh-faced entrepreneur. “Let’s just build the product fast, bootstrap the business and get it going really quickly.” A minimum viable product (MVP) – something that allows you to get the product out there, launch the app, market the product and raise even more money, is often seen as the Holy Grail in Silicon Valley. It’s practically a technology fashion statement. It’s a deliberately basic product, often a beta, to give a little teaser to the backers, staff, and entrepreneurs dreaming up the idea. “It’s no problem if it’s not perfect” they’ll say – you can always fix it post launch and worry about any issues at a later date.
People asking for an “MVP” is one of my pet hates. What people are really saying is ‘let’s cut corners’, let’s put a v0.1 product out there, likely to be riddled with bugs and, even worse, put a badly thought-through product out to market. Entrepreneurs are big dreamers, and while I wouldn’t be seen as the boring guy who is stifling their creativity, their desire for a “quick and dirty” fix that gets the product on the way as a quicker route to revenue is likely to cause much bigger problems for their software and indeed their business in the long term. Relying on an MVP at stage one often ignores proper engineering principles and is literally like building your house on sand and hoping it will stay standing in the future.
A poorly-planned MVP can have a number of drawbacks. The product might be good for this week, next week or next month but what if your business takes off in six months’ time? Can your product cope with thousands of sign-ups per second? Everyone in the industry knows of an app or even big brand that has just fallen over with huge traffic from media exposure - what we used to call the Slashdot effect - or a tweet from Stephen Fry. By building an MVP you could engineer a scenario where on your biggest marketing push you effectively lose every customer as they’re pushed to buggy software that collapses at the first sign of significant interest.
This brings us to problem number two. If you just ‘settle’ for an MVP for launch then you’re running the risk of releasing incomplete software that will leave your customers unimpressed, assuming they are still customers at the end of it. Businesses are discerning - implementing any new piece of software for a business with more than a handful of staff is a real hassle, not worth the cost or bother if the product doesn’t work first time. Consumers have even smaller attention spans - a dodgy app, an arduous sign-up process or badly designed, confusing, interface and you’ve lost them on day one. Chances are, they’ll even publicise their frustrations on social media. In the heavily regulated retail or banking industries, putting a foot wrong could have legal consequences. Is going down the MVP route really worth that risk?
Often one of the biggest issues we see with MVPs is security. Without implementing best practice around security from the start, you risk leaving backdoors open, ready for hackers of every sort. Facebook is guilty of spreading this culture. The social media giant’s “move fast and break things” mantra led it to release updates to two billion users globally without enough thought and planning, including the historically awkward Cambridge Analytica scandal.. In short, releasing products before they are ready could lead to a question mark over your product, legal and regulatory ramifications and, in Facebook’s case, an accusation of undermining western democracy as we know it.
You hope in the future that if the product is a success then you can go back and fix the problems, keeping all your users and without compromising their data. But there are no guarantees. We’re often tasked by clients to solve problems and issues with an MVP after it’s been launched, fixing the issues with the first version of the product that was designed and developed too hastily at the outset.
How do you avoid the MVP scenario? Here are five tips to avoid falling into the trap:
1) Ask “What if” - it all comes down to planning for exceptional, or even normal, scenarios. What if all of a sudden 10,000 people click the same link at the same time? Twitter was guilty of this in the early days with a hugely buggy product. The Fail Whale was a familiar sight as the service fell over with almost clockwork regularity.
2) Invest early on - MVP can be code for ‘we want it cheap’. But it will cost you more in the long run to unpick early mistakes from under-investment in your systems.
3) Think through the product together - discuss the product with your developers carefully, looking at how it should work. Thank of it as like building your home, making sure that all the appliances and services are in the right place.
4) Don’t rush - it’s not about saying to your boss or investor ‘look, we delivered on time’, it’s about the balancing act of having the right product at the right time.
5) Constant dialogue - founders need to have a continuous conversation with their developer. Don’t undervalue the advice of your engineers.
“What’s the worst that could happen” you may ask? Well, your product could fail for whatever reason – there is reputational risk around a PR disaster following breaches of information, regulatory failure or public fines. Alternatively, you might just turn off your customers completely.
But if you do fail, what then? There’s another piece of Silicon Valley jargon which is a pet hate of mine… you might as well take your failed business and ‘pivot’ it in to something else!
Andrew Elia, CEO, Arishi