What exactly is a minimum viable product (MVP)?

Earlier this month I gave a talk to several groups of 8th graders at a middle school where a friend of mine teaches.  I talked to them about what it was like to be a software developer, what I did, what my day was like, and what they would need to do if they chose such a path.

Beside just rambling on about the processes of learning and practice, I also showed them a Xamarin Forms application called About Time that I had written quite a while ago that is a quirky kind of clock.  I showed them a bit of the code the deployed and ran it on my iPad – which was about the coolest thing I could think of related to some of the normal development that I do which most 8th-graders would not be too enthused about.  But creating an app that you could put on your iPad, that was something else.

The app was just a learning experience for me when I was learning Xamarin Forms and while I have considered it many times, I have not spent any actual time to finish it up to publish the Apple App Store.

A couple of days ago I get a package in the mail that contained a stack of thank you cards from the school and from the students themselves. Most were of the “thanks for coming and talking to us” variety but a few were very appreciative and inventive in what they had to say and you could tell they actually took the time to write what they thought.

One young lady named Alexis, had this to say:

I really think you should make that software into an app. The only advice is if you could change the background so it could be personal to users.

Does she look like a future product manager or what?

So Alexis, let’s discuss the application development process and what it actually means to ship an application that people will either purchase or use.

Minimum Viable Product (MVP)

A minimum viable product, is exactly that: It is a version of your product that contains the minimum amount of functionality required to perform its job.

The purpose of an MVP is to get it into the hands of the users.

Why is this so important? Back in the late 1800’s, a Prussian army general named Helmuth von Moltke the Elder coined phrase (paraphrased):

No plan survives contact with the enemy.

My updated version of this is:

No plan survives contact with reality.

The basic concept is that we as software developers do not often know what our user want.  In fact, in most cases, the users themselves do not know what they want.  So what do we do?  We guess.  We may shroud this in market research, focus groups, one-on-one’s, etc., but in reality, until people see a thing, it’s really just conjecture.

Don’t believe me, listen to these guys:



So, the idea is that you create a product, get it into the hands of users, the take their feedback to improve the product.

So you want me to ship crap?

Nope. That is not what I said. Your product needs to be professional, functional, and perform the basic tasks for which it was designed.  But, it does not need to have a million bells and whistles that people may or may not use or need.

Consider this:


Pretty scary to think about, but unfortunately it contains a lot of truth.

Why is this important?

It all comes back to time and money. It serves no useful purpose to spend months and thousands of dollars adding features that you are not sure people will need or want.  Stick with the basics then iterate from there. It costs less to add a feature than it does to change a feature once implemented.

It is also important to note that this practice is valuable no matter of this is a paid application or a free application. Time is still money and they don’t make any more than they used to.

I have personally spent months developing software that people did not buy and let me tell you, the thought of the sunk cost of that effort makes me queasy every time I think about it.

So let’s get back to the application that I demonstrated to the kids as an example of an MVP, the possible update process, and how things can work.

About Time, now and future

The idea for About Time came from a watch that I read about ten years ago. I thought it was a pretty cool idea but later research seems to indicate that the watch never made it out of the prototype phase.

My version is slightly different, but it uses the same concept of telling time using phrases that many people commonly use when telling someone the time of day.

Here are some screen shots showing About Time in action:


At around 5:35am.


6:10am or so.

Here is the path that About Time could take:

About Time v1.0

Version 1.0 is my MVP and really needs to have just the basic functionality:

  • Display the time
  • Change the background image to reflect the time of day
  • Update the time should the application be running on the screen so we always have the current time

At this point, it does everything that it is designed to do so I can bundle it up and ship it to the app store. My main decision point now is the price. Here are my options:

  • Give it away
  • Charge $.99

Remember that on the Apple App Store, once a user purchases your application, they get future updates for free. The only way to charge for an update is to create a new application. So once you have their $.99 (minus the Apple commission), you have made all of the money that you can make off of the sale to that customer, unless you create a new app. (we’ll discuss other monetary options in a minute.)

About Time v1.1

Assuming people are using the application and that you have received good feedback and ratings, consider moving the the Android and Windows Phone market places. Since the code was written in Xamarin Forms, it is already cross-platform and just needs to be published to those markets.

About Time v1.2

The phrases are hard-coded into the application so let’s make them configurable by the user. Let’s also ship some pre-defined phrases from other countries.

About Time v1.3

The times that the app uses to determine when to switch background images is hard-coded. Let’s add a call to an Internet web service that will get the location of the device to determine the proper boundaries for sunrise, sunset, day, and night.

About Time v1.4

Apple Watch edition. Assuming by this time that Apple actually allows us to create applications that can show you the time of day.

About Time v1.5

At this point we need to discuss and discover if we need to add an alarm clock feature. If so, then do it now.  How do we know if we need an alarm feature? We ask our users to see if that would be something they would find useful.

About Time v2.0

In this version, we add the following features available as in-app purchases:

  • The ability to add custom background images
  • Synchronizing configuration data (phrases, images, etc.) with a cloud-based database so that About Time running on any of the user’s devices will always have the same configuration.

This will be the final version of About Time, baring any maintenance updates.

So what is the point of the multiple versions?

Well, there are several things to consider:

1. Regular updates will increase your visibility within the App Store.

2. You have a methodology that allows for a constant feedback loop with your customers.

3. You don’t have to worry about spending time on unused features should the feedback not be favorable. You can halt development at any point in this product plan, should you choose.

#3 is the most important point, so let me give you an example of why:

In v2.0 we are going to allow the users to select a background photo of their own.  While this seems like a trivial exercise, here are the actual steps required:

  1. Selection of the photo for each of the four times of day
  2. Storage of the photos
  3. Photo analysis. In order to have a text color that allows the time-phrase to be shown, we have to sample to photo to determine what the main color is so that we can properly adjust the phrase to be either black or white.

Again, not rocket-science steps here, but things that must be considered and which will take time to do properly.

In Conclusion

So to wrap things up, just ship the damn thing. You can make it perfect later.