Lets Talk about MVP
From the time I was deeply involved in product management at Linear Squared the concept of MVP-Minimum Viable Product, is what really bamboozled me! Of course everyone talks about it and writes about it, and agrees about it as a general concept. However, I’m yet to see two people seeing eye to eye on the scope of a MVP for any product. I found this phenomena really intriguing and started to formulate a framework around the definition of a MVP sometime back. This framework, I would say, is still work in progress. But hopefully it takes the existing ideas forward.
Concept of MVP
Concept of MVP stems from the fact that we should not build beyond what is really required for your first iteration. Lets call it V1.0. Why keep building (as opposed to go to market) if you can start generating revenue with what you already have? We may also end up building things that nobody really wants. These are very valid questions and concerns that no one can dismiss. Hence the general concept of MVP is universally accepted.
MVP or MFP
I recently watched a video by Anand Sanwal of CB Insights where he advises on 68 mistakes that a SaaS startup can make. Its a great talk. https://www.youtube.com/watch?v=fx1OXZAGd-I
He talks briefly about MFP, Minimum Fabulous Product. And it is obvious where he is coming from. Many of us visualize MVP as a buggy, ugly ramshackle of a product and wonder how on earth it can be viable.
Ask a Potential Customer
This sounds like a good idea and sound advice. The only problem is, it almost never works!
We have wasted many months in our product development by taking this approach. And I know that we are not the only startups who have fallen in to this trap, in fact the majority does. The problem with this approach is quite obvious, unfortunately in hindsight though :).
Customer will tell us what is viable to her. Not necessarily minimum viable to us. And if you get to the cycle of building a product until a customer acknowledges of its viability it may take years to get there. That is also, if you are lucky. Most likely, this approach will never reach the level of viability.
The simple reason is our very human nature. If we had an option, we will always be asking for more! Hence the customer, if given the option, will most likely keep asking for more. And this obviously is a viscous cycle.
I conduct this thought experiment between Steve Jobs and I…sounds weird :) If he gave me the option of deciding what is viable for me and made a commitment to build it for iPhone 1, I daresay iPhone 1 would still not have been launched!
Don’t Ask but Show a Potential Customer
Even though this may seem like a subtle point it makes a massive difference. We need to show the customer and ask her to make a purchasing decision on the “as is” product. Extracting that clear YES/NO decision is more important than getting the feedback. If we get some feedback, great, but never at the expense of a clear YES/NO decision. The Y/N decision makes us learn not only about the product but also about its pricing, which is priceless!
Minimality in a Mathematical Sense
Now that we have extracted a clear Y/N, we know if the current product is viable to the customer we have shown the product to. But the concept of minimality exist when there are many observations (data points, objects etc.) Hence the golden rule is that it should never be one potential customer that you are showing your product to. The more the better, of course, but as a rule of thumb try to start with around 10.
Let’s keep pricing aside for a moment. The 10 potential customers we have carefully picked will hopefully represent a fair cross section of our initial target market. And all of them will have different expectations in terms of viability. For simplicity lets assume the product we are building, lets name it F10Squared, can only have 100 features in total. No one can ever ask for a 101th feature.
Customer A may settle for 45 features to make a YES decision. This is the viability level for Customer A. But it may or may not be the minimum viable level for the product. We need to always remember that there is nothing called minimum viability for a given customer, only viability exist. The concept of minimum viability can only exist when there are multiple customers.
Strictly speaking, F10Squared can reach the MVP level when it has 35 features by selling to Customer D! It can have 10% of market share with 35 features and can be generating revenue from then onwards.
MVP and Price
We talked about getting that all important Y/N answer from the customer for the current product. However that answer probably is conditional on price. Hence it is important to put the price in front of the customer along with the product.
For an example, Customers will probably have a different viability opinion on F10Squared at a reduced price point.
At the price point of $500 as opposed to $1000, we would have a MVP at 31 features. And now it’s selling to Customer H, not D!
Easier Said than Done
Of course the above examples are trivial. Products are not as straight forward as F10Squared nor customers are as simple minded as Customers A,B,…,J. And pricing requires a lot of trial and error. However, having a well-defined framework around MVP would give us guide to navigate through more complex real world product management scenarios.
