The MVP (Minimum Viable Product) that you’re making is probably “wrong.” Mine have been too. In fact, I caught myself making one of the three most common mistakes last week.
Let’s go through these 3 mistakes one by one, and I’ll tell you which one I made this time…
These three mistakes are costly because they cause you to either throw away a great opportunity. Or, more likely you end up wasting months building something that’s never going to fly.
Mistake #1: Thinking that a Landing Page is An MVP
The first mistake is thinking that a landing page with a simple mockup is an MVP. I’ve made this one before, after being inspired by Dropbox’s startup story. If you haven’t heard Dropbox’s story, they created a demo video showing how dropbox would make transferring files between computers a breeze. The video went viral, and they ended up with a large waitlist. Startup idea validated.
While this can work, the so-called “landing-page MVP” is getting rather old, and people are tired of signing up for pre-launch products that might never be delivered. The world is noisier, and expectations are higher. So mockup images or videos are pretty weak vs an actual MVP that you can try. You haven’t solved any pain point for them, you’re just promising that you might do so in future.
I made this mistake years ago, and threw away what would have been a great opportunity. Profitable startups were built with the idea that I rejected, and that could have been me. That could have been my business…
Mistake #2: Taking “Minimal” too Far, & Forgetting “Viable”
The next mistake is taking minimal too far, and expecting people to fall in love with a buggy incomplete piece of crap. Look, people are busy, and don’t have time to look at a broken app that’s incomplete.
Don’t expect anyone to see past the bugs and imagine what could be. Your MVP needs to function properly and solve the core pain point. Users will pull out their credit cards for a basic app, provided that it solves a big enough problem right now, today. NOT maybe in future when you’ve polished your turd of an app.
Mistake #3: Overbuilding (a.k.a., Not so Minimal)
The third major major mistake is overbuilding. And I make this mistake over and over again. Just last week I was working on a simple app to generate qr-code labels for stingless beehives. This is more of a personal project, but I caught myself doing it yet again. My “MVP” was going to have a simple GUI plus a preview of the printable page full of labels.
I started writing a pluggable renderer so that I could generate both the preview and the printable PDF from the same code. Needless to say, this was taking up a long time. Then I realized my mistake. Why build the preview at all? It’s nice, but it doesn’t solve the core problem. The core problem is to print unique ID labels for each hive. The MVP does NOT need a preview pane.
So I ripped out the pluggable renderer code and wrote code to generate the PDF instead. I finished the MVP within an hour or two.
Overbuilding can cost you months of your life building a solution to a problem that nobody cares about. The whole point of an MVP is to find out as quickly as possible if your startup idea is something that the market wants. Every unnecessary bell and whistle that you add to your “MVP” is time wasted, because it delays getting the market feedback that you so desperately need.
I think that this last mistake is the easiest to make, because it’s so easy to convince yourself that unnecessary features are a “must have.” No, your app’s MVP doesn’t need multi-factor authentication, or a fully-featured billing system. You can get away without a self-serve password reset system even if you don’t like it.
At least, overbuilding is the mistake I’ve fallen into most often.
Summary
How about you, which mistakes have you made. Have you thrown away opportunities based on a “landing page MVP?” Did you build buggy and incomplete MVPs? Have you wasted months of your life overbuilding the MVP?
Or, have you made a completely different mistake? Let us know in the comments below.
And remember, your MVP’s job isn’t to impress, but to find out if your idea solves a problem that people care about. Make it small, make it work well, and get it in front of real users ASAP.