MVP - Is This The Best You Got?

When I was a kid in 1972 I wanted to be Reggie Jackson. He captured my imagination then during a playoff game against Detroit Tigers he blew my 8 year old mind. The series with Tigers went the full five games, and Jackson scored the tying run in the clincher on a steal of home. He stole home base! Arguably the most difficult way to make a run, never seen it done and During this play he was injured and had to sit out the World Series. He was so cool. His effort in that game became an example of what you want in your sports hero, grit, grace, and power. The next year he was instrumental in hitting home runs and his inspired play in the World Series cementing his place in the pantheon of sports gods. In most sports when the season goes long it becomes a battle of attrition. As players become injured and play with limited capabilities, athletes who endure the pain rise to the top and this is where Reggie Jackson earned his moniker as Mr October. Playing through the pain of injury and and ever increasing pressure of team leadership as his teammates fell away to injury. He was one of the best guys to play the game, and a super star off the field.

So by every sense he embodied the MVP = Most Valuable Player = Sports Hero, the Best of the Best.

Move the clock ahead 46 years and now in my mid 50's with the Glory Days and Boys of Summer long past, the phrase MVP still comes up every week. But now MVP now stands for Minimum Viable Product which carries a totally different definition. We go from the very best of something to the literally the most worst thing and still meet all the expressed needs. Technically MVP is defined as, "A version of an end user solution that meets the minimum set of documented requirements."

MVP - Minimum Viable Product = Meh Experience = The Best of the Worst

So the complete opposite idea of the the greatest ever, to be what is the least capable that can be delivered and still meet all the minimum requirements. Which brings me to my point and my picture.

First a little background on the picture. During summer months we take a trip out to a little family cottage on a lake in Northern Michigan. Behind the cabin is the wood pile, and about 100 meters away from the wood pile is the camp fire pit. So a daily activity is to chop and haul logs from the wood shed to the beach. It has been determined that we need a fire nightly to last about 3 hours to roast hot dogs and make the obligatory summer S'more (Check it out if you have not known the earthly pleasures of sticky toasted marshmallow between Chocolate bars) This requires about 30 - 50 pounds of wood, too much to safely carry in ones arms. So a set of requirements to build a log hauling contraption emerged.

1. Hold 50 Pounds of Wood
2. Mechanically deliver 50 Pounds 100 yards with a minimum of effort
3. Use existing equipment on hand
4. Mechanical device must be gas operated, and require little to no maintenance.
5. Must start faithfully for the next 10 - 25 years

So with these rules we have come up with this contraption. It meets all the requirements, reusing "off the shelf" components, this does no more and no less than is required, this is perfect for me the operator. Not pretty but it gets the job done.

Now to my point, and a question to you. How many times have you been involved in making an MVP off a set of requirements in order to prove a particular technology or use case? In my pre sales roll of building demo experiences for prospective customers this is a very common activity. "Build us a POC or MVP and we will be able to see what your tool can do." is the request. Upon successfully completing the build I take my MVP and show it to the prospective customer. I am told, "The UX is no good, too many clicks, or the UI color doesn't match our color scheme, or why doesn't this have our data in it?" After all that work I have missed the mark, and for all intents and purposes I have failed. I am worthless and weak, I am going to die penniless and 20 pounds over weight. I am a failure. I can take cold comfort in knowing that I built it to your requirements, didn't I? I mean this thing rocks! I even added chains on the wheels because it slips in the wet sand on the beach. Who wouldn't love this thing? It's awesome.

Two points. First your can be 100% right and still loose. Technically accurate and still lose the fight because however we got to to this point we didn't really meet all their real needs, I have to own up to that. I need to know that all that feedback I got was legitimate and that my defensive reaction is cold comfort. So the question is how to not let this happen. To fall into the "Give me a list and I will build it" How I work thru this challenge?

Mindset = Empathy. Who and How are to the two main goals after function. Is it C level leadership and end users, or is it the business analysts, or purely developers. With that mind I can then be creative with how we get to show MVP functions. Maybe screen shots up to the live part, adding the appropriate customer colors and maybe their logo. Simplifying forms and changing terms and labels to make the form more in alignment with their lexicon of terms. Basically understanding not just what they functionally need, but more importantly ask these question what are the implied needs they have.

"How are you going to evaluate the solution?" Putting on the mind that "the customer is always right" will lead you down the right paths.

You may have technically built a perfect MVP but if you fail to make them feel a connection to the solution then you are on a sure path to loser town. As they are always going to consider the fit and finish, or colors. The end users will always need to imagine how they will use the system. They may not say it, but it is always being considered.

Strategy:

1. Wait to start a MVP project until you discover and fully understand
2. The Specific Functions
3. Who the users are
4. What is their expected experience
5. Get good idea of the mindset of the evaluators.
6. Use the time as a negotiating chip to get the understanding you need and Don't build anything until you have that understanding
7. Get feedback early on in the build, even pull the customer into the process of the build to get inline feedback as you go.