Software Design

Minimum Viable Product: Good Idea, Poor Execution

computer

 

There’s a process for software development called Minimum Viable Product, better known as MVP. When executed correctly, it should help teams mitigate risk by keeping focus on core functionality, avoiding unnecessary features. You take limited releases and get them in front of your users so they can test the viability of an idea. Sounds good, right? But what happens when this process is overprescribed, and you find yourself on this path for everything you do? If you’re testing truly unique ideas, then MVP makes sense. Truly unique is truly rare, though. What I have seen launched in the name of MVP are immature versions of products that were developed to compete with functionally mature products. And many things can go wrong.

If a user has invested in your product by taking the time to learn about it, downloading it, installing it, and exploring it, only to reach an impasse by finding out something they wanted to do is completely absent, you have violated their expectations. You have wasted their time, and people will judge you negatively for it.

Once a judgment is made, the belief may persist long after it is disconfirmed. Years ago, Hyundai motors made really bad cars, but I can’t remember the details that made them so bad. What I can remember, however, is that my family had a negative experience with a Hyundai more than 20 years ago. But the memory of my dissatisfaction has outlasted more recent information to the contrary. I am still unsure about Hyundais even though I have read nothing but good reviews about them lately. My negative experience has turned into a negative bias. I was done with Hyundai because they screwed us once, and I don’t care if they make better cars now.

MVP makes the assumption that users understand that digital products will evolve over time and get better. But the average person doesn’t think that way. Amazon.com is constantly evolving and releasing updates, yet I have talked to people outside the industry who are surprised that Amazon has more than one designer, or any designers at all because, “Isn’t the site already designed?” The here and now is when most people make a judgment.

When I first engage with a product, it will be the strongest impression I will get about that product. Apple knows this. Consider the care they put into packaging. As you unbox that shiny new iPhone, you are taking ownership. Your first experience is with packaging that is beautifully crafted, because Apple wants to amplify the strong emotional response that accompanies taking ownership. They know you will tell other people how amazing it is, and in turn, those people will go buy an iPhone. Conversely, ever buy something at the store, take it home, and unwrap it only to find out it’s missing some of the pieces? How does that make you feel?

The half-baked version of your software called MVP will lack beauty, craftsmanship and delight. Those attributes make great experiences that people care about and come back to. Those attributes count because they communicate quality and much more. Why would we ever subject a user to incomplete work? If we are doing our jobs and focusing on how to solve real problems, we should forget about the idea of an MVP. There are a myriad of ways to test a product before going live that will allow you to build and validate ideas. Sure, work on the core features first, but keep going. If you push the product out too soon, know there can be material damage from an incomplete experience. And we should be striving for nothing less than a great experience.

Advertisements