How to Avoid These Three Most Common MVP Mistakes

We work with lot of founders to create prototypes, MVPs and full-fledged apps.

One thing that we invariably observe that founders want to have as many features as they can imagine in the product and want to ship it as soon as possible.

Some of the founders have read The Lean Startup book from Eric Ries and they think that let us bring first version out with minimum set of features and see if the features are accepted in the market or not.

Our experience suggests that this type of thinking seldom helps in making the product a success.

The reason?

Misconception about MVP as a concept.

Product Development is not about having minimum features done quickly and release version #1 in the market. It is about identifying a product-market fit and its acceptance with minimum efforts and focuses the startup’s energy in the direction that gives optimum results.

Mistake #1: Minimum = Minimum Features

It was early 2014 and Marc, an App Entrepreneur approached us to create an iOS app in the Photo & Video Category.

One of his friends has had 3 different apps in Photo & Video Category and he was making good passive income from her apps.

Marc knew this data from her friend and was interested in startups and entrepreneurship. He had read The Lean Startup Book and wanted to ship an app within 3 weeks with 5 or 6 minimum features.

When he came to us, we advised him that the features that he was suggesting were not unique and we had seen much better apps in the Appstore, which offered similar features.

Marc did not hire our services and hired another developer via a marketplace. Marc got his app done and pushed to the app store. In about 3 months he came back to us and shared his data:

Downloads: 1st day: 30, 2nd day: 45, 3rd day: 21, 4th day: 13, 5th day: 4, 6th day: 2, 7th day: 2 … and the downloads numbers were never in two digits.

Revenue: $9 total

Marc made a mistake of creating an app that did almost nothing different from its competitor apps. He misunderstood the concept of “minimum” and focused on creating minimum features.

Marc made a mistake of creating an app that did almost nothing different from its competitor apps. He misunderstood the concept of “minimum” and focused on creating minimum features.

The problem was the app was working fine but it did not have any unique thing that customers would buy the app for.

Marc understood the mistake and we worked with him to create an iterate app prototype that gave him confidence that his app would be successful if it is built.

The prototype was a visualization of several key features that we thought the app should have. We didn’t build the app. Creation of the prototype took about 2 weeks of time and as we suggested he met with about 150 potential users of the app.

Some users liked the app features. Some criticized it and few ignored it. But he has some good data to make a decision on.

So he concluded that I would add these 4 features in the app and reposition it with relevant Appstore Optimization.

And guess what, the downloads of his app increased and he found several users who asked for different tweaks and made suggestions.

Eventually not only he recovered his costs but made a decent profit. He made a mistake of misunderstanding the word – “minimum” and it cost him 3 months and caused him lot of stress.

How to avoid the mistake?

Create minimum features that enable you to gather maximum information about what your customers want.

Mistake #2: Viable = What’s That?

This is the most common misconception we see.

Imagine that you are trying to validate a product idea around Interior Decoration Niche but you don’t know if your idea is something potential customers would pay for.

Here are several options to validate the idea:

Create a landing page, which signs people up for the platform for a set price per month. Validate the landing page using AdWords and observe how many clicks you are getting on “Sign-up”

Create a lightweight non-functional prototype of the app, which can be installed, in your mobile device and go to 100 potential customers. Tell them that you have such a platform in development and you’re meeting them to understand the problems of the industry. Observe how they react. Through customer interviews, gather as much info as you can about the industry and better your hypothesis.

Go to a meetup of Interior Decorators and speak about your idea. See if people are listening to you. Once your speech is over, are people coming to you? Do they want to establish a relationship with you? If yes, then your idea is likely to succeed.

There are numerous other ways to validate a product idea. You don’t need to create a full-fledged product.

How to avoid the mistake?

Understand the distinction that MVP does not equate full-fledged product. It could be a small manual activity or a prototype that will bring you one step further in your feedback loop.

Talk to us for 30 minutes on this subject and you might get insights that will save your lot of time, energy and dollars.

Do you know that 30 minutes consultation with us is totally FREE of charge. Schedule a time. Send us an email on

Let us look at the case of Marc outlined in above section. Marc didn’t explicitly ignore the viability part of the things but his actions did so. Adding in features that are not viable – that are not something that the customers want – is a waste.

If a feature does not enable you to continue the build-measure-learn feedback loop then it is not viable and shouldn’t be part of your MVP.

Also, many founders think that viable means commercially viable. That’s true but when you’re building an MVP, it is not about making commercially viable. It is to enable you to continue the feedback loop.

When we look at an MVP creation request, we look at it from the perspective of what would be the problem-solution fit? This is the most important question to be answered while creating an MVP.

How to avoid the mistake?

Make sure that the MVP you’re building has a clear problem-solution fit. While this is easier said than done, if this is done right, most problem would not even surface in future iterations.