Um, that’s not an MVP

One of the questions I get frequently when I am speaking at conferences or training clients on how to improve their new product/service development process is this, “what about the minimum viable product?” This article is to help managers and executives understand today’s implications and limitations of a minimum viable product. 

Defining MVP

The minimum viable product (MVP) was popularized by Eric Ries’ book The Lean Startup. Eric states that “the goal of the MVP is to test fundamental business processes.” He goes on to say “Any additional work beyond what is needed to start learning is waste.” Technopedia defines MVP as “a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.”

Technopedia defines MVP as “a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.”

Since its introduction, the concept of MVP has been abused by software and hardware designers alike. Unfortunately, most MVPs I see serve the impatient and undisciplined as a way to justify their rushed approach to launch a scaled-down product with plans to add additional features in the future.

In classic Silicon Valley style, proponents push the MVP model just like entrepreneurs push unicorn valuations for software companies that have no sustainable business model: it’s not ready for prime time yet. In the valley, something that hasn’t been updated in a week is “old” and if a month goes by without an update, a product is knocking on death’s door. Heaven forbid you update a product quarterly. Despite “real time” updates, this method is fraught with problems.

No Quality

One of the things I hate the most are poor quality products. To me, it is a sign of poor engineering. Although it could be that the product or service was produced or manufactured poorly, it is most likely a failing product was due to a bad design and insufficient testing during development. The damage due to a poor quality product can be long-lasting. Dodge Dart’s initial quality problems & Sling TV’s poor streaming issues are great recent examples of not delivering a quality product. People tell more people about poor experiences than good ones. One lost customer due to a poor experience can lead to many others never trying it. I’m not the only one that feels this way.

According to EY, a global leader in knowledge management, Australian businesses are losing more than $720 for every negative customer experience. That’s a lot of money to lose and a number MVP practitioners likely don’t share with the CFO when pitching a new product. Your product has to be high quality from the start. You can add new, valuable features in the future to differentiate it from the competition, making sure each product or service release is successful from the start. 

In software, the rush to release a revenue-producing MVP leads to many issues from their poor workflow, missing features or annoying bugs. These software issues are then addressed and updated on a continual basis. This is one of my biggest frustrations in software. The number of updates that companies are pushing to their smartphone apps is unacceptable. I have my app auto update settings turned off because I don’t want my phone to automatically download the latest version. Consumers should know what changes have been made before they update an app.

Because of this, I often have dozens of apps that are always in need of an update. I scan the description of every update before I make my decision to update or leave as is. If it says bug fixes or minor improvements, I am passing on the update. I will usually only update when there is an interesting new feature being introduced. Many times, I have seen apps change their user interface, just to be different. I think this is confusing and causes the end-user to relearn the app, leaving her in frustration. 

Excuse to Appease Sales

I can’t tell you how many software teams I’ve seen say “We’ll add it or fix it in a future release, we’re working on the MVP.” This is simply the sign of a poor development capability and leadership. If the marketing team has identified a pain point the customer has now, it needs to be developed now. If there are known bugs or workflow issues, they need to be fixed before release. MVP is not permission to release a substandard product. 

Although many companies are now pushing for MVPs, an MVP is not an excuse to throw a poor quality product or service into the market faster. 
There can be a great harm done if the next iteration of the product occurs fairly quickly after the original. In B2B applications, the software must be pushed out to the whole enterprise again and an entire workforce needs to be retrained on new features or capabilities.

Companies that sell software as a service (SaaS) rely on subscriptions. Poorly done MVPs may result in cancellation. A customer won’t spring for the next period of subscription or wonders why fixes weren’t included in the first release. 

Hardware is NOT the Same

In hardware, the implications are much more significant. The investment is not simply a software engineer’s salary for writing lines of code but instead huge investments in tooling, manufacturing and service readiness. Going from an initially released MVP to an updated can be extremely expensive. 

MVP was never meant to be developer lingo for “release something to the market as soon as you can.”

An MVP is a prototype to validate your hypotheses. (read this again)

Prior to creating the prototype, you need to understand the major pain points you’re trying to solve. Fixing these is what will create differentiation for your product. The software or hardware development team, its capacity, and their agile-epic-train-sprint-release protocol is not the determining factor for what a successful release needs. 

Development teams need to focus on creating what the product’s owner has defined as what is required to win. The MVP is the first attempt at delivering that solution. After validating with a subset of the customer base, the company can then make the final changes prior to release.

You don’t release an MVP as a formal product. You don’t rush something out the door hoping to fix it later. An MVP is a chance to test a prototype with your future customer base. Period. Use it for such and benefit from the learnings prior to release. Then, you will experience success.

Leave a Reply