Season 3 - Episode 5: The Good, the Bad, and the Ugly of the MVP Process
MVP… Most Valuable Player? Must Vacate Property? Millennial View Point? Nope! For our first episode of our Innovation Station series we’re revisiting the “Minimum Viable Product - MVP”! It has long been hailed as the best approach to product innovation. The recipe is simple: build-measure-learn with a dash of rapid iteration. It has worked incredibly well for us. But we’ve also had some misfires. In this episode we’ll discuss how MVPs can launch your startup to success, or totally flop.
Background Story
Chris, reporting in! When we started AppArmor we had a very simple idea, to create a blue light security pole (like those seen on many higher education campuses) except it was on the phone in your pocket. We had an engaged first client (an “earlyvangelist”) who worked very closely with us to build and iterate the initial prototypes. We learned a lot about the market quickly, and this led to a great product. We rocked the MVP process and lived to tell the story!
We also had several experiences where the MVP process went completely awry. Sometimes it was our fault. Sometimes it was the fault of our earlyvangelist that we were working with. Sometimes it was both of us that blew it.
In this episode, we hope to steer you away from the pitfalls of the MVP process and ensure that you’re successful.
Outline
Engaged Earlyvangelist
Focus on the Problem
Engagement of Your Team
Busted Myths
Myth: That the MVP process is flawless. Best thing since sliced bread. It’s not, and can very easily go off the rails.
Myth: Throughout the MVP process, the stakeholders will have the same level of engagement. Wrong. In fact, you should expect your initial customers interest levels to change during the project, same goes for your developers, and of course, testing, feature scope, code quality can change throughout the process.
Learnings
Engaged Earlyvangelist
It is critically important that your earlyvangelist understands the problem that we’re trying to solve. They don’t need to be technical experts, that’s your job, but they need to have a deep understanding of the problem. Also, make sure that you double check what your earlyvangelist tells you. They sometimes can be unaware of existing in-market solutions that might turn your efforts into a waste of time.
They also need to understand that the MVP build-measure-learn process gets messy. There will be many misfires and corrections throughout those cycles, and that’s the point. You’ll get things wrong. You’ll get things wrong, a lot. So your earlyvangelist needs to be ready for that.
Focus on the Problem
The MVP process isn’t for building tech, it’s for solving problems. You need to narrowly define the problem. In the HBR Article “What Drones and Crop Dusters Can Teach About Minimum Viable Product” the author explains how a startup planned to use drones to capture hyper-spectral images of crop fields so that farmers could optimize the fertilizer, water, and farming efforts. Originally the product was going to be drones with special cameras. What they learned instead was that the product was actually the data. It didn’t matter how the data was captured, just that it was captured. The farmers already used crop dusters to fertilize their fields so no drones were needed at all. They just mounted the cameras to the existing crop dusters. Focus on the problem, not the product.
Keep in mind that sometimes it’s too costly or unfeasible to build an actual working MVP. Instead, you can often prototype (we called this vapourware) a concept to tease out the feedback you need from the build-measure-learn cycle. The HBR Article “When a Prototype Isn’t Enough, Use Theatrical Tricks to Sell Your Idea” does a great job of explaining how stagecraft can be used instead of an MVP.
Engagement of Your Team
If you’re going to be using an MVP approach to innovation, make certain that your team is highly engaged in the project. The last thing you want is an unmotivated, disinterested employee working through the build-measure-learn rapid iteration cycle. They’ll give you half-ass products, not half products and ultimately your MVP will fail.
Make sure your team tests thoroughly before putting the product into the hands of the earlyvangelist. Comment out the code for features that aren’t fully functional before compiling. That way, your earlyvangelist isn’t thrown off by buggy features. Everything they touch should be well tested and working.
Summary
Everyone needs to be on board for an MVP. Engagement of both your earlyvangelist and your team is essential.
Focus on the problem, not the product. Sometimes the product will be far different from what you originally thought.
Remember half-product, not half-ass product.
Iterate as quickly and as many times as it takes.
If an MVP is too costly or unfeasible, then consider a prototype that mocks up the idea instead. Often you can get the feedback you need from just a prototype.
Data And References
Lean Startup, Eric Ries - https://www.amazon.ca/Lean-Startup-Eric-September-13-2011-Paperback/dp/B0C1JJZDN3
What Drones and Crop Dusters Can Teach About Minimum Viable Product - HBR, Feb 2014.
https://hbr.org/2014/02/what-drones-and-crop-dusters-can-teach-about-minimum-viable-product
When a Prototype Isn’t Enough, Use Theatrical Tricks to Sell Your Idea - HBR, June 2017
https://hbr.org/2017/06/when-a-prototype-isnt-enough-use-theatrical-tricks-to-sell-your-idea