Many startups start with a Minimum Viable Product (“MVP” for short) or minimum sellable product. But, what should your MVP look like and what should it do for you? Of course, the details of this are different based on what exactly your group does.
However, there are a couple of boxes that anyone should be able to check before releasing their MVP to market.
MVP Philosophies: The Traditional Approach
Traditionally MVPs were developed to validate a few assumptions that the developer has about the customers according to Eric Ries. In these cases, the technology developed is designed for those assumptions in a way that leaves little room for organic change.
That means that the MVP only fits a small and potentially temporary set of users or actions. This can make it hard to build on the MVP to turn it into a more complete and developed product.
That means that when your assumptions about your customers’ changes or you want other functionalities, it can seem easier to simply develop a new application. In many cases, the technology (web applications or mobile apps) of the original MVP is lost and the development for the next app starts from scratch for the next version.
Most of this section has sounded very negative but that doesn’t mean that the traditional approach is never the right approach. Starting from assumptions about your potential users is a valid and valuable first step.
However, it is important to make sure that these assumptions are accurate and that your design strategy is flexible enough to incorporate changes and additional functionalities. This way you can change and add to your original app rather than constantly starting over.
MVP Philosophies: Incremental Improvement
A more recent philosophy on MVP production takes issue with the implication behind the very term “MVP.” Calling a stage an “MVP,” proponents of this approach may suggest, encourages developers to start from assumptions as in the traditional approach with the intention of taking the product to one set end.
The “Incremental Improvement” model says that, in a manner of speaking, your product should always be looked at as an MVP no matter how long it’s been around.
By perpetually looking at your product as an MVP, you avoid the trap of making an inflexible MVP with little room to expand into a more complete projector to change in subsequent versions.
Instead of restarting the product from scratch every time that you want to add or change functionality, you create the MVP so that it is a platform to make experiments.
One very visible example of a company that followed this model with huge success is the gaming platform Zynga. Instead of creating games as individual applications, they created a platform where they could experiment and measure different aspects of games.
This allowed them to quickly and efficiently roll out new products without starting over each time. It also made them free to scale their product to a much larger platform than was initially intended.
What to Do with Your Successful MVP?
So, your MVP has met your goals. Now what?
Whether you go with the traditional approach or the incremental improvement approach, the next step is the same. in many cases, when an MVP is being developed you may not consciously choose one philosophy over another.
The next step should involve going back to what you planned to do before you started planning your MVP. If you create your MVP as if it is meant to exist in isolation from what you do in your larger projects a couple of things can happen.
For one thing, people will likely have a harder time finding your product. Then, no matter how well it is designed, it won’t serve your target users.
Further, if your product doesn’t serve your target users it won’t serve your larger organization. That means that all of the time, energy, and resources that you put into your MVP are doomed to never pay off.
Any time that you make an MVP, you should treat your MVP just like you would any other initiative that your organization takes on. That means giving your MVP the time and budget that it needs and deserves to become a fully-functioning product.
It also means keeping an eye on the product even if you consider it “finished” after it becomes available to the public. Promote your application through your organization just like you would any other event, product, or service that your organization wants its customers, clients, and wider audience to know about and take advantage of.
Once again, taking this attitude will help both your audience and your organization get the most out of your application.
Revisiting MVPs
Revisiting the MVP stage can take two basic forms which can be but are not necessarily related to the MVP philosophy that you took initially.
If your new MVP idea is meant to offer a drastically different functionality from your first MVP, it may be easiest and cheapest for you to start over. This can also be the case if you took the traditional approach to your first MVP, making it difficult to change or add to.
This doesn’t mean you need to forget all about your original MVP. Even if you’re starting over from scratch you will probably have some content from your original MVP that you can reuse.
This could be digital artifacts like images, custom color schemes, images, &c. Much of the usability research that you (hopefully) conducted while working on your original MVP will probably carry over as well.
If your new MVP idea is an expansion of your original MVP or the goal is adjacent, you should be able to create the new MVP as a new edition or addition to the original project, potentially saving you and your organization time and money.
This is more likely to be the case if you created your initial MVP with the Incremental Improvement Philosophy but even if you went with the traditional philosophy you may be able to reuse the original MVP as a building block or stepping stone to your new product.
