Why you should focus on Riskiest Assumption Tests and forget about MVPs.
There is a flaw at the heart of the term Minimum Viable Product: it’s not a product. It’s a way of testing whether you’ve found a problem worth solving. A way to reduce risk and quickly test your biggest assumption. Instead of building an MVP identify your Riskiest Assumption and Test it. Replacing your MVP with a RAT will save you a lot of pain.
MVP is used so much it’s lost its original meaning. It’s often mistakenly applied to the first release of a rudimentary product. As a result, the “MVP” ends up much more complex than the quick test it was supposed to be and far too shoddy for a released product.
Worried about a second-rate product, people call for Minimum ValuableProducts or Minimum Lovable Products. This is going in completely the wrong direction, though. Leading you to make larger bets on riskier assumptions. Leaving it later and later to learn anything from real customers.
Minimum Viable Test is sometimes used as an attempt to make smaller iterations before release. This fails to capture two crucial points, though: why and what are you testing? Furthermore “minimum” is ambiguous. When asked how minimal your MVP should be, Eric Ries (author of The Lean Startup) replied:
“Probably much more minimum than you think.”
A Riskiest Assumption Test is explicit. There is no need to build more than what’s required to test your largest unknown. No expectation of perfect code or design. No danger it will prematurely become a product.
An MVP seduces with false reassurances of a clear, linear path to an optimised solution. A Riskiest Assumption Test puts the focus on learning. It is a candle in the darkness that allows us to move forward one step at a time. Once you’ve validated the riskiest assumption you can move on to the next largest one. Gradually building confidence in the viability of your idea.
The key to this is rapid, small tests. What’s the smallest experiment you can do to test your biggest assumption? As Tom Chi, co-founder of Google X, puts it:
“Maximising the rate of learning by minimising the time to try things.”
Not just minimising. Dramatically minimising. Even with complex ideas like Google Glass they built the first prototype in 1 day!
Identifying the underlying assumptions takes a lot of mental energy and discipline. Express the opportunity as a customer problem and work backwards. What has to be true for the opportunity to exist? Now take each of those assumptions and ask what are the main assumptions behind them? Repeat until you’re reached the root assumptions. This is similar to the 5 Whys. Working your way back up from the bottom identify evidence that supports each assumption. You should now have a clear idea of where the critical gaps in your knowledge are. A clear idea of what your Riskiest Assumption Tests need to be.
Every new idea starts with a RAT
This doesn’t just apply to start-ups. It is equally important for established companies. Maybe more so. When you’ve been operating successfully for a number of years you can be lulled into a false sense of security. This leaves you at risk to disruption. At risk from ploughing money and time into building something that nobody wants to use.
Meanwhile your competitors are discovering the market’s jobs to be done. They are building products aligned to what people actually need. They are gradually stealing your customers.
Doing Riskiest Assumption Tests in established companies comes with different challenges. Constraints of a start-up drive the frugal thinking that lends itself so well to RATs. With plentiful resources there appear to be fewer consequences committing to large projects before validating them. Riskiest Assumption Tests require a different mindset. Dedicated engineers, designers and product managers can be their own worst enemy. Their professionalism pulling them towards perfected products. Leading to feature creep and polished code. But if no one needs your product then no one cares if it’s beautiful and has impeccable code quality.
Maximise discovery
Riskiest Assumption Tests prioritise the key tasks required to validate your idea quickly. They remove the temptation of prematurely creating a rudimentary product. But they are not easy. You need to be relentless in your pursuit of them. Vigilant of scope increases. It is the responsibility of the whole team to continuously ask each other:
“Is this the smallest thing we can do to test our riskiest assumption?”
Comments
Post a Comment