It is very important to have a broad set of competencies to get the end benefit from the software produced in a project. The competences have to fulfill the Three Pillars of Innovation – Viability (business), Feasibility (development), and Desirability (design). The business analysts have to find out how profitable the solution is while the developers have to find out if they actually can build it and at the same time, the designers need to know if it is desirable enough. All of this together forms the value of the product. This value can in most projects be found over time, but at that moment it might be too late since the world out there is constantly changing. Naturally, it is really important to find out early if your product is what people want.
To many agile teams, this seems like an easy task. Incorporate the UX-guys into the team, make them follow the same methods, as I’ve written so many times. Just build it and test it. Instant gratification. But Anders Ramsay says (and so do I) that the UX designers’ biggest mistake is to think that methods like Scrum or XP are synonymous with Agile. He argues that those methods were created by and for developers to solve developer problems and to create high-quality efficient software. That is one form of value, one form of quality, but not the whole story that makes the customer want to buy our product. We designers need to look towards what actually creates value in the long run, and with that, desirability.
Enter the Minimum Viable Product (MVP). In product development these days (and now I am talking about the business side) the MVP has emerged to find out if the customers are the least interested in a new product. A minimum viable product has the exact (not least) amount of features to make it desirable and sellable, thus giving value. It is created to maximize learning. The all too common approach to using an MVP is what Brandon Schauer calls a dry cake.
First, a cake is created, this is a product that has the minimal but complete usage flow with a minimal but complete technical framework. It is nice, it is a cake. It shows that the product is feasible. It might say something about viability, for instance showing the cost for the developers to add a feature. It might also say that the interaction design is good. It is easy to add filling (features) since we have both the design and the technical frameworks. Sales persons will probably argue that to make it sellable it needs this and that feature as well, adding items to the feature list on a daily basis. What is missing is the icing. So, somewhere along the line, we find what is the icing, what makes the product desirable and interesting, but as I mentioned earlier, this has taken way too much time. We need a better approach, we need to use a real MVP.
Let’s start with creating a cupcake instead of a dry cake without filling and icing. The cupcake has filling and icing, but not so much compared to the cake. But, the cupcake is something that the customers want, need and love, so you can start measuring how much and if it is viable to produce.
After that you can easily expand your MVP to become a cake with filling and icing. And since you then know that you have a feasible, desirable and viable product, you can easily expand it to become a wedding cake. The only thing you have to remember is that less is more.
Ha Phan adds that the original intention of the MVP was the smallest nugget that matters. Not a cupcake but maybe tasting samples. I would add that the MVP should be the minimum thing that can validate your hypothesis and that could be easily thrown away if it does not taste good.
(addendum: The MVP is dead, long live the RAT)