Reid Hoffman, the founder of LinkedIn, famously said, “If you are not embarrassed by the first version of your product, you’ve launched too late”. If you take this philosophy on board, your minimum viable product (MVP) may well be the toughest software release you ever do.
In a nutshell, your MVP includes the absolute minimum functionality you need to get your product in front of your customers.
Some businesses struggle with this because they feel that a specific feature is a “showcase feature” and sets the product apart. I advise clients to think long and hard about developing these sorts of features. They are usually expensive to build and often your customers will not find them as important or impressive as you expect.
Other businesses think releasing an “unfinished” product will give potential competitors a whiff of what they’re trying to do. While I can’t comment on the ruthlessness or perceptiveness of your competitors, I will point out that first-mover advantage is of little use to you if you don’t have the funds to maintain momentum because you’ve blown your budget on your full-featured system and if you take too long you might not be the first to market anyway.
My overarching observation is simply this: every piece of functionality costs you money. Don’t build it until you know you need it. Here are some practical examples of getting your product down to MVP:
- Do people really need to log in to your system? Can they do everything on your website instead?
- You don’t need a password-reminder system. Have the page send you an email and you can go into the database and generate a new one yourself and email the customer back.
- You don’t need a contact form on your site – include an email address instead.
- If your product has a back-end system which you use to populate a database (e.g. registering new products in your eCommerce system), you probably don’t need to build forms to manage it. Just ask your developer to insert the information directly into the database as required (usually a quick and simple job).
- Don’t build a system to serve 100,000 concurrent users if you’ve only got 100 to start with.
- Don’t worry about a flashy landing page or introduction video.
However, there is one place where you should not rely on the bare minimum: your software architecture. As your MVP will serve as the base for version one, your architecture is the foundation for all future development. Your developer will have good tricks for “stubbing our” or “mocking” functionality which you don’t need for your MVP. This mean that they can prepare your system for expansion later without actually implementing it now – giving you the best of both worlds.
Any shortcuts you make on your architecture during the MVP will cost you double later on because you’ll have to pay to undo them as your system evolves. If you’re strategic about what you build and where you invest, you can gain any first-mover advantages while having a good foundation for future growth.
Ben Liebert, Founder, Blackball Software
