As the minimum viable product idea becomes mainstream, I’m starting to hear “MVP” used to justify any minimal effort. It’s great that people want to benefit from being lean and agile, but it’s also absolutely vital that an MVP answers your important questions. There are many kinds of MVPs and most of them are anything but minimal effort. Thinking of an MVP as minimal effort risks wasting the effort completely.
Finding the Sweet Spot
In software we often balance competing goals. I’m going to deconstruct the MVP as tension between three different kinds of questions. Thinking this way helps you prioritize what you want out of your MVPs. It’s more useful than trying to find the sweet spot on a Venn diagram of potential products.
These questions should be asked in the order they appear, but it’s common to loop back and iterate with more specific questions as you learn more about your product. Each kind of question needs an MVP designed to answer it. If you gamble building a single MVP to answer all your questions, you’ll likely spend a long time and learn nothing.
MV: Minimum Viable: Is Anybody Interested?
An MVP sans product is a great way to gauge interest without spending any engineering effort. There are lots of options ranging from an elevator pitch to a landing page sign-up. Be careful of over-committing to details while gauging interest. For example, crowd funding is a great way to validate market size and price points, but if you don’t know how to build the product, you are heading for disaster.
A variant of the MV approach is to come up with a substitute product that would strongly correlate with interest in your idea. For example, a personal concierge service might demonstrate interest in a scalable automated version.
MP: Minimum Product: Can You Build It?
Building a minimal product will definitely show whether the viable product is beyond your capabilities. It will also allow you to predict cost and schedule. In agile software terms, an MP is similar to a spike. On the other hand, testing an MP in the market is unlikely to give you much information because failure of a minimal product isn’t a strong indicator that the viable product will fail. Weak products fail all the time. The more mature the market, the higher the risk.
Be careful of jumping into an MP too soon when an MV would be more productive. Technical founders and organizations with engineering capability are more likely to fall into this trap–we love to build things. Building a minimal product will bring in an engineering perspective, and that can accidentally skew the focus of your questions. Engineers love to talk about technology, scalability, performance and reliability. Engineers rarely talk about whether something is useful, attractive, or valuable.
MPs are sometimes shallow slices of functionality across a feature set. The MP may have an unfinished feel because you are trying to answer a question about your capability, not about the market. Don’t keep working on an MP too long; improving your capability is probably the easiest thing you will do. You must get to a VP as soon as possible.
VP: Viable Product: Will People Love It?
Once you know there’s a market and you have the ability to compete, you must find the product that people love. A minimal, unfinished product won’t do that. A viable product has only the simplicity, beauty and features it needs–you sweat the details to figure it out. A viable product ships as soon as possible–you cut all distractions to make it happen. You keep iterating and experimenting until it works. I prefer the lean approach of testing VPs by continuously shipping improvements, but if you have a Steve Jobs on staff, you can batch up improvements and release less often.
Shipping a minimal effort shows people you don’t love your product. And if you don’t love it, why should anyone else?