(Originally published at InfoWorld.)

I prefer to write about things that have either not been written about previously or where I think that the value is still being missed. This article is the latter criteria, given that the term Minimum viable product was coined in 2001 (according to Wikipedia). Like many patterns and processes related to technology there is more to the use of MVP than the name implies.

Minimum is for targeted effort

The M in MVP is often misconstrued as the minimum to go to market at the start of the effort though it is more suited to the end of the effort. The definition of minimum should evolve through the life-cycle of design and development.

If you will accept that all functionality is moving something from one point or state to another, then absolute minimum is being able to get from start to finish. So at the start of an iterative design and development process for a feature or product this should be the first goal and go no further until the results are reviewed by the product owner and/or users. Another way to look at the first value of minimum is sufficient for demonstration and discussion.

Once the absolute minimum has been achieved, then the additional criteria can be added in. The additional criteria are going to be beyond the bare minimum to accomplish the change in value or state, of which there can be many such requirements. These requirements must be prioritized by the key stakeholders and then delivered singly unless (in very rare cases) multiple requirements are inter-dependent. The reason the inter-dependency should be rare is that the requirements should be stand-alone. They may need to be done in a particular order, which should be considered when determining the priority.

In a recent design session where a new feature was required for call center users to follow a script and record responses with the script branching at points based on answers through the process. There were some participants that wanted to start from the assumption that this functionality would be re-used in other processes and start with a generic approach, even though the expectation was that any such reuse would be far in the future. It is important to acknowledge the potential for reuse and avoid approaches that will prevent it or make it overly complicated. That said, it adds nothing to the initial solution to genericize without knowing what the future requirements are. It only adds to the level of effort in producing the first MVP for stakeholder review and getting to the first production-ready MVP. In this case the difference would have been a couple of weeks in a project already behind schedule.

Viable must be based on agreement

I can think of several well-known enterprise-technology products that have a terrible user experience. For me, personally, I feel they miss being optimally viable, though I have to admit they are minimally functionally viable. That said, I’m neither the product owner nor the key stakeholder (let’s admit, that is the person paying for the license and not the actual user) and cannot honestly say whether the standards of viability were met.

The most important part about the previous paragraph is acknowledging that it is not my role to determine viability. I can (and should) provide my input about what I think is important about viability, but the ownership belongs to the product owner and (sometimes, and maybe not as often as it should be) the key stakeholders.

Another area often forgotten about viability is from the other side of the coin. The product must be maintainable. Product owners often insist on functionality that is difficult to maintain. In some cases, this is an acceptable trade-off and in other cases the maintenance cost out-weighs the business value and that impacts viability from anyone’s point of view. My experience is that product owners asking for high-maintenance features generally do not know that is what they are asking for, and that often times it is the timeline more than the possible solutions that make it a maintenance issue. Delivering products using an MVP design approach is also about continuous communication between owners, designers and developers. If any one of those roles works without both giving and receiving input, the project is in peril.

Product should be plural

Because minimal is an evolving criteria and viable is the result of consensus, a single outcome, i.e., product that is shippable on the first iteration is extremely rare, with the possible exception where the product is a very simple addition to an existing product.

By willing to iterate and refactor, each version of the minimally viable product will be better until it at least reaches the level of minimum where it can be delivered.

Minimal valid postscript

Does the Minimal viable product approach described here sound like other approaches? Agile come to mind? Most good approaches have similarities. It is exceptional when they do not.

A lot of this depends a bit on “perfect world” scenarios. In the real world, sometimes the work needs to forge ahead with assumptions while waiting for stake holder review. This is where source control management comes in to play. The important thing to remember is to not become overly-fond of assumptions as they may prove incomplete or invalid after the stake holder review and input. This could even happen frequently with new teams, but as the product owners and producers continue to work together, the gaps will become fewer and fewer. Again, I caution to avoid complacency as those gaps narrow as the will rarely go away completely. The goal for all is best functioning product that can be created given the capabilities available, even if that means the occasional solution refactoring.

The only difference between technical debt and financial debt is that costs are more often known in advance when taking on financial debt. Both types of debt are a tool when used intelligently with purpose and a plan to manage it and can take a devastating toll when used recklessly or imposed through misdirection or miscommunication.

Acceptable vs unnecessary debt

