Thursday, August 11, 2016

The MVP curse

When I was working in the Services industry, the concept of Minimum Viable Product (MVP) was far away from my dictionary. I basically had projects with a (sometimes) well defined scope that normally had whatever was needed to answer a client's need. Although the triangle of project management has "scope" (also present in the project management star - PMBOK), this wasn't normally a point were we would change: normally, the client would pay for what he needs and didn't want to cut scope.


Now, when working in the Products Industry, it's a different story. The acronym MVP is everywhere. And is one of the most important things to have written in the back of your head all the time. Particularly, if the product you're developing is complex and has lots of impact, the issue is even more relevant. All the time you get pinged with quotes like "it should have this", "it's missing this part" or "users will want this". More relevant, Alpha, Beta, whatever testers will start to throw feedback at you saying "this feature is mandatory, we need it". Even when there's a workaround, they'll say it's fundamental. And that's when you have to stop and rationalize: Yes, I understand that the feature is really important. BUT, should it be part of the MVP? What will we have to leave behind to implement this (because we want to stick to our release date)? This is crucial. If you don't do this exercise whenever some feedback comes in, it's complicated. Your backlog won't stop growing and growing and growing.

So, when you look at a product and think: "Why... why didn't these guys just implement this? It was so simple!". Just rationalize: "It probably wasn’t because they didn't think of it. They just had to balance between this feature or some other very important that you are using."

Why, Why?!