The true face of an MVP

Did you know that when it first launched, Airbnb didn’t have a checkout flow? Users were expected to hand over cash in person as they arrived at the hosts’ rental. Can you guess what (safety) problems that it can create? After years spent building products, it’s clear to me that teams release products way too late and stop iterating on products way too early.

The book “The Learn Startup” coined MVP (Minimum Viable Product) to remedy this issue. The author defined it as a process to build a product which maximizes product learnings.  The goal of an MVP is to put something in the hands of a few customers as soon as possible so they can test it. The Minimum in MVP ensures that the product is nimble and easy to change based on customers’ feedback.

Most teams are comfortable with the theoretical idea of MVP, but when it comes to their own products, they rarely manage to build an actual MVP. The bigger the company, the more likely is the “MVP” to be bloated. Unfortunately for the future of the product, a bloated first version has dire consequences on future success, and ultimately the team’s morale.

Comfortable with the uncomfortable

Coaching people, I’ve realized that the first step for the team is to accept the true face of an MVP. Spoiler alert, it’s not pretty

If product owners don’t establish that reality first, as they seek consensus, other team members or leadership on what should be in an MVP is the most common “MVP killer.” It’s the responsibility of a product team alone to define what goes into the MVP.

What an MVP is

What an MVP is not

Avoiding MVP decay

Typical product decay happens by the rot of existing features. Over time products tend to break down and not work. MVP decay occurs in the opposite direction. As the MVP gets close to a “releasable” state, a team will start to doubt if this first version is “enough.” Additional features and requirements will be tacked on. The M part of MVP slowly gets forgotten as worries set in the product team.

MVPs required active management of stakeholders and product teams by the product manager. Product Managers need to step into the details of Engineering, Design, and execs requirements to avoid the delivery team in charge of the product building taking on unnecessary tasks. As a product manager, expect many uncomfortable conversations with team members that will doubt the product’s success. While you must listen to the concerns, as there could be some real late discovery regarding feasibility or usability, you must ensure that the minimum product’s vision is not compromised.

The hard reality of product management is that most products will not work. It follows that MVPs are a fundamental tool as they allow for fast learnings and iterations on what needs to be changed to give the product a chance to succeed.

The first version of your product is likely to get your organization out of its comfort zone. The bigger the organization, the more uncomfortable the first version of a product will feel. As Reid Hoffman said, “if you are not embarrassed by the first version of your product, you’ve launched too late.”

New comment

Comments will appear after moderation.