Quality of Minimum Viable Products

The common misconception that MVP equals low quality

A Minimum Viable Product (MVP) is a crucial concept to build a successful new product. However, there is a common misconception about this term. MVP is often seen as a product with basic set of features and with low-quality. Therefore, companies consider that they need to choose between building an MVP or a high-quality product.

Unfortunately, this misconception makes many companies (both startups and established brands) averse to the MVP approach. They avoid going the MVP route because they don't want to damage the quality of their product or the reputation of their brand.

What is actually quality of a software product?

Before we talk about quality of MVPs, let's first explore what software quality actually means?

Software quality refers to the degree to which a software product meets specified requirements, customer expectations, and industry standards. It encompasses various quality characteristics, such as performance efficiency, reliability, usability, security, maintainability, etc.

This means that software quality is not limited to the absence of defects only, but it is about the overall user's experience with the system, how easy it is to use, and how it performs in different environments and situations.

For example, a software application with high number of defects is considered to be of low reliability. However, reliability is just one aspect of software quality. Even if an application is completely defect-free, it may still have other issues, such as slow loading times, which indicate poor performance efficiency. Similarly, the software may have a high level of complexity that makes it difficult to make changes and maintain, leading to low maintainability.

MVP is NOT about low quality

The MVP approach was introduced in detail by Eric Ries in his book "The Lean Startup". But in the book Eric never explained MVP as a minimum product from quality point of view. He did not talk about cutting corners during product development, leaving defects in the software and launching a software of poor quality.

The idea of MVP is to think "lean" during product development and to challenge yourself on how to deliver high value with minimal effort and how to maximise the amount of learning during this process. (I've explained in my previous post the concept of MVP in detail).

But even if you deliver a "Lean" product, it needs to be valuable for the user, and even more, it needs to stand out from the competition and delight the user. Otherwise why would the user choose for this new product when there are already other alternatives.

Low quality MVP can be harmful

Delivering a low quality product comes at a risk.

First and most important, a user testing a buggy software would unlikely be delighted. The low quality will lead to damaged user experience, and would hinder the user from seeing the real value of the product.

Low quality is also very harmful for the product development team. Although you might benefit from launching the product faster, this is only a short term win, and over time, ignoring software quality means accumulating so called technical debt, i.e., technical issues that should be fixed at some point.

Maintaining a good quality software is like keeping a house well maintained and tidy. This requires fixing small issues right after they occur, keeping it tidy continuously, and establishing a system or a process to help you keep everything tidy. If you just keep things polished from outside and you hide all the damages and clutter, all issues would accumulate over time. At some point you would need to spend so much time and even money to bring it to a desirable level.

How to approach quality in MVP

Understand what are the quality criteria for your early users

When building a Minimum Viable Product (MVP), the importance of software quality depends on the specific context and goals of the product. While a high level of software quality is always desirable, the MVP is designed to test the viability of the product idea with minimal investment of time and resources. Therefore, it may be acceptable to compromise on certain aspects of software quality in order to deliver the MVP quickly and cost-effectively.

However, before you compromise on any quality aspects, you need to make sure that this is not going to be harmful for the user experience. So it's crucial to identify the key quality criteria that your early users expect and focus on those.

Which are the quality criteria for your product? This can be very different and depends on the type of your business and the expectations of your early users. Evaluate all the quality criteria and consider how much each of them is important for your product at this stage? Questions to consider include:

• What do your users value most?

• How tech-savvy are your early users?

• Is there any critical data your system is processing?

• What is the business impact of a system failure?

• Would a great UX design be the key differentiator for your application?

For example, if you are building a software application for online-shopping, and you discover that your competitor's disadvantage is poor performance, performance becomes a high priority for your product.

Good UX design is typically an important criterion for most users today. However, if for example you are building a highly innovative software product for medical professionals, users might value more the accuracy of the tech algorithm than the UX design.

Define measurable quality requirements

Once you have your key quality criteria, it's a good practice to define concrete measurable quality requirements. These requirements should then be treated in the same manner as the functional requirements (the features), which means that with every release of the software, the product development team should ensure that these requirements are met.

For example, if performance efficiency is you key criteria, a requirement might be defined as "every page should respond in maximum one second".

If Usability is a key differentiator of your product, you might consider a measurable requirement like "the user should be able to purchase the desired product in no more than 3 steps".

When these characteristics are measurable, you can also monitor them and improve over time.

Select the right technology and architecture

The key quality criteria that you've selected drive many decisions in the product development. And one of the key decisions is the selection of the technology and the architecture foundation.

If you have chosen a short-term technical solution (such as a low-code platform that you plan to use until you have a proven business model and you plan to rebuild before scale), the decision you make now would not have a significant impact.

However, if the software you build now will serve as a foundation for the long-term, selecting the right technology and architecture is critical. This includes selecting a foundation framework (potentially a commercial off-the-shelf software), or choosing a frontend, backend, database technology, or specific payment technology. Making the wrong decision could result in the need to fully rebuild the software in the future, which is definitely something you'd want to avoid.

Integrate quality best practices in the development process

An important practice is defining quality coding guidelines, particularly when working with multiple software engineers. These guidelines help ensure that everyone on the team is working towards the same level of software quality.

In addition, integrating automated testing is another important practice that can greatly increase the reliability of the software while also improving the efficiency of testing. Automated testing helps catch defects earlier in the development cycle, allowing for quicker identification and resolution of issues.

Conclusion

Software quality is as important as is the functionality of your product. Even when you are introducing your product to the early users, quality should not be sacrificed in the pursuit of building an MVP faster.

While you should not invest in the most advanced software quality tools or make the software extremely reliable or scalable, a satisfactory level of quality is needed. This will ensure that the user is able to see the real value of your product without hindrance.

In his book"Designing for emotion", Aaron Walter introduces different characteristics that a product should have. Great products are not only functional, but are also pleasant to work with.

MVP is not about implementing partially features only, and ignoring everything else. Instead, an MVP is about implementing a satisfactory level of everything that matters to the user, including both functionality and quality.