5 Things MVP is not

Photo by Leonel Fernandez on Unsplash

I heard the term MVP several years ago while working on a project that was too complex and too risky to begin with. We did not understand all the details when we started it even though the goals seemed achievable. Our vision was to bring out a product that was extensively thought through, one that would delight our customers and most importantly was quite superior to our competition. It was an outgrowth of our high expectations and confidence to deliver no matter what challenges exist. A big assumption was we thought we knew our customer very well. 

After several months, we managed to finalize the feature specification, although bit halfheartedly. So many differing opinions to consider, people to convince, options to try out and risk mitigation made closure difficult. It was hard to make everyone happy.

The development team wasn't either. Too many assumptions made. Several open questions as they worked out their way into the implementation. With months invested, the project became a big liability if it did not hit customer expectations. 

Luckily we had the VP of engineering take over the project, one who always asked the right questions. One of them

What is our MVP?

MVP stands for Minimum Viable Product, to quote Wikipedia, it "is a version of a product with just enough features to satisfy early customers and provide feedback for future product development". 

When I first heard it, the philosophy of defining a "minimum viable product" made a lot of sense for several reasons. 

First, it made us rethink which features were most critical to the product, ones that were most essential to reflect on the value proposition. Second, since no one had absolute clarity on the market demand and how customers would respond, it would only make sense to take things as they evolve, while investing time or resources on the critical aspects. Luckily for us, we were able to course correct and ship the MVP version of the product much sooner than we thought. Thinking back on how the product evolved over time, it is almost impossible for me to comprehend we could have hit it in the first go. 

So coming back to the original question: Is MVP mostly a vaporous phrase? Even though MVP seems common sense to me, the reason I am writing this blog is the fact how much overloaded the term is, interpreted by people in different ways, sometimes due to their inherent bias or due to rigidity.

MVP, if correctly represented is a factor that can define your products evolution and success.  

Here are the five things that MVP is not. 

1. MVP does not mean the lowest cost product

Often times I have seen people confuse MVP to be the lowest cost product. Cost in this case could mean both time and effort. While cost is an indicator of minimum-ness, it does not signify the viability of a product. If cost becomes the sole deciding factor, it can lead to poor design decisions, poor user experiences or even a product that isn't ready for initial use.

A cheap implementation may get perceived by your customers in a negative way. Brand building takes years or ages. A quick out-of-the-door product might do more harm to your reputation than helping build it. Today, where performance, security and privacy concerns are paramount, it is of utmost importance that an MVP product includes these essential cross-cutting concerns in the initial phase itself.

2. MVP does not mean bare-bones product that's difficult to use

This is where the "viability" of the product takes precedence. Will the customers be OK to use it in the way we shipped it? Is it cumbersome to use, to the point that customer may not even use it? These are not easy questions and brings in a lot of subjectivity.

The best way to deal with this ambiguity is to be driven by your vision and obtain early feedback from the users of the system. Talking to your close customers, launching quick surveys, analyzing past instances and obtaining data from your existing system can help drive decisions quickly.

3. MVP does not mean you need to wait on marketing

The whole point of an MVP is to get the product early on, let customers try it and analyze feedback so that you can adapt quickly.

You definitely do not need to wait on marketing, hoping for the perfect product for an ideal launch. A MVP is the time for rolling out free trials, beta launches of the product and on-boarding other departments in the company such as support and documentation.

4. MVP does not mean a product which is difficult to change

While you are driven by the vision, do keep the value proposition open. You do not know how the market might perceive the product or find it's use. 

To give an example Play-Doh, that strange, brightly colored, salty clay that all of us grew up molding and poking, was first invented in the 1930s by a soap manufacturer named Cleo McVickers, who thought he’d hit upon a fantastic wallpaper cleaner. It was only later it was repurposed as clay for pre-schoolers, a product that remains wildly popular among children.

A MVP needs to be flexible to adapt quickly. This is more true for software design, because initial technology can play a big role in how quickly you fold subsequent features into the product. While refactoring is an on-going process, it is often a nightmare to rewrite the entire implementation to fit new feature sets. As time progresses, it is even more true.

5. MVP does not mean one-size-fits-all product

As Steve Blank once said

"You’re selling the vision and delivering the minimum feature set to visionaries, not everyone."

There is no product that satisfies every single consumer. Same is true for MVP. Just like you spent enough time defining the viable product, you need to spend time identifying the segment of customers who benefit the most, not to mention the section of customers who would be willing to partner with you in the initial journey. These are the ones to target first. 

(Image Source)

Remember you are also trying to get feedback and evolve. So launching in a big-bang way is risky. Understanding the product life-cycle plays a big role. We are in Stage #1 here. Making an initial product widely available for use, without prejudice and consideration, can lead to several problems such as scale challenges, negative feedback from your premier customers and difficulty in rapid changes due to lock-in.

Conclusion 

Any new product should spend time defining its MVP. The products evolution and long term success is greatly dependent on how good you have defined your MVP. It also saves you time and money from wasted efforts in building features that are not critical. Adapting to feedback and building rapidly becomes the mantra. However, MVP is often interpreted incorrectly. It may not necessarily mean a product that has the lowest cost to build, or something that ignores usability concerns. You need not wait for marketing it and involving other departments. Lastly, it still needs to be designed correctly and targeted to the right segment of customers.

So, having said this, I ask: Have you defined your MVP today? If not, please do. :)