Reading Time: 3 minutesLet’s begin with the core concept of an MVP – “Minimum Viable Product”. This is a concept that is literally self-defined, but do we really understand it? Most of us at least claim to, but that poses another basic question. If MVP is so well understood by us then why does only the end product matters? What about all the deliverables that come before the end product? Well because in practice it gets wrapped up around our conception of features that are important until it bears no resemblance to the concept itself.
To give an example, let’s say a customer ordered a meal and we first gave the customer raw veggies, followed by meat and other list of ingredients that will go into creating the said meal. What do you think will happen? The customer is going to hate it at every step and finally when the ready meal arrives the customer will be like ‘Why didn’t you give this to me in the first place?”.
Now let’s consider an alternative – When a customer orders a meal. Instead of offering him the ingredients we take a different approach now and focus on the underlying needs of the customer. Turns out that the customer is hungry and wants a satisfying meal. The final meal is just one of the solutions. We could provide him with a bread basket, followed by a soup, and then finally his meal and thus keeping the customer satisfied throughout the entire process. The meal here is just a metaphor, think of any kind of customized product development situation and this approach holds true for that.
Therefore as we see in the first scenario the team delivers all the smallest thing they can think of which will let the customer testing things and giving us feedback.
The customer is unlikely to be happy with this. This is nowhere near the meal that he ordered. But that’s OK! Why? Because we’re not trying to make the customer happy in that case. Our main goal at this point is just to learn. Ideally, the team explains this clearly to the customer in advance, so he isn’t too disappointed.
Non minimal MVP is not an MVP
When we start discussion with regards to a product, more often than not we try to broaden its capabilities with features and added functionality. This is NOT an MVP. When we do this we are building a bigger and more actualized product. The more functionality you load to your MVP, the further away you’re going to get from being able to reliably confirm or disprove your justifications on why the added functionality was required in the first place, leading to pushing the delivery date. Creating an MVP requires an intense amount of discipline and the ability to effectively say no by the Product Manager to ensure that the only things added to the scope of the effort are things that truly are required as a minimum feature set.
An MVP that cannot evolve is not an MVP
An MVP we must remember is just a building block for the next set of MVP capabilities. All too often, we lock ourselves into some technical debt that ties our hands in the future, or that requires that we perform significant refactoring on the backend or middle-tiers of our products — all in the name of “creating an MVP”.
In conclusion let’s begin with questioning ourselves when building a product, on what is really required as opposed to what’s good to have, to create a successful process map from MVP to the final product that the market needs.
As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.”
― Eric Ries, the Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
