Some claim that Minimum Viable Experience (MVE) replaces or supersedes Minimum Viable Product (MVP). While this might be true for some cases, we find that there’s actually room for both.
The best reasons for building the Minimum Viable Product is to test the solution as quickly as possible in the real world. As confident as I am in tools such as the canvases we have covered, there is no replacement for building and testing in the world. It is the quickest and surest way to figure out what you have and whether it is worth building on. Nothing kills a company faster than a product not tested in market. But some argue the era of MVP is over? Is it time for this tried and trusted way of product development to move aside for a new way?
Minimum Viable Experience is lauded as the new way to approach app and product development. No longer does app development look only at the product. The focus has shifted to the experience. What is at the heart of the MVE is the client and what experience would be the best solution for them. Thus, the focus is on building one or two features and building them well. A great example are apps like Uber or Taxify which disrupted the taxi industry. These apps do not behave as tourist guides pointing out special places, nor do they recommend places to grab coffee on your journey. They transport you from point A to point B efficiently, with as little data cost as possible.
My view is that it isn’t an either or situation. One is not better than the other. Why would it be? Both add great value to development and there is no reason why both paths should not be walked to ensure the best for your client and your company.
I believe that some have quickly replaced MVP with MVE without integrating why MVP was important and still is a good app development strategy. MVP is not about putting out a badly designed, average app. It is a strategy, a process of prototyping, data collection, analysis and learning. It is part of a successful product development strategy that ensures the team sees the product as an ever evolving solution to a need that is changing as rapidly as solutions are presented.
One of the challenges of app development is when the development is built on too many assumptions. With MVP, you can get engaged with your user sooner and you can learn, build and measure in a continual loop. I would to also point out that not every MVP should be a massive build. It can be a simple solution that still relies on some product’s functions to be handled manually. Once we have an understanding of the user’s processes, we can build full functionality.
Why we believe MVP is not dead
- MVP is an accelerated learning experience that allows us to tailor app development to the real world and not to our assumptions
- MVP has a low cost to success ratio. If a product is not going to succeed, you learn quickly and can adapt
- At it’s heart, it is about evolution. I sometimes wonder if Kodak would still be around if it had considered its products as MVPs
But, just because MVPs are a great way to test our assumptions, build fast, let’s not throw the MVE out with the bathwater. I believe that once we have an MVP and we enter the learn-build-measure loop, we can move into MVE mode. From here we can, focus on the customer’s experience completely. Map their journey, taking into consideration all of the aspects, not just the engagement with the app. Align your MVP to MVE. Update the product backlog and check to make sure that the product development team is engaged with other departments. Create storyboards to assist with buy in.
It’s not about picking a side, or which is better, it is about the right tools for the right job. At Polymorph, an often used Maslow quote is ‘when you have a hammer, everything looks like a nail’. It is a reminder that the tool must suit the problem and not the other way around. And always feel free to talk to one of us at Polymorph. Finding the right tool is a passion of ours.