Defining An MVP: The First Step Is the Hardest

When we talk about application development there are many terms that get blended regarding an initial application release. Minimum Viable Product (MVP), Release Early – Release Often, Version 1, Alpha Release, Beta Release, Proof of Concept (PoC), Prototype, Lean Development, the list goes on.

These terms have a lot of overlap in their definitions and are often confused. People tend to use them interchangeably. At the end of the day, it really doesn’t matter what you call your first release as long as the team understands what you are trying to build.

What Is Your Intent?

If you want to develop an application, before you decide what features and functions will be in your initial release, you should consider its purpose.

Will the release be something you can show to potential investors to acquire additional funding? If this is the case then you might be talking about building a Proof of Concept or a non-functional prototype.

Will the first release be an application that is released to a very limited number of select users to gather feedback on the application’s viability and usefulness? This would require a functional application, but the level of polish on the user interface could be minimal.

Maybe you just need to prove that the technology behind the application can be built. If that is the case, building a Proof of Concept would be in order.

Will the first release be made available to the general public and be possibly be monetized from the start? If so, a higher level of polish on the UI will be required. You don’t get a second chance at a first impression after all. You’ll need to be sure that the application has enough functionality for the users to want to use it regularly. In this case, you might be building a Version 1 or an MVP.

The First Release

Let’s assume you are trying to build an application that will be released to the public. You are going to release the application either regionally or nationally. Your hope is that users will like the application, find it useful, and want to use it frequently. The goal for the first release is to attract a userbase, and maybe even to monetize it right away. Your first release to the public would be Version 1 (or 1.0) of your application.

If you have an unlimited budget and are very confident that you know exactly what your intended audience is going to want, then your path may be clear. You can develop a specification for your application and build all the cool bells and whistles that you know the users are going to die for.

This typically is not the case.

In fact, it is very possible that the cool bells and whistles you think the users are going to love will be completely overlooked. Instead, the users will request features that you had no idea they would want. You can waste a lot of time and money trying to predict what the users of an application will want and by assuming you know how they will utilize your application.

Most often, you will start with a pretty good idea about what your users will need. Your budget for the project will probably have some constraints. In this case you may want to develop your application’s Version 1 as an MVP or Minimum Viable Product. Those two words, Minimum and Viable carry a lot of weight when you are making decisions about your application during the development process.

So What Is A Minimum Viable Product (MVP)?

A Minimum Viable Product is a buzzword that appears in software development a lot. An MVP can be a variety of different things, for example; a prototype or proof of concept that would be used to demonstrate the capability of your application to a limited audience. The trouble with buzzwords is that everyone has a different definition.

In this case, I’d like to think about MVP as the Minimum set of features and functions YOU think are required for the intended users of your application to find it Viable (useful and attractive).

When developing an application, it is easy to get caught up in all the cool things that you can do with software. The issue here is that every feature takes time to develop and more time equals higher cost. These cool features that you want in your application will all affect the bottom line. It’s important to try to limit features to those that are necessary to make the application functional. The features that you think are cool may not be useful to the end-user. Remember, the time you spend developing them may be wasted if they are not used.

There is a balance when it comes to what is really viable for the end-user. Your application can’t be so stripped down that the users complain that key features are lacking. You must include the functions that users will need to use the application for it’s intended purpose. You should include features that make the application easier to use and provide for a better user experience. The challenge is keeping features to a minimum while ensuring the application is still useful (viable).

What is critical when it comes to an MVP?

Design. How an application looks and feels can be almost as important as it’s function. Good user experience (UX) and user interface (UI) design can still be done while constraining your project budget. The design phase is worth a little extra time to make sure the application is attractive to the users.

There’s Always Another Release

One of the most important things to remember when defining requirements for your MVP is that there will be future releases. An MVP allows you to release your application quickly and at a lower cost than a full-featured build. It does not limit you to only one release. Instead, the idea is to Release Early, Release Often.

Keeping the initial release to the core features allows you to grow your app based on user feedback. Doing so can also help eliminate wasted time spent by developers developing features that users don’t really use (a key of Lean Development).
Let the users guide your development. This ensures your application will only contain features people will use and can help attract new users.

If you get an application in the hands of the users early, they will be happy to tell you how you can make it better. You might be surprised at how users will want to use your application. This is not a bad thing. It can be great when people want to use your application in ways that you didn’t expect.

When you are going through the process of developing an application it is exciting to see all of the possibilities. With software you can build pretty much anything you can dream up. It is easy to get carried away designing your application and adding new features. In order to avoid these mistakes, focus on driving a solid, core set of features that will make the application viable. A good development company can often help lend suggestions of what features to keep, and which should be cut for later.

At the end of the day, the app, and its initial release, are up to you. What will your MVP look like?