With MVPs, the Real Product is Learning

Sometimes it feels like our professional lives are so wrapped up in learning new jargon that we overlook the actual concepts that jargon represents. Take for instance the term, Minimum Viable Product (MVP).

In a past life, I used an MVP management approach on a federal project I was leading. Seemingly out of the blue, the COTAR (this is what we called a COR in those days) came to the development team with a plan to defund development and apply an Operations and Maintenance (O&M) budget to the next year’s option. It took some delicate coaxing to ascertain that the COTAR thought “MVP” referred to the least amount of work that needed to be accomplished to call the project done. 

The idea of taking our MVP and throwing it into O&M crushed the morale of the product team and instigated a flurry of activity between the project leadership and the business owners. 

“That’s not how this works,” I said, desperately trying to explain to the executive stakeholder that when we said MVP would get us to usable software more quickly and increase adoption, we didn’t mean you could release it and forget it. 

“If you release this and do not commit to iterative, continuous improvement, you are just releasing bad software,” I argued.

Not having a shared understanding with the COTAR on what MVP means and how it would be applied to achieve our goals cost us time, money, and credibility. We got where we needed to go in the end, but not before our erroneous assumption of a shared understanding put our customer, our project, and our reputation at risk.

That is why I’m writing this series of posts: to explain what MVP means to me and to start a conversation with you so we can develop a shared understanding at OIT. At this point, I suspect nearly all of us have heard the term. Many of us are already applying the concept to our work. 

However, as is often the case with workplace lingo, each of us has our own interpretation of what MVP means. Though we may all have a good understanding of how and why MVPs work, the collective ‘we’ must come together on the nuances that will help us, as an organization, apply the concept to advance our mission. 

Let’s start with the textbook definition that resonates with me. In Lean Startup, Eric Reis defines an MVP as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with least effort. That validated learning comes in the form of whether your customers will actually purchase the product.” (my emphasis) 

Note that Reis stresses the impact of learning in product development. The purpose of the MVP is to gain insight about how future versions of the product can better meet customers’ needs. 

I don’t know about you, but I have had a lot of “customers” over the years that struggle with this definition. Partners not well-steeped in Agile may think that MVP refers to the least amount of functionality that can be released and called an “in-production” win. 

While various Agile methods create efficiencies in our work, I think continuous learning is the most important aspect of Agile. MVP is a crucial step in the learning process. 

With that in mind, I have written a series of pieces on critical MVP concepts. They are accompanied by bulleted suggestions on how we can tangibly activate these concepts in our day-to-day work to learn more about our customers or end-users. These posts are designed to be read in whatever order you find most useful. They will cover the following topics:

1. An MVP is a starting point. Sometimes MVP systems blossom into production tools, but on some occasions, they never see the light of day. MVP delivers only the minimum functionality needed to provide a real-world analog for user engagement.  
2. MVP is a manifestation of upstream user input and an understanding of downstream needs/drivers. MVP, by definition, requires iteration, brutal prioritization, and robust, continuous user feedback loops that integrate Human Centered Design.
3. How do different members of an organization shape MVPs? No single player “owns” an MVP. Once an MVP is defined, it impacts leadership decisions, contracts, budgets, and developers. This post looks at how the different members of an organization can coordinate to reach an MVP.
4. Case Study. I will share a successful application of an MVP at CMS, explaining the mechanics of how and why it worked. 

Look for the next installment of Rick Lee's series on MVP - coming soon to PlanetOIT.