Is MVP a Viable Approach?
It’s common to hear business people talk about a Minimum Viable Product (MVP) nowadays, but it’s not always clear if everyone is talking about the same thing, or if what they’re talking about is something that’s valuable and solves a real problem.
What does MVP mean?
The MVP idea comes out of the Lean Startup movement in the early 2000s. The basic idea is to get products in front of customers early so that an audience can be validated before investing the effort to create a “full” product. However, the contention, misconceptions, and criticisms start to pile up around differing understandings of what constitutes the minimum level of viability, how to define viability, and whether or how to transition from a “minimally viable” mindset into a “fully viable” mindset.
I’ve been in meetings where an IT leader was talking about limiting the scope of features on a project to the MVP level so that it would only take 18 months to deliver instead of 24-36 months. While it’s helpful to move towards shorter delivery timelines, I don’t think any of the original Lean Startup and Lean Software Development thinkers would have thought 18 months and MVP belonged in the same idea. In this sense, MVP has lost almost all of its meaning. There was no plan to react to customer feedback after those 18 months, it was only about limiting the number of things “we know” we have to deliver.
On the other side of things, some teams take the MVP idea to mean that they don’t need to finish features or polish interactions, because there’s always something more important to be working on. Well-designed experiences aren’t considered “minimally viable” (at least not by the technical members of the team). This is a common tension that Extreme Programming (XP) teams need to address, so that there’s a focus on the full experience, not just delivering features.
How Should We Then Build?
Getting back to the heart of Lean and MVP, start thinking about the quickest way to validate an idea with real people (either customers or potential customers). The best teams repeat this process multiple times per week (which has the added benefit of shared infrastructure, making each attempt cheaper). These MVP experiments will usually “fail”, meaning that test subjects will be confused or unimpressed or fixated on the wrong thing. This feedback is the exact purpose of the test, letting the team see and address their shortcomings before trying to deliver to a large audience. Note that these MVP tests will usually involve a full-fidelity design, because wireframes and incomplete design is incredibly distracting to everyday people. So, instead of skimping on the design, engineers need to get good at skimping on the implementation, creating a fake version that works just enough for a test.
What is ultimately launched to the public will then be a polished experience with delightful interactions which are known to meet and exceed the expectations of real customers. The process won’t feel like it results in anything “minimal” about the product. What has been minimized is the waste of building something that no one will use.