Failure to Launch - Avoid the MVP Trap!

Author - Calvin Gosla III

Consultants at Percipio are often brought in to implement new technologies and tools. Sometimes we are called because the client organization does not have the expertise in house; other times we are called because the internal resources are already spread thin on other high priority projects and do not have the bandwidth for anything else.

Occasionally we are called in after a tool was implemented. In these situations, the tool is not meeting the needs of the business and considerable reconfiguration or improvement is needed. When discussing the history of the project with the client, we’ll often hear the phrase MVP (Minimum Viable Product); as in “The plan was to release an MVP and iterate from there.” Businesses often misunderstand what MVP means, especially for products intended for internal customers, and this can get them into real trouble.

The concept of Minimum Viable Product came about in the start-up world, where new firms, operating on lean budgets, needed to figure out whether a product idea was a potential success and deserved additional investment. The idea is to get a prototype of the product into the hands of early-adopter customers to get feedback quickly. The product does not need to be a comprehensive suite with tons of bells and whistles (hence “minimum”), it just needs to be “viable." In this context, (and this is key) “minimum viable product” doesn’t mean the “minimum functional product”, it means “the minimum functional product that addresses a customer’s need better than any other product available”.

When dealing with external, revenue generating customers, there may be several competitors vying for the same space. However, initial market analysis may indicate an opportunity to solve a particular problem better. Whether one has an MVP becomes quickly clear - customers are willing to pay for it or not!

When dealing with internal customers (as Percipio almost always does on technology projects), the analysis is much more complicated because internal customers are often accustomed to more comprehensive tools with arcane features that they rely on. With internal customers, it is much easier to fall into the MVP trap where the business, in a sincere effort to solve problems, makes things worse (by the way, there is an excellent German word for this: verschlimmbessern). Internal customers have bent and molded their business processes to fit the tool they have, usually at great effort, so any new tool has a very high bar to clear before it can be considered “viable” in that it solves enough of their core problems better than the tool they have.

This bears mentioning here, the internal customers always have two tools that the new tool is competing against: the tool they are using and Microsoft Excel! To avoid falling into the MVP trap, the business has to avoid two failure modes for new tools: (1) the new tool fails to meet business needs or (2) the new tool meets needs but insufficient effort is placed on shifting business processes to align with the new tool. If either of these happens, the internal customers will abandon the new tool and frantically redesign their business processes to be managed in Excel! We see this far too often. Our business stakeholders are experts in their processes, are smart, and are motivated to keep the business operating. Excel is always an available fallback option for them.

When one hears an executive or project team say “MVP”, this should motivate stakeholders to ensure the everyone understands that the MVP, though incomplete, must absolutely be better than the current solution before it is imposed on the business. This is good advice in any project, but for projects that are under enough schedule and budget pressure that the phrase “MVP” starts getting tossed around, it is doubly important to revalidate requirements, re-design test cases, re-evaluate stakeholder analyses, re-think release processes, and have an executable roll-back plan.

It is a frustrating reality that sometimes requirements cannot be truly known until stakeholders have a tangible tool to test, so requirements gathering should be considered more of an ongoing activity than a project step.

Shifting requirements means shifting understanding of business processes so impacted stakeholders should be re-evaluated along a project as well.

Finally, we all must be wary of the sunk cost fallacy and be prepared to delay a release to get it right the first time. Just because several million dollars have been spent does not mean that a tool should be released; it is very possible for an ill-considered release to generate substantial negative value for the business. Above all, it is critical that the system integrators and project team actually talk to the people they are trying to help to ensure an accurate understanding of what “viable” means for them.

As consultants we consider it our duty to advocate for the business as a whole. If we are lucky enough to be involved early in a technology project, we can use our experience to avoid the MVP trap. If we are brought in later, there is always a way to right the ship, though it may not be quick or cheap.

What have been your experiences with solutions that are introduced before they are truly viable? ?Drop a comment below and share your thoughts!

?