MVP vs MDP

A frequent point of contention when developing new products is just how many features should be implemented before the product can be rolled out the door. While the specific meaning and implications of "MVP" have been done to death by thousands of other writers, I'm going to attempt re-iterate the need to distinguish "Minimum Viable Product" and "Minimum Desirable Product." These two terms are frequently at odds with one another, with MVP more often than not being used when MDP is the intended term.

I'll start with two somewhat subjective definitions:

• Minimum Viable Product - The actual minimum product necessary to test assumptions and potentially prove the existence of a market
• Minimum Desirable Product - The smallest possible feature set product owners are willing to launch with

Product owners often begin using "minimum viable product" in sentences after having read The Lean Startup, guessing at the intent of the book while completely missing the point: that an MVP is almost always more duct tape and bailing wire than it is automated software and polish. I've seen people un-ironically use the term MVP when explaining that a given product can't be launched without 90% of the overall road-mapped feature set. This is where "minimum desirable product," or MDP, is the better acronym. Your product owner is essentially telling you that the product isn't viable without the majority of the vision.

Put differently, I believe the hesistation to equate MDP with MVP stems from the word "incomplete." One needs to eliminate the word "incomplete" from any conversation regarding the MVP. The MVP can't be incomplete; it's precisely the set of features you agree to build. Unfortunately, it's hard to change this mindset once it's established, largely because it's difficult to put your name on something that is invariably going to look so utterly unattractive. You yourself may find it hard to believe that anyone will give you money for the MVP. However, the ability to scrap a misfire early is worth its weight in salaried developer hours. It's your responsibility to try to convince the rest of your team and your product owners that it's in their best interest to release early and iterate. The only feeling worse than releasing a broken product is releasing something no one wants, and we've all been there.

I recently worked on a product that involved developing nearly every feature on the roadmap before it was considered launch worthy. Meanwhile, my team argued that the product could have been represented by a handful of scripts and some manual labor. It sounds scary to ask customers to pay for a patchwork mess but the upshot is we could have launched a workable solution in under a week, tested our assumptions, conversed with the customers to figure out the next steps and most importantly proven it can work at all. Instead, we spent months in meetings building a nearly finished product and it could have all been for nothing. At the time of this writing, we still haven't launched the feature, so the outcome is unknown!

You've likely experienced the alternate form of this problem: you start with a manageable workload and then the product manager scope creeps with "edge cases" that end up being features in disguise. Unfortunately, if this happens, it's probably your fault: you should have been working with the product manager and gotten him or her to agree to a fixed contract and timeline. The product managers job is to remove chaos, but he or she can't do that if you aren't taking the design portion seriously, including estimates of well-defined features.

The ability to release early is the sign of both a mature team and a product owner willing to put the product itself ahead of his or her own ego. The MDP has to look as close to the MVP as possible, lest you risk wasted time, money and sanity. It's your job to convince your product owners that it's in their best interest to release early and add polish later.