Can we agree on this? Our main goal is to deliver value to our customers so that they buy our products and services which provides us with revenue.
So that being true how do we do this?
Well we do it through the proper use of minimal viable product MVP but almost certainly not the way you're doing it and MVP needs a little help from a rat. A rat? Yes a rat, let's find out why and how.
MVP has been around for a long time was first coined by Frank Robinson back in 2001 and was popularised by Eric Ries particularly with his book, ‘The Lean Startup’ back in 2011.
But perhaps most people, certainly in the agile world at least, know it from Henrik Kniberg’s famous picture that went viral almost 10 years ago, not like this like this.
Now Henrik prefers the term ETUL earliest testable usable lovable to MVP but that never really caught on, MVP just rolls off the tongue better.
But unfortunately this picture has been massively misunderstood by many for a long time and in fact has caused people to adopt MVP but in completely the wrong way, resulting in no value and frankly frustration.
Henrik himself realised this and wrote a blog to explain it further which you can read here;
The main problem with Henrik's infographic is that people completely misinterpreted it they just looked at it without reading the explanation and thought oh okay so the customer wants a car but we can't do that quickly so we'll give him a skateboard first.
This led to organisations giving customers a minimum product not a minimum viable product.
People get hung up thinking that MVP needs to be a finished product, that is not the case. Don't look at Henrik's model and think no one will buy a skateboard if they want a car if you do you're missing the point.
The whole point of MVP is to learn, it's an experiment.
Now Henrik's infographic is a metaphor not to be taken literally it's about how you do product development.
You don't develop products slowly building them in stages, which is the first line in Henrik's infographic, what you need to do is understand the underlying needs of your customers.
Remember Henry Ford's alleged statement;
If I’d asked customers what they wanted they'd have said a faster horse
Now Henry Ford understood his customers needs, which wasn't a faster horse or even a car, it was to get from A to B faster.
So focus on what MVP can do for you, it's a learning tool.
Eric Ries said;
MVP is a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort
The key here is validated learning, the most important thing is to test your assumptions about your product with your customers.
And remember Oscar Wilde’s words;
When you assume you make an ass out of you and me
Well do that with a product that hasn't been tested and validated in the market and you're likely going to be doing far worse than making an ass of yourself.
More likely you'll lose hundreds of thousands of dollars or worse.
You might remember Quibi back in 2018.
It was a short live video app competing against YouTube and TikTok. It folded 2 years later in 2020 after spending close to 2 billion dollars.
Its content library was eventually sold to Roku for less than a 100 million.
Now Forbes said it was a misread of consumer interest while the Wall Street Journal said that they spent far too much on advertising leaving them with nothing left when things got difficult.
What Quibi didn't do was validate their concept prior to launch, this is the true purpose of MVP to quickly validate the concept before burning millions of dollars. Create the simplest smallest version of your product. It doesn't even necessarily have to be fully working it just needs to be enough to test your assumptions.
It's not a beta, this is a pre-release, it will tell you if your product has legs but way too late.
And it's not a demo either, this may be good for stakeholders but it doesn't tell you anything about the probable success in the market.
And it's not a proof of concept, this is a prototype, and can tell you if it's technically possible, definitely good to do, but it doesn't tell you if there's a customer need.
This is the key, MVP is the first thing you should do to make sure there is a real need for this product and that there is demand, but it doesn't have to be technically complete it could be entirely manual using smoke and mirrors and this is completely fine because all you need to know is whether this thing is wanted or needed in the first place.
This is where our rat can help us with MVP, our rat is the riskiest assumption tests better known as RATs. Now RATs has been called the MVP killer. It was originally put forward by Rick Ingram as an alternative to MVP.
Ingram argued;
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
But in my view both are legitimate and even complimentary approaches, you can use them at different stages of development or combine them, incorporating assumption testing as part of MVP.
Traditional MVP has its benefits but it can sometimes fall short in addressing those critical assumptions. If you only concentrate on launching a basic version you might end up wasting resources if those core assumptions turn out to be wrong.
Costly iterations rework and potential project failure.
Enter riskiest assumption tests RATs. It's been called a game changer in product development. RATs shifts the focus from the product itself to the underlying assumptions and risks.
Instead of blindly building an MVP it's about identifying and validating those riskiest assumptions first.
Now RATs prompts you to identify assumptions that if proven wrong could kill your product.
These assumptions are the really big ones the ones that could spell doom for your entire project. By putting them under the spotlight you can design targeted tests and confirm or debunk them.
The goal is to gather real world data and feedback that inform your decisions and shrink uncertainty. If an assumption gets invalidated you can just adjust your approach or even pivot the entire idea before going all in on development.
So how do you start?
First identify your riskiest assumptions
Create a hypothesis about each assumption
Design a test to validate each hypothesis
Execute the test and collect the data
Analyse the data and draw conclusions.
Now one of the key takeaways here is you need to involve your customers or potential customers early and often.
It's one of the things I see time and again, organisations not engaging with customers, not bringing them into the work with the product development team.
In my experience it's one of the key contributing factors to failure.
Credit to Jon Harmer in his Medium article on RATs and Ben Schwarz in his Engineering for Humans article on MVP.
Comments