Skip to main content

Good bye MVP, RAT to its invention

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

Popular posts from this blog

The History and Evolution of Product Management

Both new and experienced product managers often ask where this role came from and why it seems to have so much crossover with other roles such as Marketing and UX. While there’s no definitive history of product management, it’s often useful to consider our roots and understand how the role evolved over time. If nothing else it helps to understand the organisational trade-offs that happen as our capabilities and thinking evolve. The History Neil McElroy Modern product management started in 1931 with a memo written by  Neil H. McElroy  at Procter & Gamble. It started as a justification to hire more people (sound familiar to any product managers out there?) but became a cornerstone in modern thinking about brand management and ultimately product management. What he laid out in  his 800 word memo  was a simple and concise description of “Brand Men” and their absolute responsibility for a brand – from tracking sales to managing the product, advertising an...
Post a Comment
Read more

Reasons why Agile Isn’t Working?

Reasons why Agile Isn’t   Working? A couple drawings… I was visiting a relative a couple years ago. My poor cousin (the CEO of a company) had been sold the Agile Silver Bullet ™ and was pissed. He said something like: It’s a sham! We changed the way we do everything. We brought in consultants. We hired these master project managers. And nothing worked! It made no difference. There’s no accountability. All I get is excuses I forget how I responded, but I know how I’d respond today. I’d draw some pictures and not even mention the word Agile. There are a couple core concepts I’d need to communicate to him…. 1. Flow Efficiency First, if we look at lead time — the time from when we dream up an idea, until it reaches customers — you’ll notice that most of the time is spent “waiting”. 15%  flow efficiency  (work time / lead time) is normal. Crazy, right? Yet we focus on what’s (relatively) visible…the small amount of time spent actually doing the job. The...
Post a Comment
Read more