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 Lean 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

• A product that’s easy to iterate on. Compromise polish and features for rapid iteration, always. Feature bloat and polish are iteration killers, as they are likely to increase the complexity of change.
• A usable product/concept. The product will have rough edges, but if your customers can’t use it or at least visualize how they’d use it at all, that’s a prototype, not an MVP. Make it usable, even if just barely.
• A “measurable” product. Quantitative or qualitative KPIs are essential to measuring the success of your product. I often tell teams to overlook most features but always include some form of tracking. Don’t fly blind with your MVPs.
• A product that a handful of customers want/need. At a minimum, your MVP should tap into the needs of a few customers in the market. If it’s not the case, you don’t have an MVP.

What an MVP is not

• A finished/polished product. The term minimum should indicate to other people that it’s the case, but you’ll have to face the fact that “minimum” has a different meaning depending on what team/who’s looking at it. Engineering may think it’s about scalability. Designers will push for visual polish. A salesperson will tell you it needs specific features. As the product owner, it’s on you to define and navigate these difficult conversations of why the MVP is built the way it is.
• A product that can satisfy a large portion of the market. As an unfinished product, it’ll be missing features required to succeed broadly. That’s why steering the first versions towards rapid iterations is critical.

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