A minimum viable product (MVP) is basically the bare minimum requirements and functions that your product would need to fully be able to go live and take on real users. This, in turn, allows the users to have an impact into how they best feel they can benefit from your product from the beginning. It would be pointless to develop a product that your users would then hate to use.The reason that this is an important step, and the way we want to work, is because having this kind of feedback at the initial stages of a product is better than building a full product that won’t appeal to the users or not only in the technical features but also in the reasoning behind why they need to use it.
Having a minimum viable product also helps in the long run to cut costs associated to new versions and full UI or UX changes that might come from the feedback. In the end it’s easier to fix a small problem than a big one while also strengthening the foundation in which your product is built on.
The original process for development puts all the testing and improvements to the end of the line, which can be a tricky situation, mostly because you have already developed your product fully before it is tested. This leads to wasting time and resources to fix something that could have been developed that way from the beginning. These problems are the reason we reversed the process and put all the testing and research at the beginning.
There are a few handy tools which we use in order to fully find what the MVP would be for every project during the design sprint stage:
- Reverse Pyramid
- Impact / Effort Graph
What is a Reverse Pyramid?
A reverse pyramid is a tool that helps provide the key elements needed for a Minimum viable Product. As the name states, it is a reverse pyramid, with the bigger end on top and the smaller one at the bottom. The reason for this is because when designing apps or websites it is important to focus on what is necessary and not that is wanted. Don’t think that what you want won't be on there, but there are other key features and decisions that come before adding gifs to your homepage.
Need to have - Must have features, can’t function without, key service offerings.
Want to have - Features that add to the substance, non-essentials that help with service offerings.
Like to have - Extras that are not needed for a full product. Most of these include gifs, animations, Easter eggs, fun and out of the box things that make your product fun and outstanding. This is definitely something we can add, but not feasible in the first few versions.
What does it provide (outcome)
The reverse pyramid also provides the backbones of defining the MVP. By taking the first two steps, need to have and want to have, you can get all you need to be able to produce a successful MVP. Having these well defined is already a great step towards having a working prototype which provides an incredibly solid base for your project.
How We Use It
The pyramid is used when there are no other ways to find your main factors and features your product needs in order to work at a minimal pace. Therefore the reverse pyramid is used during the design sprint. Having this tool has allowed us to make sure that the app or website includes all the necessary factors and that they are approved by everyone involved. Allowing this to be done within the design sprint is also a great way to solidify many important steps in as little time as possible without losing any of the impact.
There are many ways to find these features that go into the different steps in the reverse pyramid, and the main one we use here at Mäd is an impact/effort graph.
How to build the Mäddest impact vs effort graph
In order to build and effort vs impact graph it is important to go through the initial steps of the design sprint (if you are unaware of these steps, please refer to our design sprint article [here]).
Having these steps out of the way and accounted for the different needs for the product, it will be simple to fully see where each feature or step goes into the impact vs effort graph.
Take the most voted on features and review with the team how much impact one by one will have on the end product (MVP in this case), then how much effort it will take to add it into the MVP. For example, adding a tracking feature for delivery drivers in your food delivery app is something that can have a good impact on the reception of the app, however the effort to add this is immense as well as logically it is not something that is essential for the app to work at the lowest level. In reality all you would need is the list of restaurants, a cart, a checkout, and a step by step notification of how the food is doing. The geo location of the driver would be then, given its high effort and not so high impact, be in the last step of the pyramid (Like to have).
Why is Having a Solid MVP is a Must Have for any Web and/or App Which is at Its Initial Stage.
Having a solid MVP is key to how we work and how we can confidently tell our clients that we build impactful and great work. We don't wait to have a fully functional app or website with all the features and specs clients want to have. There is no real reason to have a fully functional product if when it goes live we have to change 50% of it due to user feedback. Our approach allows us to roll-out a product with the minimal features needed to run and provide its main function. This is then tested with the different users and we receive the feedback and then structure or mold the following versions towards how the users would rather it be. This will in turn ensure that the users are happy using your app and allowing our clients to differentiate from their competitors by tackling all the problems that users might have with other products not tailor made for them.