Your MVP is not a prototype: Snatching failure from the jaws of success
The P in MVP stands for product, not prototype or proof of concept. This confusion could turn your MVP’s initial success into failure.
Prototype and proof of concept are valid and very useful stages in your product lifecycle, and you should have them if you can. They will provide you with useful validations about whether you’ve identified a real pain point and come up with a suitable solution; or whether your product is targeted at the right users in a way that they will find helfpul. But they won’t validate whether people are willing to spend their money (or their time) to buy your product. That’s the job of your MVP.
You are unlikely to get paid for a prototype or proof of concept. If you are lucky, you’ll get positive feedback, encouragements, expressions of interest, possibly promises to buy, and who knows maybe a letter of intent. Short of an actual firm order, all this tells you nothing about people actually buying your product. People move, priorities change, budgets shrink. Plus you’ll be speaking to a lot of advisors, consultants, investors, people too high or too low in the decision tree, all very helpful, but who won’t buy your product.
Your MVP is the first time in your product’s lifecycle that you will test whether people are willing to spend their money to buy it (again, if free or freemium, their time, which is just as valuable to them). But because they’ve spent money, they become customers, and they have expectations that you had better meet.
First, they expect the product to work and provide some real value. Prototypes and proof of concepts, by definition, don’t qualify. The good news is that buyers of MVPs are early adopters, and as long as your product resolves a serious problem (“paint point” in marketing jargon), they will be very tolerant of bugs and won’t care about missing “nice to have” features.
The bad news is that after some time, all users become more demanding and less forgiving. The bug that was hardly noticed becomes an annoyance, then an irritation, then unbearable. The feature that was hardly missed becomes a nice to have, then a necessity, then a demand. This happens faster than you think.
To make things worse, every customer will have a different set of demands and priorities for bug fixes and new features. Most likely you won’t be able to satisfy them all, but you have to satisfy some of them (and you may have to make painful choices about which market segment to please). Your MVP must be technologically robust enough that you can fix bugs and add features fast.
Prototypes are meant to be built fast and cheap, but for much less ambitious (if equally valid) objectives. Their technology is generally simpler but may run out of steam very fast. If your MVP is nothing more than a glorified prototype, chances are that you won’t be able to make it evolve fast enough, and you’ll be scrambling to rebuild your product under very high pressure; that always takes more time than you think, and by the time it’s ready, you will have lost a lot of your precious early-stage customers. This could turn your MVP’s early success into a huge disappointment, even to failure.
In short, your MVP must have a decent shelf-life. You will not have time to rebuild your product after your MVP’s launch. Typically, your MVP should last until your next (likely seed) funding round.
Your MVP’s technology must be chosen carefully, early on, so that you can address a good part of the explosion of demands that will arise from even a moderately successful launch.
Otherwise, confusing your MVP with a prototype could be a very expensive error to make.
