Minimum Desirable Product vs Minimum Viable Product

App development, Software Development | 0 comments | by Erin Quilliam

When researching Minimum Viable Products, you might have stumbled across other, similar product management ideas online. These could include the Minimum Lovable Product or the Minimum Desirable Product. The titles bear a strong resemblance to that if the MVP, but what do they actually mean?

The problem is, many of these terms don’t seem to have clear origins or uses. (Unlike an MVP, which is a widely accepted term and product management method.)

An MVP is a tried and tested method and accepted as a legitimate business strategy. Whilst the source and process behind other terms are murkier.

In this post we will examine one method, the Minimum Desirable Product. We’ll break down what a Minimum Desirable Product is, and the differences it has with a Minimum Viable Product. We will also investigate which is a more worthwhile pursuit for your business.

Find out what is a minimum viable product

What is a Minimum Viable Product?

A Minimum Viable Product is a method of product management where a new product is created and launched in as short a time as possible so as to gain validated learning as to the viability of the product.

It is a product produced to marketable quality and able to fulfil a specific need but has the minimum features required to solve this need. Therefore you save time and money in the development process and can launch sooner.

For a full definition of an MVP, you can check out this blog post.

What is a Minimum Desirable Product

What is a Minimum Desirable Product?

A Minimum Desirable Product functions similarly to a Minimum Viable Product. Both are methods of product management and are used to design, develop and deliver a new product and to test a business hypothesis.

Similar to an MVP, an MDP does not aim to be a completely perfected end product. Again, there is a focus on minimising the product’s features, but not to the scale of an MVP.

The key difference is that a Minimum Desirable Product is supposed to be more elaborate. It has the scope for more functions, features and details to try and create a more attractive, desirable product.

It tries to take the thinking behind an MVP and use the least time and effort necessary to create a “desirable” product, rather than viable.

It’s much the same for “minimum loveable product”, which is pretty much indistinguishable from a minimum desirable product.

Andrew Chan defines a Minimum Desirable Product as this:

“Minimum Desirable Product is the simplest experience necessary to prove out a high-value, satisfying product experience for users”

The problem with this definition is that it can’t be easily distinguished from the definition of a Minimum Viable Product.

“But a Minimum Viable Product is the bare minimum!” Some might argue.

Except, it isn’t. Here’s why.

A minimum viable product is not undesirable

Minimum Viable Product Does Not Mean Undesirable

A Minimum Viable Product does focus on only having enough features to solve a problem, yes. Yet, it must still be a valuable product able to please its users. That’s the aim of developing an MVP.

We do not mean that only in terms of the definition of what a Minimum Viable Product is. If a product is not genuinely desirable for users, then they won’t buy it. If no one is interested or buying your product, then it can’t be considered viable.

An MVP has the minimum features to solve a problem, but it still solves the problem. The features and purpose are therefore both viable and desirable. “Minimum” simply means that any additional features and functions are not present initially, but what you have developed is still a fully functional product.

This means if your MVP isn’t getting the attention you thought it would, you might have a problem elsewhere. Perhaps it’s your proposition, creating a product for a problem no one faces. Or maybe there is a mistake in your marketing efforts. 

Should you use a minimum viable product or a minimum desirable product

MVP vs MDP – What Works Best?

Without hesitation, we would say that an MVP is the better product management choice.

This is because if you decide to build an MDP, you could easily lose focus. You are more likely to spend more time and money on developing the product, and might not see any additional benefit for the effort and investment.

That is because, at this early stage of development, you have not yet had any input from users about what they actually want from your product. Your idea of what will be desirable is likely very different from what your users actually want.

You could delay your release by a few weeks to add that cool feature you think everyone will love. Doing so means you spend a large chunk of cash and time on one task. But when your product launches, you find no one actually uses the feature. In hindsight, the MDP might perform no differently to an MVP, meaning you have overspent in your initial development phase.

Lower Risks and Save Resources Using an MVP

Focusing on building an MVP first prevents this situation and wasted resources. The purpose of an MVP is to release the product sooner. You can then gather customer insight and validated learning about the viability and success of your product at the earliest opportunity. If you find people are consistently requesting an extra feature, you can develop it post-launch and add it in an update.

By working in this way, you know that the feature and update are genuinely valuable to your users. It ensures you only spend extra time and money on development with good reason, rather than investing based on an assumption that might not work.

If you develop a product with more features in the hopes of it being more desirable, you will always face a steeper uphill climb to earn that money back. That’s because you’ve invested so much more in the product to get to that early release stage.

With an MVP, you can justify any additional investment you make. Because there will be a genuine demand for the product and features, with the learning to confirm that. Not to mention, having a working product already on the market which is seeing demand for expansion will be seen more favourably by investors.

our conclusion: minimum viable product is the best method

Conclusion

While you might think that an MDP must seem more attractive to users, it also could cost you a lot more. Especially if it doesn’t take off. Although an MVP also runs the risk of a slow uptake, you can lower the risks by spending less time and money in production, and access market validation much faster.

That is why we would always suggest building an MVP first. In addition to the other benefits associated with developing an MVP.

By beginning with an MVP you can push your product to market sooner and validate if your product and business are viable. Once you are certain of this, you can invest in improving and updating the app to become more desirable to your users, leveraging their interest and expanding your audience.

How You Can Build Your MVP

To begin the journey to your dream app, you can book an MVP discovery session and give yourself the ideal foundation from which to build. 

The discovery session is a free guided session that aims to take you through the first stage of developing your MVP. You will also gain access to a host of free resources including the “Magic of the MVP Method: The Secret to Business Success” eBook and loads of helpful videos.

Click here to book your discovery session today.

Tags: , , , , , ,
Image MapDesignImplementAcceptDeployAnalyze
Close

DESIGN

We will prepare the experts, process, environment and roadmap needed to achieve your goals

Close

IMPLEMENT

We will bring together talent, innovation and technology to work on your project's blueprint.

Close

ACCEPT

We will give you quick access to our people, methods and infrastructure to help improve on each project iteration.

Close

DEPLOY

We will execute the solutions to complete your --' project and transfer knowledge, while protecting your intellectual property.

Close

ANALYZE

We will define, study and clarify with you the scope and limits of your requirements.