Minimum Viable Product is a Bad Pattern

Posted on: 2017-04-17

A few years ago, for me, MVP meant "Most Valuable Professional", but since I moved in the United States, every time I hear this acronym it's for "Minimum Viable Product" -- and I hear it a lot. It's almost a habit that people have. When discussion arises around what needs to be done, this free card gets on the table. Mostly at a time when someone is pitching an idea that is time-consuming or that doesn't go in the direction desired. Lots of people get caught in the trap of accepting this excuse without giving more thought while this is certainly very costly for a product.

The rationale behind the MVP can answer is that we should build the minimum possible and iterate afterward with how the consumer reacts to the product. This way, you do not build features that the user do not really want. At that point, I think we can all agree, but the problem is that if you are building a car, you still need to have seats. The original meaning of MVP was that your car shouldn't need a rocket to fly. Unfortunately, like anything that gets used too much in the wrong situation, it creates the reverse effect -- a product that is not very viable.

The first bad resultant of building with a minimum spirit attitude is to bring the product to stay at this minimum level. While many people really had the intention to iterate to improve the feature, the reality becomes something else. It will probably stay minimal because of many reasons. The most popular one is that "it already does the job". For example, users may need to click 5 times more than it should, or that the user interface is built to fast that it almost forces the user to consult the documentation to figure it out; but "it's good enough". Also, it stays minimum because everything is money driven and budget gets shuffle all the time. Future alternatives to a better plan get behind an infinite list of other "supposed" more important tasks. The major issue of this minimal spirit is that customers get a piece of software (or any product in reality) that is flawed since its design. Some side effect is to have a big product with a lot of features that are all average instead of being good. By aiming at the minimum, the whole product stays at the minimum bar.

The second result is that it's hard for people who get used to work in a minimum environment to see beyond what is produced. After few months or years of working by doing the minimum, your expectation bar gets low. While having a car with massage seats is probably not a good idea, because it's too much, having a car with seats that is just a piece of wood shouldn't be your minimum. You may think I am stretching the idea of MVP in this example, but in reality, for any of us, a wooden seat is just ridiculous. Same thing happens to software, we are just more tolerant since it's less tangible.

The third output of a wrong MVP is that it's very short-term goal oriented. When working on a product, you should not plan its next 10 years, but you should be able to see ahead for few months and have an objective. MVP becomes the excuse for people to not think more than few feet in front of them. A short-term vision breaks the master plan of having something cohesive, build in a way that can grow in a direction. While software allows doing more easily 360 degree turnover, it is still very costly and creates many technical debts in the code. The excuse of doing the minimum and get the customer feedback for not having a plan is even more obvious when once the feature delivered that there is not telemetry based on users behaviors or not any time allowed to improve upon any feedback at all. I have seen many telemetries getting gathered and never queried. The reason is very simple, while MVP is initially mentioned some deciders know that they cannot fail, hence not acknowledging that something is wrong is a way to avoid being wrong. Pushing a boat into the ocean and hoping this one to land in a good place (which we do not know where it is) is a sad reality. Not looking to see if this boat could have landed in a better place is also a symptom of a wrongly MVP pattern.

The fourth fallacy is that being in a constant MVP environment bring your expectation low, which means you will get low results. Forget about creating a good user experience, or creating a "wow factor", or trying to be innovative in MVP mode. After all, the first letter of MVP, is M for "minimum". It's like asking your kid to aim for the minimum grade and expect this one to be the best of its class at the end of the year. Again, we shouldn't aim to have a flying car, but your car should beat your competitors in term of performance, consumption, comfort, etc.

The fifth result is the principle that with MVP we will iterate into something less minimum which will be better in time. I have been the witness of this pattern several times and the output is always the same: many iterations with drastic changes that could have been avoided with more though or even just a little more time at the beginning. I saw many people rising proper points and issues that could have been solved right from the beginning, but because the minimum was required, many iterations went down the road and added 6 more months instead of going in straight line. The side effect is that the code is getting messy, incomprehensive by those who worked on the previous iteration and discourage those who keep working on the same thing over and over again. These same people, which often knew since the beginning that it would have been better not to take this detour. A common and wrong behavior of those who are behind this MVP iteration spiral is that they are satisfied to see the improvement between the iterations which is just wrong -- it could have been right from the start and not being bad at all. Finally, you can confirm that you are in this pattern if you are iterating without even getting users feedback. This happens if the MVP route was taking to reach some "fictional" deadline or because one individual well placed in the hierarchy wanted something else. By fictional deadline I mean that a date is dropped on the table for some reason that is not very clear and it becomes an emergency which no one understand since it wasn't an emergency since months and months... mostly this idea converge with the short-term plan which it was pretty obvious that this would be needed but it wasn't looking ahead.

The sixth fallacy is present only if you have a product with real customers that are paying to use your software. Once you are done with the release of your minimum viable product, lots of people well placed in the hierarchy become frightened by changing or iterating. The reason is that the product is working, it has to pay customers and why trying to change something which could disappoint existing customers or even lose some of them? That happened more than you think. Instead of having a strategy to test on a small subset and go ahead, we go on the spiral of overthinking to try to absolutely guarantee that it must satisfy everybody. And, as we know, having everyone satisfy is impossible. So, people become frightened and stay with their minimum product or changing really subtle elements and stop thinking that they can grow more, do change to get more customers, etc. While this could be mitigated with a proper transition plan, it's costly to do if you always aim for the minimum because the system/infrastructure you are working on is probably of minimum caliber too.

MVP remains for me a keyword that people use in discussions where they want to kill someone ideas. There are many other keywords used like agile, iterative and slim that are used to avoid thinking more than just the minimum. Like I said, it's not about trying to figure out everything from the start, but it's about having a vision of what we want and do what needs to be done in order of priority. You shouldn't have to do 3 iterations of the same thing even before releasing your product, neither you should work on something without having the master plan clearly exposed to you. When Tesla built its car, they didn't said that they wanted to do the minimum possible in electric car to be just a little bit better than the competition. They did the best they could with what they have without going crazy by trying to get a flying car. Every time you hear someone bringing MVP, you should be sure that the product is still doing what it should do, without the fluff of bringing too much side features, but also without removing everything from it which would result just to more work later or a bad user experience.

The end result is a growing amount of bad products getting into the market rapidly with low quality, with features that reach their limitation within few minutes of use, and that even a neophyte can tell you that it doesn't make sense the way it's built. We see products that don't evolve in time and die by the competition, even if these one were popular once upon the time. We see big marketing events that should inspire us with something new and different, but we end up seeing copycat of existing features without any innovation added.