Minimum Viable Product disconnect: How to avoid a dangerous trap

One of my favorite examples of business miscommunication is from the movie “Hudsucker Proxy,” in which Tim Robbins’ character pitches a new toy by drawing a circle. What he is describing is a hula hoop. Of course, the company executives have no idea what he’s talking about, and they think he’s crazy. It’s only the audience that understands the impact of what he’s saying.

[ Are you a DevOps job seeker or a hiring manager? Get our free resource: The Ultimate DevOps Hiring Guide. ]

IT and business leaders are beginning to speak the same language, yet miscommunication still happens. When it does, it can slow everything down. In particular, the use of the term "minimum viable product" (MVP) can lead to mismatched expectations. When IT leaders use the term, they tend to focus on “minimum,” while business leaders focus on “viable.” This miscommunication creates a disconnect that can later become a huge impediment to execution. 

[ Don't miss our related article : 10 TED talks to sharpen your communication skills. ]

With a focus on “minimum,” the IT team may, for example, build a product that will boot on one specific machine configuration with a minimum number of discrete features. Everything else is a crap shoot. Meanwhile, a business leader may expect an MVP will viably support all potential users. With these two different mindsets, you can expect some pretty uncomfortable post-release meetings.

[ How does the MVP approach add agility? Read Why minimum viable product isn't just for startups. ]

How can you address this confusion? First, look for overloaded terms and define them as a group. Simply ask, “what does ‘viable’ mean to you in this case?” Also, follow-up with “what does that do for us?”

For example, a business leader might say, “We need to support 100,000 concurrent users.” But marketing and sales teams may only be able to sign up 100 users in the first quarter. If IT takes the business leader's request at face value, they might overbuild a solution that, in reality, only needed to support 100 concurrent users during the first quarter. Scaling an application from one to 100 is far harder than 100 to 100,000. Thus, by focusing on the first part, the company can release an MVP faster, by ignoring problems until they become problems.

Second, IT must impress upon business leaders that failure is necessary to improve. The entire point of building an MVP is to find out what you don’t know. IT must have an open dialogue with business leaders about how everyone is going to learn and improve. Prepare business leaders for failure, learn from it, and then make certain that IT delivers improvements.

Hindsight is 20/20. Caution business leaders against using phrases like “should have." Otherwise you risk creating a culture where IT is afraid to take risks to find a clever solution. You don't want IT to be mired in analysis paralysis. Business leaders should then show off progress to the C-Suite by touting IT's consistent improvements.

Additionally, by celebrating IT's successes and lessons, business leaders show IT that they are their best advocates.

In turn, the best members of the IT team from development, test, and operations will seek to work on projects associated with those business leaders. The business leaders who do not champion their IT partners will find themselves struggling for team members, and perhaps looking for another job. 

Don't let the MVP disconnect or other miscommunications slow down your organization's progress. By defining key terms and expectations upfront, you can avoid those uncomfortable post-release meetings – and ultimately deliver better products. 

[ Read also: Teaching an elephant to dance - a free EBook on the six stages of digital transformation. ]