5 Rules to build a software MVP

The path to a minimal testable product

I’m tired of saying that your MVP is not small enough. Here are five simple rules to build a software MVP.

Rule #1

Quality is non-negotiable. Quality must remain high. You cannot build something that has poor quality.

You are not building a cheap product fast. You are building a quality product with reduced scope.

Rule #2

The release date is non-negotiable. Once you define the scope and set the date, you cannot postpone the release date.

There is a fixed amount of time that you have to work on the design and development of the software MVP. Once you have defined the release date, you cannot change it.

Rule #3

The end result has to be a usable product which tests a core hypothesis of your business model.

When you define the minimum feature set, you need to always keep this in mind:

This is a great illustration by Henrik Kniberg. You can read more about this in his article about an Earliest/Testable/Lovable Product

Rule #4

You can remove features from the scope. You must not add features to the scope. The goal is to avoid scope creep as much as possible.

Before you begin, you will have a list of prioritized features. You will start working on the most important features and leave the least important ones for last.

You might need to cut some of the features out of the project. So it’s best if the least important features get cut.

Rule #5

Before you release the MVP you must setup a goal tracking mechanism. The goal is to track the interactions with the MVP and start learning from day 1.

Fortunately there are great free tools that you can use like Google Analytics or Mixpanel. If you have a small budget, you could also use Intercom to talk to the people using your product.

If you follow these rules, you will be able to release early and start iterating using real feedback.