The original heading here was “Necessary vs unnecessary debt”. On further reflection, though, I realized that the only good reasons for incurring debt are time drive. If time is removed as a factor there is no reasonable need for debt. So then it becomes a question of when time is important enough of a factor to make debt acceptable. The only context I can think of where time is universally an acceptable driver for debt is in an emergency situation.

Beyond an emergency, the evaluation for whether debt is acceptable because of time becomes a value proposition. In our personal lives, the first car and house is generally considered to be a good reason to accept debt because both have a large enough cost where they are likely to become more expensive over time, making it harder and harder to save for them in a reasonable period of time.

Similarly, building in-house custom applications rather than waiting for a Common Off The Shelf (COTS) solution that will incur technical debt in minimally reviewed code and the inevitable maintenance costs is worth it for functionality that is key to business value. Having worked for software vendors, I can honestly say that it if it isn’t already Generally Available (GA) as at least a patch one then it should still be considered unavailable as a COTS solution.

The other common time driver that should generally not be an acceptable reason to take on debt is impatience. Using a home equity loan to buy the latest television is a poor financial decision and implementing a new solution without a thorough evaluation and proper training is a gamble that will usually result in higher maintenance cost or a potential system failure.

The old adage “patience is a virtue” is not only true, it is a vast understatement of the value of patience.

Stop debt before it happens

The reason technical debt is becoming an increasing concern at many companies is because it tends to grow exponentially, just like financial debt. And for the same reasons. Of the three drivers for debt mentioned previously (emergency, long-term value, short-viewed impatience), the most frequent cause is the least necessary. Impatience. Problems arising from bad habits will grow until the habit has been replaced by actions that have a more positive effect.

Without getting too psychological here, impatience is a result of either wanting very much to move towards a reward or away from loss. For some odd reason, the drive forward doesn’t seem to repeat in the same context nearly as much as the drive to move away from. In technology, the drive to move away from is so common that the three key emotions related with impatience driven by escape have an acronym: FUD (fear, uncertainty, doubt). In the case of IT decisions all three are essentially redundant, or at least a sequence. Fear driven by uncertainty and/or doubt. When the decision is around taking on technical debt, the fear is that business owners or customers will be upset if the feature is delayed or reduced and the uncertainty and doubt are the result of either not asking these stakeholders or asking only half the question.

Asking a stakeholder “Is it a problem if feature X is not in the release?” will frequently have a different answer than “Would you prefer we include feature X in a later release or risk certain delays to all future feature releases by pushing it before we have time to include it in a maintainable manner”? My experience is that most of the time neither question is asked and it is just assumed the world will end if users don’t have access right now to a new option that only 3% will ever use. It is also my experience that when the tradeoff of reliability and stability versus immediacy is explained to stakeholders they usually opt for the delay. I know many people believe that businesses have lost sight of long term implications and I believe that in many cases it not because they are deliberately ignoring them but because the people that should tell them when and why to be cautious are afraid of saying anything that will be considered “negative”.

To summarize, the best way to reduce the accumulation of technical debt is to have open, honest communication with stake holders about when decisions involve technical debt, the consequences of that debt, and the options for avoiding taking on the debt. Then, if the decision is to still choose the right now over the right way, immediately request buy-in for a plan, timeline and budget to reduce the technical debt. Again, my experience is that when the business is presented with a request to ensure functional reliability they frequently say yes.

Getting out of unavoidable or accepted debt

Taking on some technical debt is inevitable. This is why the modifiers usually, most often, and frequently were used in the previous section rather than more-comforting-yet-inaccurate always, definitely, and every time. Even in a theoretically perfect process where business always opts for debt-free choices and emergencies never happen, there are still going to be debt-inducing choices made either from lack of information or usage of imperfect vendor releases.

In the case where the debt is incurred unknowingly, once it is discovered be sure to document it, communicate and plan for its correction. The difference with cases where the debt is taken on knowingly because it is unavoidable without a much larger cost in vendor change, monitor the item with every project and when there is a reasonable option to correct it, do it. I once had to build something that was a bit kludgey because the vendor application clearly missed an implication of how a particular feature was implemented. We created a defect in the defect tracker which was reviewed in every release. 18 months later, the vendor found the error, corrected it and we replaced the work-around with the better approach in the next release. For major enterprises it is a good idea to raise a support case with the vendor when such things are identified, which I did not do at the time because the company I was managing this application for was too small to get vendor attention and the feature was not in broad use.

Originally published at InfoWorld.

IT Solutionist

Helping technology help people

Maximize ROI with MVP