What are your main concerns for MVP(Minimum Viable Product)?

In MVP Approach, the beta version of the product is developed first with just the necessary features. This is to get money and feedback from early adopters.The idea of Minimum Viable Product approach is useful because you can basically say to your users- look, our vision is to build a great product.

Awaiting for Feedback.

It might help to think of MVP as just one part of a bigger product development and go-to-market strategy. Consider it this way. If:

1) you begin with the end in mind,

2) you have a solid business model,

3) you have a product vision that isn't tied to really granular, specific feature-functionality that you aren't willing to change even when feedback indicates that something is wrong (I call this "founderitus", or in other words, "Don't let reality get in the way of a good idea"), and

4) you effectively communicate your strategy internally and to investors

Then MVP is often a wise approach.

Here is why: If you focus too much on the "V" in MVP, you might conclude that you product has to be viable upon your first release; which means the inherent challenge in is knowing exactly what will satisfy potential customers enough to continue using your product beyond their first experience. This viewpoint also causes irrational fear and consternation about whether or not you will make the right decisions for V1.

But you shouldn't worry too much. MVP isn't really a business goal specifically related to the first release of a product, but rather a philosophy regarding the incremental release of the fewest features necessary to drive adoption, decrease attrition, and get feedback for improvement at every release of a product. The point I am making is that if you do a great job of communicating your solid business model and product vision to your team, it doesn't mean the end of the world if you launch a very "skinny", inexpensive product and it fails to generate the traction you ultimately want to achieve. Rather, it usually means that you need to get some customer feedback, make some tweaks (sometimes major changes which you want to catch early), and continue releasing enhancements that are increasingly more relevant to the needs and requests of real customers.

The alternative is waiting longer to launch, making poor decisions about the core features of your application (the features that you just "know" customers will love), and then developing rich feature-functionality around those poor choices. Then when you finally launch and find out that you missed the mark you have no funding/runway left, no traction, no customers have a vested interest in seeing you succeed, and a product that is so "developed" that it is impractical to take a step back and rethink your approach.

By launching early and releasing often you will always be developing against real customer feedback, enhancing what's working and nixing what isn't, and you will be forced to deal with major systemic changes as early as possible.

If you are concerned about competition, failing spectacularly and getting a bad image early on, or something along these lines, try to keep in mind that MVP doesn't have to mean "publicly viable product". Focus on getting a small group of early private beta testers together, write to them often, don't abuse their generosity, thank them for their feedback, and eventually begin opening up the product to others. If you’d like some support, here is a link to a study that concluded that "The best results come from testing no more than 5 users and running as many small tests as you can afford." Show this study to your investors, then focus on getting 5 relevant users to participate in early testing.

http://www.useit.com/alertbox/20000319.html I think MVP is common sense, the study supports MVP and the "release early, release often" philosophy, and I hope you see the wisdom in it as well.

Best of luck with your venture!

Jon

I incorrectly read Eric Ries and the MVP gurus as a way to simplify the start up process. The promise of getting market validation as you go and reducing the riskiest aspect of a technical startup is certainly alluring and the principles are sound, but execution is everything.

It is incredibly hard to pull off. To do it correctly requires more expertise than the traditional startup model. You need to have an incredibly flexible technical team paired with an incredibly talented marketing team to successfully build a product around the MVP. There are certainly good tools out there and a few people that can execute against this model, but my experience is that unless you really know what you are doing you are introducing execution risk in hopes of reducing market risk, and execution really is everything.

Minimize market risk at every step you can - test google and facebook adwords for your product, advertise on beta lists, track, analyze and optimize based on numbers. Include 'coming soon' ghost links and be aggressive obtaining customer feedback, and all of the other very good suggestions in the 'Lean Startup Methodology'.

At the end of the day you still need to build a killer product. The MVP process should be seen as a set tools which help make sure that you aren't wasting time chasing bad assumptions, but it's not a substitute for vision, and it's definitely not a way to attract users.