Most software ventures fail and they fail because they never solved a problem, to begin with. The Internet has made it easier than ever to start a software business but, at the same time, made it too enticing to create a product that no one needs. For that reason, it’s only rational to first test the waters with a Minimal Viable Product—a reduced subset of a full-blown software. As the well-reasoned logic goes, if people are ready to pay for your rough-and-ready product, there’s decent chance you’re heading in the right direction.
In the recent years, the wisdom of building MVP has become a mainstream guiding principle. But even when would-be entrepreneurs adhere to it, the product ends up becoming more than “minimal”. The recurring theme here is spending time on features that add insignificant value. To create an MVP, a real MVP, there are far more corners that should be snipped before shipping.
Tyler Tringas, co-founder Storemapper, managed to get his first five customers with the code he wrote within 36 hours. He shared his insights in his free micro-SaaS ebook (which I highly recommend). Inspired from his chapter on MVP, here’s handy list of things that you can omit from your MVP:
Multiple users / projects / groups: Single user is enough. If your customers need multiple, ask them to create a new account.
Password Reset: Ask your customers to email you if they forget their password. Maybe send the reset link manually.
Profile updates: Ask customers to contact you for that. Even when Product Hunt had grown mainstream, the only way to update your profile was through Intercom support.
Multiple plans: Maintaining multiple plans implies adding significant code to bill users and enforce the restrictions. A single plan, or a simpler version of multiple plans, substantially prunes the complexity.
Free plans: Free users eat resources without adding any long-term value. Don’t lure them unless you’re sure what you’re doing.
Well-designed landing page: Good design can be influential, but don’t squander your time in making a beautiful one. It’s better to focus on a copy that communicates the benefits.
Multi-page website: Don’t borrow ideas for the website from established companies. You don’t need a team, a detailed contact, or a tour page yet. Just make sure you have a way to be reached.
Automated user onboarding: Don’t attempt to create a fancy onboarding; do it manually over screen sharing.
Live chat: It depends on the context but providing support through live chat is hard. You may not be available, or you may just miss the message. It’s better to have something more passive.
Multiple reports / Drill-down options: Creating an all-encompassing reporting interface is an onerous problem—don’t even attempt it. Only show relevant reports with minimal options.
These aren’t hard and fast rules about creating an MVP but it’s helpful to understand how much you can cut before shipping the first version of the product. I learned the painful lesson last year when we spent more time in adding unnecessary features rather than finding users and in the end, had zero paying users. There aren’t any useful predictors of any software venture’s success, but it’s an irrefutable fact that time spent in selling is vastly more productive than building.