The concept of « Minimum Viable Product » (MVP), defined in Lean Startup, is becoming more and more popular. What should we do in the next release. In Eric Ries book, the answer is two-fold : we should bring value to the customers AND learn as much as possible about our market.

In our projects, the criteria of selection in the minimum viable product is thus :

–          Bring as much value as possible (I mean economical value)

–          Learn, about the future acceptance of the business process we intend to deploy or about risks

We score every user story with a value (from 1 to 10) and we include has much user story as we can in the MVP, based on estimates.

Well, in fact, we score every features, not user story. Some user stories have no meaning alone, and can only be considered as a part of a whole.

Well, in fact, sometimes we split features, because user stories don’t have the same level of priority / of value, and if we really want user story 3.5, 3.6 and 3.8, we can wait for user story 3.7 and 3.9, so they become part of a new feature.

Well, in fact, based on Impact Mapping, we prioritize Impacts we want to have on the way people work (do the closing in one day) more than features needed to have this impact (automate the consolidation)

But that’s not all. Let’s talk about MoSCoW and Kano.

MoSCoW is a classic way to prioritize impacts : Must-Have, Should-Have, Could-Have, Won’t Have.

Kano is a more elaborated way to prioritize impacts: You answer two questions for every user story : “What if we get it ?” and “What if I don’t get it ?”. Based on the answers, you can categorize your features :  basic (I need them but they don’t bring satisfaction), linear (the more I get them, the more I am satisfied) and delighters (I can live without them, but I will be excited if I get some).

Merging both approach, I would say : for an MVP, define Must-Have based on a mix : 70% basic, 20% linear, 10% delighters. Do the same with the remaining features for the Should-Have.

The iPhone was launched without basic feature but with delighters, for instance, and it was a success.

There is a gap between the value of the impact perceived by the sponsor of the project AND the perception by end users. It is necessary to spoil some money on delighters, to get enough adhesion from the end users, i.e. to ease change management.

In summary : a product is a set of features, bringing a set of impacts. This set is built around value, but with adjustments, selecting impacts with a bit more complexity than just taking high value scores only.