By Nathan Weir , Project Manager for Rose-Hulman Ventures
At Rose-Hulman Ventures, we build solutions to make our clients’ dreams become reality. These solutions can take many forms, from a quick and dirty prototype to a bells-and-whistles finished product. However, often the format of the final deliverable is up for debate. If your secret sauce is a risky idea that could use some proving out before going to market, then a proof-of-concept prototype could be the best next step. But, if you’re confident your product is sound and you’re ready to enter the market, we at RHV urge you to think Minimum Viable Product, or MVP.
But what exactly is an MVP? A simple definition is that an MVP is a product that contains only the minimal features required for shipping to market. But let’s drill in to each piece of the name in order to construct a more complete perspective:
Essentially, an MVP design results from applying reductionist thinking to what your product ‘is.’ Here’s an example.
Imagine that you’re looking to launch a restaurant review app on the Google Play store. You know that, at a minimum, users should be able to record that they have dined at a restaurant, assign it a score, and then write a review. Here are some questions that might arise during the design process:
And so on. When designing an MVP, the engineers and product owner must ask themselves, “Do I need this to sell my product?” The key word is ‘need.’ Do users need to be able to sign in? Yes. Can users pay for premium accounts? Not necessarily. If your business model requires payments, then, yes, this is an MVP feature. If not, then no. There is no middle ground!
Clearly, this is a difficult process that requires frequent reanalysis of business needs and product viability. So, to help drive thinking on how to build a good MVP, let’s take a closer look at why building an MVP is so important in the first place
One of the key insights that lead product owners to choose MVP-first development is that sending even a supposedly finished product to market is a daunting challenge. No matter how prepared, deciding to press the deployment button immediately brings to light a host of concerns:
And so on. Now, imagine the size of that list when you’ve built your app over a period of years with all the nice-to-have features imaginable, as compared to a slimmed-down, biggest bang-for-buck MVP developed over a matter of months. Every additional, unnecessary feature, usage pattern, option, and configuration adds another tool that can break, or process to support. You might easily find yourself struggling to tread water in a sea of error reports and customer complaints!
More crucially, imagine the worst-case scenario—your product underperforms on the market. If a large-scale, bells-and-whistles goliath fails, can you really be sure you should blame the core product idea? With an MVP on the other hand, you’ll often find yourself with more decipherable, actionable data points that can be used to tweak your product into a stronger version Number Two. And, since your product is minimally complex, preparing for a follow-up launch will take much less time than otherwise.
And at the end of the day, what’s preferable: sparing no expense to release a “perfect” product that underperforms, or shrewdly designing a focused product that earns revenue? When launching your new product, an MVP may be your Most Valuable Player.