The Real MVP - What Happened Next
A few weeks ago we decided to challenge ourselves to take the MVP model to the extreme: we were going to validate a whole business in just 48 hours. That’s build the MVP, test it, market it and analyse it, in two days. Our experiment wanted to see what innovation would spawn from the petri dish of time pressure, while proving that people are straying too far from the pure and simple light of the Minimum Viable Product.
We said we’d report back once we’d done it, share our findings and see what we could learn from the experience. Here it is in two parts: what happened, and how we can do better.
Before we could code a node or sketch a wireframe, we needed to do the one thing you cannot simplify, the one thing you cannot minimise: talking to people.
Without talking to potential customers, we could not evolve our hypothesis for our business idea. Of course we’d allowed time in our 48 hours to conduct customer development, but such was the nature of our particular business idea that the conversations could not help us move forward. Instead of focusing on the real challenge of building a product, we got stuck in research, going round in circles, asking more people more questions.
It reminded me of this saying by Twitter founder, Evan Williams:
“You know that old saw about a plane flying from California to Hawaii being off course 99% of the time—but constantly correcting? The same is true of successful startups—except they may start out heading toward Alaska.”
Well, we realised we were heading to Alaska by the end of the 48 hours, but it was too late, we’d run out of time.
The good news is that we can and will continue to develop that idea now we’ve got two days of juicy data to use. We’re still going to try the 48 hour business validation project again, with a more defined hypothesis better suited to an ultra-quick validation.
The difficulties of finding the right direction for the MVP got me thinking: when do we know if we have enough information to make a decision to move forwards? When does one stop researching, and start building?
It’s not easy to know when one has enough data to make a definitive decision, or to know what to decide with inconclusive data results. Barack Obama sent in the SEALs when there was just a 50% chance Bin Laden was in a compound in Pakistan, Elon Musk started an underground tunnelling company while sat in a traffic jam.
Excellent decisiveness there Elon.
…So my question is: to make a Minimum Viable Product, is there a “Minimum Viable Data”?
What is the least amount of data needed before one can reasonably take a decision? Well, I did some mining of my own, and found a few tips to help us get better at knowing when to take a decision during a hackathon, and when to keep digging for data.
A bit of light reading: the brief but seminal The Mom Test by Rob Fitz. Not only does this book give wonderful advice for conducting customer development interviews, it also gives nuggets of advice for knowing when you can stop talking to random strangers, and go back to coding in your underpants.
Speed over success: Jeff Bezos is just one example of an entrepreneur who prefers to make quick decisions over good decisions. Officially, Amazon workers employees are expected to make decisions based off of 70% of the information they need, not 100%.
The missing 30% of data means that someone in the team will always inevitably disagree with the inherently incomplete decision but they agree to disagree, commit and crack on, because the high velocity is proven to give more benefits than the mistakes cause setbacks. So, if you make a decision based off little data which turned out to be a disaster, you can at least console yourself that Bezos would have done the same thing.
And Theresa May too, so you’re in great company.
Cool prioritisation: ICE. ICE is a popular acronym used for deciding what to prioritise, it stands for Impact, Cost, Effort. So, when you’re faced with inconclusive data which gives you many different potential directions to develop a product in, you can ask yourself which development gives you the most impact with the least cost and effort, relative to the others.
The riskiest lean: And last but not least, we need to go back to the The Lean Startup basics: when faced with incomplete or inconclusive customer data which gives you more questions than answers, remember that the MVP is not used to test your idea for a business, or even to test your idea of the customer problem your business is going to solve, it is to test your idea of what the riskiest assumption for your business idea is.
Therefore, the “MVD” you get from your MVP depends on the assumption, not the whole business idea. Airbnb’s riskiest assumption was assuming strangers would stay in other people’s houses, so they tested that only. The “MVD” they got was enough to inform them that strangers would indeed sleep in someone’s house, and nothing more. It was then an easy decision to move forwards because they’d only set themselves one question to answer, even when the whole entrepreneurial idea begged thousands. They avoided Paralysis By Decision Overload.
But Beware Decision Fatigue: It’s a real thing. Obama went from dreary dad to stylish DILF after his presidency, because he finally spent time deciding what to wear. He previously refused to make small decisions like clothing and food, because he needed his decision stamina for more important stuff, like saving the free world. You are definitely as powerful and important as Obama so take a leaf out of his book.
We’ve got some more hackathon news coming up over the next couple of weeks, we’ve been building demos and testing more assumptions, and we’ll be tweeting them when they come out - follow us right here to see them.