Are there significant risks to creating an MVP that is too minimal?

What a lot of folks seem to miss is that MVP is not JUST an acronym. It is one part of a larger methodology (Lean Startup). That wider methodology may or may not be something you wish to institute. However, if your understanding of MVP is based solely on the definition of the three constituent words you're likely missing something very crucial.

First and foremost, your goal is to build a successful business, not just to build "a product". A successful business requires a product that fits a market need in a manner that produces sustainable value. Within this understanding, MVP is a test, and it's purpose is to prove/disprove things that you are currently assuming about your market or your product's fit to that market. Assuming, because you think you know, but you have not proven. Simply asking a potential user is often not the same as presenting a potential user with the real life buy situation. I can confidently tell you right now that I will happily pay $20k a month for your product knowing absolutely zero about it. But, if you ask me for my credit card number, I wont actually give it to you.

Operating under assumptions increases the probability that you are wasting resources building the wrong product. Instead we Build (something that tests our hypothesis/assumptions aka an MVP), Measure (results to prove/disprove assumptions), Learn (replace assumptions with understanding and fact), then repeat, applying what we learned, adapting and progressing-- until we find product/market fit. This may sound strikingly similar to the scientific method, because it is, simply applied to business.

Your MVP is the right size if it can test key assumptions that you are making about your target market. That is THE criteria.

Right now, you are ASSUMING (worried, believe, etc) that potential customers will not engage if features x,y,z are missing. Test that assumption, and test it as quickly and cheaply as possible.

You can worry about how much to build, adding ever more features, delaying release -- increasing your resource burn by prolonging the time to market entry, thus increasing the overall risk to your business that you are building the wrong product and potentially die from failure to launch. Or you can as quickly as possible, build the smallest piece needed to test what you are currently assuming, in front of some segment of your actual real world market. As Benjamin Olding alludes to above... you must ship to KNOW.

This approach has the added advantage of providing your marketing and sale organizations with first contact experience as well. Again, we seek to build a successful business, not JUST a product. In my personal experience I've seen more startups fail from the sales/marketing side after "the product" has been built -- ultimately indicating inability to fit product to market -- than from an inability to perform the act of building a piece of software. It's very easy to build software. The challenge is building the right product for the right market.

Yes. I am a strong believer that people are taking the concept of MVP way too far without really understanding what it means. Remember that "V" stands for "viable". Strip down everything that does not include the core of what you are offering, but you need more than a landing page and benefit statement. That is not a viable product.

I think its more than just early adopters - its a matter of what you're testing with the MVP - ideally if you are testing the hypothesis of whether something will work or not from just a basic core idea perspective you can do that. We often use the idea of minimum loveable but you have to be careful not to be hung on the idea for too long.

MVP is a great concept but vary hard to do. In your example, you have to keep iterating until people are actually interacting with the product. You might call that the MVP, but then you might want people to interact with the product even more, and you'll need to keep going. So, maybe the MVP is further out. 

Hi Michael, Here are a couple of articles you may find useful. I've faced this dilemma many times, and have lived through the pain of user adoption when we've missed the mark on value/lovable in favor of minimal. This can be overcome by sharing prototypes with your target customers and seeing if it helps solve their problem better than their alternatives. Look for signs of loveable/delight reactions from your users. If you're not seeing a spark, what are simple UI/design adjustments that don't overcomplicate and keep it minimal, as intended. A good UX/visual design can infuse that love, assuming your solution actually solves the user's problem. 

No MVP design survives first contact with customers unscathed.   

Very few people are qualified at the outset to found & start a company...  Yet people pull it off every day.

It also depends on who you are 'selling' your MVP to. We launched a MVP that had the core functionality but was not very well designed and was missing a lot of the features that would make it smooth to use. But we also gave it away for free to hand picked teams (its a B-2-B product) that understood what an MVP is and were willing to give us feedback on a weekly basis so that we could improve it. I would be very weary of releasing an MVP to the public. The point of MVP is to get early users who will help you design the optimal product. 

Great insight gentlemen, thank you. I like Michael's point on the "Viable" portion of MVP. We obviously don't want to create something that doesn't do our core function well. I also like Steve's point on identifying a goal for our MVP. Our current goal is to build confidence and learn about what more(or less) our product can do for our customers as well as identifying when and how to implement our extended features.