Misconceptions on a Minimum Viable Product
I first came across the concept of “Minimum Viable Product” (MVP) when I read the well-known book The Lean Startup by Eric Ries. This was during my studies some years ago, and since then I came across of various interpretations. One just keeps coming back: “This prototype is still a MVP so its OK that not everything works properly”. WRONG: a MVP is never an excuse to deliver a buggy or a broken product.
I have heard this misconception so often, that I decided to write my first ever article about this topic. I will illustrate this with an example.
The case: Launching a new product
At one of the companies I worked for, we were developing a new product when suddenly one of our clients asked if we could deliver it right away. “Of course!”, and without hesitation it was decided this client would be the launching customer for the product. The thing was, the product was only partly finished, both functional and performance-wise. I knew at that point the product would break right away in production.
This was the moment, when one of the members of the team came up with the infamous quote “It doesn’t matter the product isn’t working properly, it is still a MVP which we will test with the customer”, followed by, “the customer knows this is a MVP so will not expect a flawless working product with all features”. Eventually it was discussed to go live, and in the subsequent weeks we got complaint over complaint on product features not working. The product was unusable in the state we delivered.
What did go wrong?
In this case, we were doing two things wrong.
1: We were not using the customer to learn, but to find bugs in the product
The whole idea of a MVP is to create a validated learning process on how a customer uses the product. A customer in this stage has the sole function of testing the functional assumptions during real-life use. In our case, the product was launched to sell to the customer, and to find out where it would break in production. Ries writes “Build the right thing, then build the thing right”. At this point of time, we did neither of the two.
Lesson: When releasing a MVP the customer isn’t there to find bugs in your product, but to validate the functional assumptions you have made.
2: The product was launched with a set of non-working features
During the launch the product contained multiple features which did not work at all but were already incorporated in the UI. It was discussed not to remove these non-working features during launch, because the product would then only have 2 features left. Instead, the idea was to keep these buttons in the UI, so the users could already get an insight on what features would be added in the near future.
When we received feedback, one of the comments was “this button for feature X doesn’t work at all”. The users expected the function to work, since it was incorporated in the UI, but thought the feature was broken. On top of the already buggy working features, this didn’t increase the value of the product at all.
Lesson: When releasing a MVP, only release the working features which you want to validate or know already function as intended. If you release the MVP with not-yet-working-features this significantly devaluates your product. Instead of dangling the carrot in front of the user on what the product will have in the future, the user will think the product is broken.
How should we have launched the product?
So, how should we have tackled this situation? We launched to0 early in the development process, because we were too afraid we would lose the client. In the short time period we had before launching the product, the focus was too much on delivering a 50% working “complete” product and fixing issues on the way, rather than delivering a 100% working “minimum viable” product.
In this time period, we should have prioritised and work only on the necessary features to actually deliver a MVP, to build the right thing. And then add and improve features on the way based on the validated learning process, to build the thing right.