Why the MVP method is hard – Organizational challenges

In my previous post I talked about how the MVP method is very frequently referenced but rarely used. Organizations usually use the word Minimum Viable Product when they develop what I refer to as the Maximum Possible Product, where the features for the product are defined up front and then as many of those features as possible are delivered before a deadline or within a budget. They do this because the MVP method that Eric Ries describes is not as easy as it sounds.

Probably the most difficult obstacle to the MVP method is the structure, values and history of the organization itself. Certain very common characteristics can make it next to impossible to execute a project that emphasizes testing, learning and changing direction based on feedback. Let’s talk about three of these characteristics.

The most common organizational barrier I see is focusing on avoiding project failure, sometimes referred to as “front loading.” For example, an organization may employ a product development process with mandated reviews and approvals of design documentation, or a team may use many meetings, documents and presentations before putting any functionality before a user. A lot of analysis and design is conducted and a list of required features is developed based on opinions, the assumption being that if we get the right experts involved we can ensure the project is successful. After this analysis is complete, the only thing left is to decide which features will make it into the product before the deadline. This is not the quick turnaround “build – measure – learn” loop that Eric Ries describes. Instead we have one big release, sometimes followed by some corrections and refinements, if there is still budget or time left.

The main problem with this approach is that failure is valuable. Eric Ries says it best – “If you cannot fail, you cannot learn.” The focus of the MVP method is on investing as little as possible while gathering as much information as possible. You use that information to define the product. The required features have to be able to evolve, and failure has to be embraced and leveraged as valuable learning, while obviously minimizing the cost and impact of said failures.

The second way that organizations drive MVPs into MPPs is placing efficiency over creativity. The MVP method requires experimentation and evaluation, which can be time consuming and expensive. It also requires that the team be able to “pivot,” meaning change direction or focus, when required. Unfortunately, when the focus is on efficiency, organizations require evidence of some return on the investment, such as features delivered against a road map or progress on KPIs. These are completely reasonable demands, but according to Eric Ries, the most important product of the MVP method is what you learn about your customers and their problem, and as he says “You can’t take learning to the bank; you can’t spend it or invest it.”

Of course I don’t think anyone would say that the MVP requires a carte blanche, but trying to evaluate it like a more traditional style of project results in an emphasis on delivering features or numbers rather than learning and evolving.

The last organizational hurdle I’ll mention is the ability of the indirect stakeholders in your product to understand and work with the MVP method. Groups such as Sales, Marketing, Branding, Public Relations etc may demand time to prepare for a launch, or management may prefer big launch events and communications that have to be scheduled in advance. The different groups will want assets and descriptions of features well in advance in order to prepare, and they may not be able to react if the feature list changes close to the launch.

There are other organizational and “people” related factors that hinder or just prevent the ability to use Eric Ries’ MVP method. I recommend a recent blog post by Kurt Bittner “5 Beliefs That Predict Enterprise Agile Success.” The MVP method shares a lot with Scrum and the Agile Manifesto, and much of what he describes in this post applies to using the MVP method too.

The solution to the above problems is not simple, but it begins with education and communication. It’s not sufficient to ask everyone to read  The Lean Startup or send them to agile training. Product Managers need to emphasize learning over delivering. Management must focus on ensuring the teams have the information and tools they need and learn to trust them to make the right decisions. Developers have to accept a lot of ambiguity and the fact that sometimes work they put a lot of effort into will fail and be discarded or revisited.

Some of these changes can be communicated through training, but it’s just as important that leadership deliver the message of how things will change and why these changes are important. It is also vital that the process and decisions be transparent to all involved, which is another barrier I’ll talk about in the next post – how difficult it is for product manager, product owners and managers to execute the MVP method.