When building a new feature or product, we're always talking about the MVR - the minimum viable release (or MVP - minimum viable product). The MVR allows a team to collect the maximum and best feedback and lessions learned from a new feature, while at the same time putting the least effort into building it.
So, what does this mean in detail?
Basically for an MVR you have to make sure to invest short development time and only low-risk investments, but the MVR of a feature has to meet all functional requirments defined in order to provide any value for the customer.
How to build an MVR the wrong way
- the user has to wait a long time until the feature is being built in a way that provides value. In the meantime the chances are higher that one of the competitors released something similar which solved the problem.
- you get feedback way too late in order to shape the feature
- what if the functionality, the user wanted was a complete different one?
- what if the funtionality, the user really needed was way less than we built (we wasted a lot of time for something nice, not something needed)?
How to build an MVR the appropriate way
- get early feedback for something our customers can use right away. This helps to learn fast and work into the right direction of what is really needed.
- keep the customer happy from the very first version on and improve this version by iterating.
- keept the risk factor to a minimum. If the MVR doesn't adopt, there isn't much time and money lost.
- keep thinking about the Ferrari, while building the skateboard. But make sure the team focuses on the skateboard and the functionalities needed to use it.