MVP stands for Minimum Viable Product. I have had a long distaste for this acronym, but I think it is worth a deep-dive. I found an image on this website that sums up some of the problems. I’m going to deconstruct it to explain better.

Strategy #1: Build too much before launch

In this scenario, you build steps 1, 2, 3 and 4 before you release anything. The problem with this strategy is that it takes too long to build and you go too long without market validation. It raises risk very high. It also means you go to market much later than competition. This means you need more funding to survive the initial stages.

The benefits of this approach is that the actual launch is full featured and not missing anything. It makes a good first impression, assuming you did your research properly.

Strategy #2: Grope for your vision through iteration

This is a popular image on the web to describe MVP. This strategy works if you have no idea what you are going to build. This is when you have a use case with no clear vision of the solution. In this case, the use case is “need to go from point A to point B. All of the solutions work. You get something easy to build in the market and you learn.

Engineering-driven organizations often love this strategy because it allows you to iterate and not trust the vision of anyone. You get cold hard data and work from there.

I think the benefit of this approach is that you don’t need strong designers. You can just guess a bunch of times and hope to learn. This strategy is my least favorite because I feel it wastes too much time building stuff that isn’t part of the final solution.

Strategy #3: Incremental features of strong vision

In this approach, you have a strong vision of the final product and you break down the functionality over time. This allows you to go to market quickly, but not have throw away products or code. You know your end game and can work you ways towards it.

Given enough quality, this can be a MLP (Minimum Lovable Product) approach. It allows people to love a subset of the final solution/vision. It possibly may restrict the stories that can be told in the sales cycle, but you have to start somewhere.

To add some extra color to this model, check out this picture below:

The picture clearly shows that you need to be reliable, usable and have some emotional design even in the first iteration. It is just short on functions.

Strategy #3 is clearly my favorite and most closely matches my own process. However, I want to add on a few extra caveats.

The first thing you “ship” is your designs. I make my designs as storyboards that are mid-to-high fidelity so that I can show them to prospective customers. The fidelity matters. You can’t react properly to wire-frames and text. You need it to look mostly like a UI. Tools like Invision are possible, but I find that prototypes don’t get better feedback than storyboards. They are more useful in testing usability, but in the beginning you are determining if the model you have designed is going to fly in the marketplace.

Second is that positioning and storytelling by the sales team is imperitive to success. You can’t just have a better product. You need to be the ONLY product that solves the problem the right way. You need to be 10x better. You need your sales people to have weapons at their disposal to inspire and close deals. This is going to change how you think about MVP.

For example, having cupholders may be required even in the MVP. It let’s your sales people say, “Hey, if you don’t have cup holders you are going to hit a bump, spill your drink and careen off the road and die! We are the only ones with cupholders!” These are unique differentiators and even an MVP needs that.

So none of these pictures is perfect, but I think deconstructing them is helpful to wrap your head around the issue. At Engagio, we are gearing up to launch our MVP of a new product. It’s really exciting, but also tense. You never know until you do it. Hopefully, it will go as well as I imagine.