What is the Minimum Viable Product (MVP), and why should you select the Earliest, Testable, Usable Products
By: Marwan Abu-Fadel 04/20/2024The critical question we must consider is: In the contexts of iterative and incremental development and the lean startup methodology, what exactly defines a minimum viable product (MVP)?
Gartner“A minimum viable product (MVP) is the release of a new product (or a major new feature) that is used to validate customer needs and demands prior to developing a more fully featured product. To reduce development time and effort, an MVP includes only the minimum capabilities required to be a viable customer solution.”
Eric Ries, author of The Lean Startup, defines MVP as " the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Not like this
The customer’s requirement – “I need a car to take me from point A to point B fast”. The top row is not the most effective way. While it involves iterative development, it does not allow the customer to test a usable functionality and give feedback on the desired final product.
The bottom row leverages the MVP concept in each release, allowing for a usable product with ongoing feedback and refinement. The “Not like this” example in this drawing[1] challenges a prevalent misunderstanding associated with iterative and incremental product development that delivering in pieces is all that is required to meet agile development.
The bottom row demonstrates that MVP in an agile methodology aims to provoke thought, discussion, and understanding and that interpretations may vary among individuals and a usable product. Some may find it resonates deeply with their knowledge and experiences, while others might view it differently. This divergence in perspective underscores the rich, multifaceted nature of Agile and product development philosophies.
Many U.S. government IT projects have faced significant challenges or outright failure due to the Big Bang delivery approach. In this method, the entirety of a project or specific system functionalities are fully developed before any part is released for end-user testing and feedback. This practice has frequently resulted in projects, particularly within the federal government, exceeding their budget allocations without successfully delivering a Minimum Viable Product (MVP).
Conversely, when introduced and implemented, agile methodologies offer a more iterative approach focusing on incremental development and early user feedback. However, the US government's adoption of agile often comes with its own challenges and adjustments. It treats MVP delivery as a Big Bang product via waterfall methodology but with a shorter release cycle.
To further discuss the top row of the “Not like this,” illustration, take a look at each individual step in the process. Delivering an "unfinished" product can seem counterintuitive—after all, who would be satisfied with receiving only half a car? This skepticism highlights a common misconception about the MVP approach within some government agencies, emphasizing the need for a deeper understanding of its benefits and the strategic value of incremental progress.
Imagine this: “Sir, here’s our first iteration, a tire. What do you think?”
The customer[2] asks, “Why are you delivering a tire to me? I ordered a CAR! What am I supposed to do with a tire?”
With each delivery, the product gets closer to completion, but the customer is still angry because they can’t use it or test its functionality—it’s still just a partial car.
Upon delivering the completed vehicle (4) to our customer, their initial reaction often masks a more profound dissatisfaction. Despite the apparent joy at the sight of their new car, a closer look reveals the root of their discontent. The extended period between order and delivery, coupled with the absence of actual user testing and end-user feedback, means that the design is riddled with flaws. These shortcomings stem from assumptions made in the absence of concrete user testing MVP and feedback.
Our failure to develop an MVP for early customer interaction has resulted in a product that only partially meets the customer’s expectations or needs. This experience underscores the critical importance of incorporating user feedback early and often in the development process, se we can ensure that the final product is visually appealing, functionally sound, and aligned with customer desires.
The first row illustrates what can be rightly described as "distorted agile." While it may embody incremental and iterative delivery elements, the glaring omission of a genuine end-user feedback loop introduces significant risks, rendering it a far cry from true agility. This approach undermines the very essence of agile methodology, which is predicated on continual feedback and adaptation. Without the critical input from ongoing evaluations, the process strays from agile's foundational principles, compromising the potential for responsive and flexible development.
“Like this!”
As for the second row of the image, the customer's need to quickly travel from point A to point B remains the same, but our approach shifts. Instead of immediately building a car, we explore the broader need for speed, with the car being just one of many potential solutions. The car is just a metaphor here. We start with the smallest viable product, a skateboard, which doesn't fully satisfy the customer's original request for a car, but serves as the earliest testable product. This is the 1st MVP or Earliest Testable Product, where, at this stage, our aim is to gather feedback rather than to please the customer entirely. With clear communication, the customer understands this is an initial step in a series of iterations aimed at learning and improvement.
We might make a few early adopters of the skateboard happy, but our main goal at this point is just to learn. The team has explained this clearly to the customer in advance, so they aren’t too disappointed.
From there, we progress through iterations: a scooter, then a bicycle, followed by a motorcycle, and finally, the car. Each step brings us closer to fulfilling the customer's need, with the product evolving based on the feedback received at each stage. This method ensures that we're not just building a car but are also deeply understanding and addressing the customer's underlying requirements for faster travel.
Unlike the tire in the first scenario, the skateboard is a usable product that can help the customer get from A to B. It's not great, but it’s functional for the customer’s needs. The customer is aware that the project is not finished, and this is just the first of many iterations. We’re still aiming to build a car, but in the meantime, the customer can try this method of transportation and give us feedback.
Imagine a customer who doesn't like the scooter we gave them; they dislike it mainly because it is black in color; they prefer red. This feedback can serve as a metaphor for understanding customer preferences. Although the customer is not fully satisfied, since they actually want a car, they’re still using the scooter and sharing their thoughts with us. This is the kind of feedback we need to improve the product. The customer tells us the scooter’s small wheels and lack of brakes make it challenging for longer trips. So, in our next update, we evolve the product closer to what he needs, something like a bicycle.
Remember, we're not developing separate products, a scooter, a bicycle, and then a car, but instead evolving a single product to meet the requirement—a car that quickly moves from point A to point B. Delivering incomplete components (just a tire, for example) is ineffective as it offers no immediate utility to the customer or feedback to the developers.
If your project is simple and familiar, with minimal complexity and risk, you might succeed with a Big Bang approach, delivering the complete product at once. Yet, most product developments are too complex for this approach, often resulting in costly failures.
The crucial early step is identifying your "skateboard"—the simplest version of your product that can be tested by real users to gather valuable feedback. This will guide the development towards the final, more sophisticated solution.
Always start with “What’s your skateboard?” for this product, feature, or story.
[1] Image source: With permission from Henrik Kniberg at http://blog.crisp.se
[2] The term “customer” here as a generic term to represent people like product managers, system owners, and early adopter users.