Prototypes should NOT be Minimum Viable Products
Teams looking to create and validate ideas may incorrectly combine these two and think of a prototype as a Minimum Viable Product, or MVP. But, what that team actually needs is a MLP, a Minimum Learning Product.
The term Minimum Viable Product (MVP) is widely used by teams that practice Agile methodologies. Agile teams work in short bursts called “Sprints” which each have the goal of “launching” or “shipping” something tangible that meets at least the minimum of what is required by the user.
Agile teams and UX teams often work together. UX teams also work in short bursts but in different ways and optimized for different outcomes. Many times a UX teams’ efforts will provide the requirements that an Agile team builds against. I have spent times in both camps, but mostly in UX teams.
In user experience (UX) design, teams typically start by gathering information about the end user’s current experience. That might include a physical product, a digital product, a process or something that has all of those at different phases of an experience. Once the UX team has gathered that information, they will use it to form a point of view or hypothesis about where that experience is meeting people’s needs, where it isn’t and where there may be opportunities. Next, the team will generate ideas that might meet a need stated in the hypothesis. Those ideas are quickly turned into something that can be experienced. This involves creating a prototype. A prototype is nothing more than an early version of something aimed at helping the team learn if they are on the right track or not. In order to find that out, the team will test that prototype with users.
It is in the prototyping stage where I often see teams incorrectly applying the “MVP” concept. A prototype is not a minimum viable product. It’s quite different. A prototype doesn’t need to be viable. Something is “viable” if it is “capable of working successfully; feasible”. A prototype is a learning tool and it doesn’t necessarily need to work successfully. It’s sole purpose is to help the team learn if the idea they have come up with meets the needs of the people who would ultimately use it. But in its prototype form, it doesn’t need to meet those needs. A prototype can fail miserably at meeting a user’s needs. When that happens in a test, the team has captured valuable learning. A MVP aims to avoid this type of failure by providing something useful at every release. Agile teams try to eliminate “waste” or unnecessary functionality in order to provide something that is useful at the end of each Agile Sprint. Agile teams are looking at that piece of functionality after it has been released to make sure it is working as intended, but the goal is to have met a need of the user. A prototype’s goal is to meet the need of the team that is building something for the user.
A Minimum Learning Product helps teams shift their focus away from trying to get the idea right to creating a scenario that helps them learn if they are right.
That may seem subtle, but it’s an important distinction. Often, when creating a prototype, team members will debate the value of certain parts of it. They will say things like “It should definitely have some personalization” or “We need to include a way to login”. But that is the wrong way to frame it. If, in this example, personalization or login are hypothesized to be important to users, the conversation should be about how to create a prototype that effectively confirms or rejects that hypothesis. It’s about creating a scenario that facilitates learning, not about designing a feature. Some of the best prototypes are designed explicitly to expose flaws in an idea.
So, if you ever sense during the prototyping stage of a project that you are focusing too much on getting it “right”, remind them that you are going for the MLP, not the MVP.
