The Fallacy of MVP

In mobile application development circles, fads tend to go in and out of style. In the last year or so, the concept of MVP (minimum viable product) has been rapidly adopted as the latest methodology for developing and launching mobile apps.

In a nutshell, MVP (minimum viable product) advocates encourage developing a very minimal app as quickly as possible and launching it into the market. Development time of days, weeks, or at most a few short months is suggested.

The app development is focused on providing only the bare minimum of functionality needed to present the user with the unique function or capability that is the raison d'ĂȘtre for building the app.

This minimally viable app can then be launched into the market and valuable feedback obtained from users that will drive development of enhancements and add-on features in rapid-fire quick succession.

The theory is that rather than painstakingly planning the architecture, design, and development of the entire app - a process that could easily takes many months or years, the benefit of rapid iteration with real-world feedback will result in a better app in less time. Instead of one release after a 12-month development cycle, an MVP app might have 6 or 7 releases in the same period.

The MVP tactics goes hand in hand with current start-up culture. In the past, start-ups required a significant amount of capital, regardless of the end product. Office space, computer equipment, salaries, and infrastructure were significant costs that had to be front-loaded with investment capital long before any product sales or revenue stream could be established.

With today's personal computer power, virtualized servers, and dirt cheap hosting services, many startups today are simply one or two people with an interesting idea, a laptop each, and a big supply of top ramen noodles.

They work without any salary dependent upon the kindness of others (friends and relatives) or part-time real-world jobs. With a much shorter runway, these startups have embraced the MVP concept out of necessity. Their company is not structured to survive a long development cycle, and with overly enthusiastic idealism, they truly believe they can built a world-class product in only a few months.

The MVP concept has developed "legs". Synergistic methods such as continuous integration, frequent time-based release cycles, fail-fast/fail-often mantras and sprint development cycles have replaced traditional meticulous planning, design, and software development methods.

What is wrong with MVP? Here are a few crucial considerations that are overlooked in the rush to release minimal apps quickly:

You never get a second chance to make a first impression! Unfortunately, MVP products are often visually ugly and missing a lot of basic functionality. It is not just bells-and-whistles that are omitted, but a lot of important, but not deemed critical, features and functions are left off.

There is a tremendous battle for user attention in the mobile app market. While the price of many apps have been driven to zero with the race-to-the-bottom in pricing, the number of new apps being introduced is only accelerating.

Consumers and business users do not have the time or attention to spend a lot of energy on app discovery so the first time they come across your app will very likely be the only chance you have to captivate their attention.

An app that is ugly visually (because fancy, interesting icons & graphics didn't make the MVP "cut"); a confusing/lousy first-time user experience (because "on-boarding" tutorials, videos, or help files would require too much time/expense and can be added later); and very bare-bones functionality (because development time was limited artificially to a few weeks or month at most) will inevitably result in a less than pleasing initial experience.

Now I am not advocating that the traditional waterfall based, long turn-around development cycles are ideal, I am more pragmatically suggesting not to "throw the baby out with the bath water" and encourage a hybrid approach that keeps the best aspects of both traditional and MVP methodologies.

I suggest aiming for what I am calling an MPP release - Minimum Pleasurable Product. Focus on the unique functionality or capability of the application, but build the minimum feature set to be an enjoyable first release. Give equal emphasis to visual appearance, design, on-boarding, and critical mass functionality.

Develop a cohesive initial product with enough functionality to be useful and enjoyable along with providing an intuitive user interface. Make the initial experience pleasurable for the user so they can be productive from the start and only pleasantly surprised as future releases add more capability.