Thinking about the MVP? RAT could be much better
When an idea for a new product comes along – a mandatory part of any work is to create an MVP, at least according to some. A solution is then created to represent the “minimum” needed, which will be the starting point for further work. Only that with MVP you do not create a product at all. What is more, many people are afraid that MVP may become a product prematurely. It may be that in your processes to create an innovative solution, a better idea is to draw up a RAT (Riskiest assumption test) where you can collect data, learn and implement for the next iteration of your solution work.
There are many problems with MVPs. In my experience, MVP – although it stands for “minimum viable product”, is not about the absolute minimum and it turns out that you can go even “lower” with the features of the solution you are creating by implementing less functionality or simply allocating fewer resources to produce the MVP. What’s more, as I mentioned above – MVP is not a product at all. Actually, many people don’t want it to be a product: we can call it a solution that doesn’t enter the market and doesn’t directly achieve our business goals. MVP therefore, because it is even “abused” no longer means “minimum viable product” and is a victim of the ambition of its creators. Besides, you have to keep in mind that in MVP we really create a lot of code, sometimes we pay too much attention to design. And yet you don’t have to create more than you should – just to perform the Riskiest Assumption Test (RAT). Just enough to do your test, collect data, learn something new from it, and then implement it into your actual work. You can, after all, learn step by step to improve all the time what actually needs improvement. Validating your riskiest assumption will allow you to go further and create your product more harmoniously. The important thing is to do a lot of testing, however quickly. Ask yourself, what can you do to test your riskiest assumption? Think of the smallest possible experiment you can do to achieve this. The RAT is all about this – the key to running a successful RAT is definitely simplicity.
Consider why people who are “lazy” are sometimes appreciated – It’s not that they don’t want to do certain things. They simply value their own time and the time of others, believing that they can accomplish exactly the same thing without devoting particularly large resources to it. This is a very good approach if we think about RATs. In the case of the Riskiest Assumption Test: there are two assumptions. You are to learn as much as possible from your test, but at the same time: Your test should be as minimal as possible. As much learning as possible without putting a lot of resources into it. Actually, as few resources as possible. Did you know that many of the greatest inventions had their prototypes created in just one day? That’s the guiding idea behind the RAT – your experiment should give you as much data as possible, but you need to spend as little time as possible on that experiment.
MVP requires way too much of that time
Because then you have to create a whole product, not a simple experiment. If you want to see if the design of your innovative cell phone meets the tenets of basic ergonomics: (you want to check if the device will lie well in your hand), after all, you will not design an MVP with simple software, all components. After all, you can design a case and 3D print it. Then, after printing it, you pass such a “prototype” to a focus group, which describes whether the device feels good in your hand. If in your test it turned out that something can be done better – you implement it in the next iteration. And you perform such a test again. You can do the same with every other thing in such a device until finally every issue related to this project is fully worked out.
In the Riskiest Assumption Test, the cycle of experiments in the simplest sense looks like this: Build -> Learn -> Measure. The challenge is to build as little as possible in order to learn and measure as much as possible. Imagine how much you would have to build an MVP to achieve exactly what you did in RAT. Definitely too much. Your MVP will not be at all as minimal as you need it to be, and you will lose a lot of time. Of course, the RAT is not as wonderful as it seems: you have to be very disciplined in finding your riskiest assumptions. You have to pick your most important assumptions and… think about what others are behind them – the ones that might be most relevant to your project. Once you are sure of the most riskiest ones – then you can think of the simplest possible experiment you can do with them. That’s what RAT looks like – you can get a lot with a little effort. This is it!
Can the RAT be implemented everywhere?
Of course. Not only start-ups can benefit from it, but this is where such an idea can be most applicable. However, you should know about the fact that not only the smallest ones apply riskiest assumption test. Also big tycoons use this idea – also developed companies. This is a wise approach, because at some point – when everything works out, we start to believe that it will be so every time. That we will succeed this time too, or that we are already “too big to fail”. This is not true – something can always happen that makes us start to lose ground. It can be random situations, and in some cases, the culprits can be us. Imagine you invested a lot of money on an MVP that turned out to be a flop. And what’s worse – you have deadlines. Then it turns out that failed MVP can be a huge burden for you or the beginning of your serious problems. RAT would be much more harmonious for your product and believe it, big companies know it very well. Why waste money mindlessly on something that may turn out to be useless, or from which – even worse – you will learn relatively little?
However, there are slightly different challenges when it comes to large companies. It turns out that in such places you can fall victim to your own perfectionism. The idea of the Riskiest Assumption Test doesn’t mean constantly improving your experiment so that the code in your feature is as good as possible, the designs as cutting edge as possible. Sometimes we find that improving the things we test can be problematic precisely because we used too many resources. Think about it, if you want to test if your product is useful – what use is a perfectly written code, or a beautiful interface? Then it turns out that you wasted your precious resources. Resources are your people’s time and of course – money. Nobody will give them back – if you apply the RAT idea incorrectly, you will also have to write off your investment. You can’t let that happen.
It is worth asking yourself in the spirit of RAT – “is this really the least we can do to get our testing done?”. If the answer is “no” – then you need to find an even simpler way, including in terms of your resources. If you see your people spending too much time on this, or trying to improve this thing unnecessarily – it’s not going in the right direction. Think about why startups have to accept failure. The most common reason for not succeeding in the market is not that they create a consumer-unfriendly product. More often than not, there is simply no need in the market to use them. The second most common reason, which comes up about 1/4 of the time, is lack of further funding to invest or develop the product. Sometimes this is precisely because those resources are spent on an inappropriately long product enhancement – something that would not have happened if the RAT had been implemented as needed. Producing an MVP, after all, also costs money, and if you’ve ever done anything new to the market, you know this very well. Your specialists need to be paid.
The key is to get the RAT right