Good-Enough Product: A Guide to MVP for Software Engineers

If we were to learn only one thing from Service Level Objectives, I believe it would be that the perfect is the enemy of good. This mindset could stretch for miles and cover not only the reliability of the software we create but also the development process itself. In this article, I’ll try to share with you my thoughts on Minimum Viable Product, how to fight the urge to create the perfect software (when it’s not needed), and why it’s actually worth creating good enough applications in a long term.

What is a minimum viable product?

A minimum viable product (MVP for short) is such a version of a product, that even though it comes with a minimal set of features, it allows users to use it and provide feedback very early on. It also lets you validate the sole idea and the purpose behind the functionality you’re designing. The benefits are visible with a glance of an eye. You can learn what are the expectations of your customers, on a living, breathing organism, not just a set of questions and theoretical functionalities. And by minimal, I don’t mean that it should be incomplete or that it should be an empty shell. It should give your customers a good grasp of what would be the power of a complete solution, just with a minimal set of features.

Fighting the urge to create the perfect software

Let’s be realistic: every time a company decides to pursue an MVP version of a product, it’s most likely due to the fact that it has to be done in a fast and agile way. There is probably a customer waiting out there for the feature to be released, eager to get it into their hands to give it a spin. This is not something developers like. We’d rather take our time: plan it ahead, create a skeleton, ask for feedback, change the solution, try out new technology, and spend way too much time refactoring. And it’s all good! It shows that we care about the things that we do. We don’t want to create bad software, and there is absolutely nothing wrong with that.

I believe that reality related to business is different, especially when it comes to startups. Modern companies need to move fast, be competitive and react early. That’s why the minimum viable product is a great way to build software. Creating MVP products allows you to share your work with customers very early on, and get feedback as fast as possible. This in return allows you to adapt very quickly, and to adjust your product easily. It’s so much simpler to work on a smaller project, not to mention a situation when a complete overhaul is needed.

Let’s face the truth: creating a full-fledged, perfect solution on the first try is most probably impossible. You need to reiterate, write some code, and see how it does in the real world. This is much easier if you decide to create a minimum viable product and then build upon it. Use it as a platform to take off!

What is the reality?

Creating a good minimum viable product is hard. It could be painful to see an idea having its wings cut off if it tries to spread them out too much. It is (sadly) a crucial, and much-needed step when designing a product with a minimal set of features. There is no place for “nice-to-haves” and “bonuses” during an already lengthy software development process. In this case, you should be trying to cut the scope as much as you can.

It doesn’t mean, however, that you’ll never come back to all those fun ideas! If the product matures a bit, all the major improvements are implemented, nothing is stopping you from suggesting enhancements and in the end, extending the minimal, stable base you’ve built.

Simplicity in software development pays off in the long run. Creating overly complex products is hard for both the author and the recipient. Smaller pieces can be (generally speaking) created quicker and delivered faster. Even though they sometimes might not feel polished and complete, they allow you to see the core value of an application and focus on what’s most important.

Sometimes cutting corners will be necessary, and sometimes you might slip when doing so. It’s a part of a process and those failures are the greatest lessons in agile software development. When choosing an approach for building your next project, give MVP a try! It might become your Most Valuable Product.