A popular catch-phrase in the agile development world is MVP or Minimally Viable Product. It was great idea when I first heard this phrase many years ago when I first started working within an agile environment.
“Keep everyone focused on what is actually needed! Speed up development! Reduce time to market! Get feedback fast! Get it out then, then iterate!”
These were all things that I heard over and over again and it was great at the beginning. I believe that the end of the traditional development process where teams nail down every single requirement at the front-end is near. This process depends on designing to a requirements document that was written 1-2 years prior just to find out that what they developed is no longer desired — it is a concept of the past. We must adapt to this changing world where:
- People want to be part of the design process hence the success of Kickstarter, Indiegogo, crowd-sourced apps, etc.
- People want updates really fast. We’re not satisfied waiting years for new versions of products.
Agile processes work particularly well for software development because code can be split up. It can be structured in a way that features can be worked on independently and tested without affecting the rest of the product. Before serious resources are devoted to production development, it is important to define what the initial feature set will include in the product launch. Understandably, the product owner may want every feature inside of the app because they’ve heard customers say that they will only use this app if every feature available to them. Practically, this would be possible if you had unlimited time and resources. But we live in a world where there are expectations that we must deliver and we, as designers, need to provide the most value with the investment we put into the work. Therefore, we need to define the basic feature set that will provide the most value at launch in order to be successful, or at least gain traction.
If we define a minimally viable feature set, this implies that the end product will just be viable. Now, if we take this word and think about where else this is used in the world — it’s usually referring to objects or ideas that are barely living and we’re questioning whether it is still alive. Is that what we really want our products to be perceived as? Hanging by a lifeline? Barely able to stand on its own? Obviously, NO.
We want to create great products that excite users, that begin to create an emotional tie that makes users want to come back again and again. In essence, we want people to become “addicted” to our product experiences just like many are to Instagram, Facebook, or SnapChat. How can we do that when we are building the minimally viable product?
Let’s reframe this by calling it the Minimally Awesome Product.
Immediately, this changes your perception of what the end product will feel like. If it’s not exciting to the team developing it, it probably won’t be exciting for the person using it. The feature set that is defined may be very similar but what might be added or removed from the backlog to create a simple, awesome experience that will leave a positive impression to the user that will bring them back for more? It’s a simple change in our mindset, but it has a significant impact.