A Minimum Viable Product is a Starting Point

Introduction: You Don’t Know What You Don’t Know

Upon learning that Thomas Edison had conducted 9,000 experiments while trying to develop a nickel-iron battery, his friend Walter S. Mallory asked, “Isn’t it a shame that with the tremendous amount of work you have done, you haven’t been able to get any results?” 

Edison replied, “Results! Why, man, I have gotten a lot of results! I know several thousand things that won’t work.”

In this anecdote, the famed American inventor demonstrates an Agile mindset, even if the Agile Manifesto wouldn’t be written until 70 years after his death. Edison saw opportunities to learn in what other people saw as failures. This point echoes my first post, where I explained that Minimum Viable Products (MVPs) are so powerful because they create opportunities to learn. 

Reaching an MVP release represents an important milestone in any project. A release – whether an entirely new system or a feature enhancement – means that the team has gathered user input, engaged users with prototypes and mock-ups of potential solutions, and been able to craft a lightweight solution that allows users to do actual work, even if not in the most elegant fashion. In Agile terms, they’ve delivered working software. 

Even so, an MVP is just a starting point on the journey of continuous learning. 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. 

That brings me to the first step in the MVP process – admitting that, while we bring an expert perspective to technology, we are not experts in business processes or user needs. At this point, all of our efforts must be applied to ensuring our stakeholders embrace their critical role in developing technical solutions and have some idea of the level of effort required of them.

Our managers need to create a runway for learning and discovery. Our vendor partners need to apply teams optimized for rapid, iterative development, and they need the ability to contractually permit some level of tech debt and throw-away experimentation throughout the development lifecycle. 

Getting on the Train

Applying an MVP approach to product development can feel like jumping off a cliff. There are many reasons you might be hesitant. 

For instance, with fixed budgets, resource constraints, and constant pressure to meet a wide array of deadlines, the prospect of using taxpayer dollars to learn and evolve a product can feel wasteful. We have all learned that technical debt is a plague on our IT house. Convincing your manager and stakeholders means admitting that we don’t know all-the-things. That, too, can be intimidating.

To allay these fears, I’d like to share an example of how an MVP approach can be applied within OIT. Currently, I am spearheading the Data Subway Map project to address the challenges of navigating the CMS data ecosystem. Before we considered a product, we engaged in 11 Human-Centered Design sessions in addition to seven sessions with Remesh, the real-time survey software. 

The research process helped us identify a promising tool, but instead of saying, “We think this will work, let’s do a $6 million contract,” we chose to spend a small fraction of that amount to do an in-depth discovery analysis. 

We took advantage of the software vendor’s “starter kit” which offers a small number of licenses. By distributing those licenses to a narrow audience, akin to “early adopters,” we can learn more about the tool and how it will function for our use cases. Importantly, we can get feedback from users before making a commitment.

Even if the final product appears nothing like the MVP, it was informed by knowledge gained from the MVP. Sure, it creates an extra step in the product development cycle, but in the end, a small gamble on a small release will lead to more cost savings than a big gamble on a big release.

This orientation toward learning suggests some tips for the application of MVPs in the workplace. 

Practical Advice: 

• Make sure your stakeholders understand what MVP is and is not. Just because you know how an MVP will serve your project, your clients and partners might not. So when you present the MVP as a milestone, communicate its purpose as well
• Integrate your procurement team into the process. A contract should take into account that the deliverable resulting from an MVP is learning, not an operationalized product. The scope of a contract should be proportional to the outputs desired at this point in the product development cycle.
• In creating an MVP, optimize for speed of learning over quality. The faster you can produce an MVP, the faster you can gather the feedback that will help you refine the product.

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