Minimum Viable Misunderstanding

Say what you want about Agile, but the concept of MVP (Minimum Viable Product) is very sensible. Yet, in SAP projects, we don’t always see it embraced with open arms. Why?

The main idea behind MVP is to do the least amount of work possible to get useful feedback from customers. This sounds great if you’re working on a mobile banking app, for example. You want customers to be happy with the app and are interested in what they have to say about your creation. In the SAP world, let’s be honest—there is usually very little concern about what customers (which we call “users”) think about the result. Because what are they going to do, find another job? HA!

Also, pushing an MVP out to get feedback only makes sense if you actually plan to act on it. And despite having all the Agile decorations, SAP projects very rarely end in a real iteration cycle. Something gets delivered, and the project team quickly gets disbanded and goes back to routine work.

This leads to another problem: defining an MVP in the first place. When business folks hear about MVP, they mostly hear the “minimum” part and not the “viable” part. “What do you mean we’re getting a minimum?! This project is costing us big bucks!” The result is never-ending additions to the “product” and a go-live date that rides into the sunset. We tend to forget that “done is better than perfect.”

So, how do you get out of the Land of MVP Confusion? I think the solution is as simple as applying the MVP concept exactly as it was intended: balancing “minimum” with “viable” and having an honest intention to follow up with improvements. JP