MVP or minimal viable product is a term used in a lot of organizations when building a new product or feature. MVP is a great way to get your product out the door quickly and into the hands of users so you can get feedback to iterate and improve the product until you get to a more mature state that has all the capabilities and features you intended to have.
One of the common mistakes a lot of teams make is to take the MVP approach without having defined the final vision or the desired end goal, as well as the user experience (UX) around the final product and what that looks like. To give an analogy of how costly this would be, let’s take an example of a tangible product like a sports car. If the customer experience around the final product was expected to be “A convertible sports car that goes from 0 – 60 in under 2 seconds” and the development team started with a basic MVP of a car that modeled a fuel efficient and affordable sports sedan, then the iterations and changes needed to get to the final product will be costly.
When developing a new product or feature, we need to have a clearly defined UX around what the final product is expected to be. This is not to say that we have a pre-defined waterfall type approach but more to set a direction and have an idea of what the final product should do and iterate in an intelligent manner to achieve the end result. Too often we see teams hyper-focused on the MVP without considering what the final product looks like. They paint themselves into a corner and end up having to re-work and re-architect the solution multiple times wasting costly resources and losing sight of the end goal. This approach is typical of teams that take an inside – out approach when developing products and solutions.
A better approach would be to take an outside – in approach by starting with the problem you are solving, clearly define the vision, user experience and ultimate product capabilities by performing market validation and then work backwards to what a good MVP would be to get into the hands of users to provide feedback so you can iterate continuously towards a great final product without wasting costly resources. Defining an end goal or an expected final product vision does not mean you cannot change course along the way, but it gives you a sense of direction of where you expect to go and allows you to architect your product in an efficient manner, accounting for the capabilities needed as you progress through various milestones towards the final product.