Most “minimal viable product” (MVP) attempts are anything but minimal. They take too long, run over budget, and usually miss the mark. During the past year, Code42 added three significant features to its core product using MVP principles (security tools, legal hold, and endpoint migration). In this article, John Durant, senior vice president of Product Development at Code42, shares what an MVP effort should look like and how to maximize its value. With more than 20 years of leadership in the technical industry—including time at Microsoft headquarters and as an executive at Code42—John draws on successes and failures, and shares what works in the real world.
It’s an exciting moment when a new idea rises to the top of the list and gets funded. In the midst of that enthusiasm product managers, product owners, and engineers start brainstorming how to approach the opportunity. People start talking through features, architectural concepts, schedules, and more. But nearly everyone forgets to do the most important thing first. The one item that will have the biggest impact on the success of the entire effort is usually ignored: Getting everyone to agree on the definition of MVP.
Car ≠ Plane
Let’s use an analogy. Imagine your company has been very successful in the automobile industry. You build cars, and now you’re thinking of getting into the nascent aviation industry (for simplicity in this example, let’s assume you’re an empire builder like Henry Ford long before the birth of Boeing). The CEO of our car company is excited. She sees the strengths that have made the company prosperous in the automobile business. Her team knows how to gather data, plan effectively, execute operations, and go to market with new cars: formidable assets that, when harnessed properly, apply directly to the aviation business.
But here is what will likely happen next. The team will crowd into a room and start thinking about putting wings on a car. In the minds of everyone will be images of the beautiful, gleaming vehicles they made during their careers, with all sorts of features added: leather seats, polished chrome bumpers, whitewall tires, and radios. As they begin planning their first aircraft, these advanced concepts about what an airplane should look like will color their discussions. Most likely, the team will swiftly move past the basics of aviation and head straight to beverage carts, reclining seats, and in-flight entertainment options!
It’s tempting to apply existing competencies to a new venture. For example, the person who designed the seating for the car might say, “I’ll get my team to work on those airplane seats. They’ll be light, comfortable, and beautifully designed! I have the best seat-system team in the world!” And the same dynamic will play out in other areas of the new airplane project. It comes from a great impulse and seems to make sense: high performing teams always want to do their best work. But in the case of a Minimum Viable Product, their energy will need to be channeled differently. And leaders will need to set expectations and temper this impulse.
Kite = Plane
Deciding on a proper definition of MVP will include understanding what “minimum” really means, and how it will lead to more advanced product concepts. Let’s look at a basic proposition of flight:
- It’s more flexible, and it can be faster.
- Air travel allows for views of terrain that are not possible from the ground.
- Being airborne is exhilarating and fun.
With these values in mind, a starting point for a truly minimum viable aviation product is a large, steerable, stringless kite rather than a car with wings. Once you have that basic concept in mind, the right level of features will coalesce around it, and the feature additions will be sensible, tightly focused, and add immediate value. For example, the team that creates seating systems will not think about seats. Instead they might say, “We’ll design something so the person steering our stringless kite will be secure and safe.” The engine team might say, “Because it’s a kite, we’ll need to make the propulsion system very light, easy to operate, and reliable.”
You might have noticed that I had the imaginary teams call it a “stringless kite” rather than an “airplane prototype.” This is intentional, and it is something I recommend when creating an MVP: find a name that best describes what you are actually doing. Don’t call it your “airplane MVP.” Call it your “stringless kite” within the team and even in your company-wide communication. This will help the team stay focused, and it makes room for another important dynamic: not assuming that the end result is an airplane at all. Remember, a vital piece of any MVP project is to get feedback! When you embark on a new initiative, you don’t know what you don’t know about the industry, marketplace, technical considerations, usability, support, sales, staffing, and more. Put simply: by the time you do a full cycle of your MVP, you may realize you don’t want to be in the airplane business at all, or that what you built is better suited to a context you haven’t yet imagined. By calling it something other than “airplane MVP” you avoid reinforcing a false inevitability of the final concept.
Plane = Plane
So far, we’ve done a better job setting up MVP expectations, we’ve avoided the temptation of jumping to advanced features, and we have put the entire effort on better footing by laying out a proper starting point. Now, we need to layout a logical roadmap for getting to the more complete product. Returning to our example, you might move from the large, self-propelled, steerable kite with straps (to hold a pilot) to the second phase. This phase features an enclosed cockpit, basic instruments, improved controls, lighting, and wheels. The third phase could include an engine upgrade, fuel-capacity increase, actual seating, a full fuselage, a radio, improved instrumentation, and more safety equipment. It should be noted: one of the most important things in this multi-phased approach is to avoid defining precisely what the next phase will include until you have gathered sufficient data from your earlier phases. Many books include good counsel on this topic such as “The Lean Startup” by Eric Ries and “Zero to One” by the legendary Peter Thiel.
The concept of a minimum viable product is used frequently in software development and many other industries. But in my observations (outside of Code42), the MVP concept is rarely discussed and dissected by the very managers and teams who pour tons of money and effort into creating the products. It is wise to take a step back and think carefully about what the MVP is, and assure that everyone on the team has a shared understanding of it, before setting out to build something.
By following the fundamentals sketched out here, my teams at Code42 have been able to deliver more features, fixes, and enhancements than ever before in our flagship product. And these MVP principles continue to guide our innovations that will reach far into the future.
Download The Guide to Modern Endpoint Backup and Data Visibility to learn more about selecting a modern endpoint backup solution in a dangerous world.