Why you should focus on _Riskiest Assumption Tests_ and forget about MVPs.
--------------------------------------------------------------------------

![](https://hackernoon.com/hn-images/1*akUKwxc1SnxCEuqBzwK3Fg.png)

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](https://hackernoon.com/tagged/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 _Valuable_ Products 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.

![](https://hackernoon.com/hn-images/1*EV_k2NDgArANOf3kwjHIuA.png)

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](https://hackernoon.com/tagged/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](https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi2hfG4rKvPAhWCWhoKHRyLBw0QFggcMAA&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2F5_Whys&usg=AFQjCNHk-Yyc9qUqyNM4U3eaQoENhzDN_A&sig2=tPvIBgLHA2qyUXs_dJy8Zw&bvm=bv.133700528,d.d2s). 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?”

#### Want to improve your A/B tests?

_Check out my new site:_ [**_ExperimentationHub.com/A-B-Sensei.html_**](http://experimentationhub.com/a-b-sensei.html)_Everything you need to know about A/B Testing and hypothesis driven experimentation!_ 👩‍🔬🎯 _And all for free_ 😀

[![](https://hackernoon.com/hn-images/1*aU2v-UGUSbp7duaQC-IMDQ.png)](http://experimentationhub.com/a-b-sensei.html)

[ExperimentationHub.com/A-B-Sensei.html](http://experimentationhub.com/a-b-sensei.html)

The MVP is dead. Long live the RAT.

Too Long; Didn't Read

Companies Mentioned

@rikhigham

RELATED STORIES