Modern PM

Thoughts on minimum viable products and riskiest assumption tests.

Always these misunderstandings

Some of you surely know this drawing by Henrik Kniberg on the subject of minimum viable products. (By the way, Henrik is a software developer for the best-selling video game of all time - Minecraft. Just to make sure we are collecting enough useless knowledge here too.) And in itself, and in theory this MVP is not such a bad idea. But as so often, when our beloved scrum-agility-buzzword-coaches are involved, it is turning into one big misunderstanding at the end. And as so often, there is an alternative that is actually more suitable to produce iterative and incremental products: riskiest assumption tests, short RAT. Those who mainly care about sounding competent should incorporate the term "RAT" as often as possible into their sentences in the near future before it is becoming the next big buzzword and can otherwise stop reading now. All others are going to learn more in the next paragraphs. You are still all aboard? Very nice!

Minimum Viable Product

Before we talk about beautiful shiny new things, we should ensure that we are all on the same level. What is an MVP? I don't want to be a smartass (pardon my French!) here, but I have seen teams dashing against exactly this question because no one has thought about the literal meaning of the phrase. The MVP is the "minimal survivable product". The idea behind it is quickly explained. The phrase was coined in 2001 by Frank Robinson, who, inspired by the bursting dot-com bubble shortly before and based on the Sharp Ratio - simplified, a return-on-risk analysis - has thought about how to give his customers a product which has just enough features to be viable. So maximum profit with minimum risk.

And what is the suboptimal part of such an MVP now?

The idea per se is, as I said, not bad - quite the contrary! But even its inventor says about the concept of the MVP:

"Too large or too small a product are big problems. The MVP is the difficult-to-determine sweet spot between them. Teams flounder tactically in trying to determine the MVP." - Frank Robinson

So as so often the implementation is the problem. The misconception that the MVP is the minimal variant of a product. Quite simply dashed off. And not enough, I often see organizations slipping into the Product Death Cycle attempting to work after the idea of an MVP.

And even if the implementation should work. Even if the mindset is recognized and lived as such, the MVP often does not really work. Because such a minimum viable product is poor in features by definition. This is not a big problem for new products. But in 99,999...% of cases we are in areas where there is competition. And in the long run, the product with the most sensible features and the highest quality prevails. And not the MVP.

The road to Riskiest Assumption Tests

Especially software developers have quickly come to the conclusion that the MVP is indeed a great concept, but just has its weaknesses. So they tried to develop the idea of an MVP further. Entrance Minimum Viable Experiment. The MVE takes an MVP to evaluate a product idea. True to the premise, "Nobody expects an experiment to be a complete success." That sounds complicated at first sight, and at second sight one notices that the MVE is nothing but the good old banana principle.  
And then the Minimum Awesome Product managed to catch some spotlight. Those who are suspecting a bunch of buzzwords, hot air, and marketing babble, are completely correct in my eyes. The basic idea behind the MAP is that the "minimum feasible" is not enough to survive in the market. Those of you who have been paying close attention to the previous paragraphs know that someone did not understand the concept behind the minimum viable product here. Not a good requirement to develop something further if you are asking me.  
Other ideas include the Minimum Valuable Product or the Minimum Lovable Product. All driven by the worry, the customer might think the MVP is not a full product, but a worthless prototype. These are solutions, but in my eyes in the completely and utter wrong direction.

I see RATs.

So, Riskiest Assumption Tests. RATs. I do not know if Rik Higham invented the concept, but he was the first I heard speaking about it. Rik is asking a simple question:

"What's the smallest experiment you can do to test your biggest assumption?"

When you are building a new product, you have to start with a whole bunch of assumptions. We project workers even have our own tool for that, the Assumptions Log. The big disadvantage of such assumptions is that you just do not know anything about it. Of course. So you take the assumption that carries the greatest risk for you and test it. Without much effort, just as easy as possible. Test early instead of Fail early so to speak. (That should be printed on t-shirts, I know.)

That is, I build a product that just tests my assumption. Quick, easy, and inexpensive. Need an example? Google Glass. Such smart glasses are an incredibly complicated and, above all, complex thing. Not just the technology, but also the whole surrounding environment. Legal, cultural, social. What do you think, how long did it take to get the first Google Glass prototype ready? I tell you: one day. 1 day. (By the way, Tom Chi is the courageous product developer in this case.) And yes, we are very close to rapid prototyping here and we should take rapid prototyping as a role model more often I think. If you have an idea, but you are not sure if it is going to work, just quickly tweak something together and test your assumptions.

Is MVP a bad approach now?

No. At least not if it is interpreted and lived correctly - as a mindset in product development. And, if you choose a strategic approach. I think a variant like this might be a good idea:

1. Analyze and understand the customer's need.
2. Write the epics and user stories based on this need.
3. Disassemble the mammoth (so, the product) into meaningful parts. (A story map is a great way here.)
4. Create an Incremental Release Roadmap.

When I do this and listen to my customers, I will have created my MVP in one of the first sprints. You notice, this is not a thing that you have done quickly in one refinement. This is hard (product development-)work.

And here riskiest assumption tests are a good alternative if I want to quickly and efficiently test my assumptions. Just dare it more often.