BarcVox

The voice of business architecture. And more.

MVP or not MVP?

I recently produced a segment related to MVP, Minimum Viable Product. Whilst researching the subject matter, I found there were detractors to the concept. I feel this is a worthwhile topic in its own right.

In this segment, I share my perspective on the critical response published on Wikipedia — the content I share here for access convenience. I address each criticism in turn. In the spirit of full disclosure, some of the opposition relates to instances with conditional or marginal applicability, and some I am unsure of how the criticism wouldn’t also apply to a full old-school, long lifecycle release.

To MVP or to not MVP is the question. Let’s jump in. Brooke reads the Wikipedia content on the podcast.

Some research has shown that early release of an MVP may hurt a company more than help when companies risk imitation by a competitor and have not established other barriers to imitation. 

At core, this is a positioning statement. The key takeaway appears to be a fear of imitation. Firstly, it presumes that your MVP is successful out of the box, people will want to imitate it, and the profit margins create an incentive to do so.

In the event that it is successful, a first-to-market advantage is still in your favour. Plus, it’s an MVP. You are ahead of your competition, and your next task is to extend the feature set and expand your customer base.

It’s obvious, that this is taking a defensive, old-school, all-or-nothing mindset. And it doesn’t account for the fact that any product, MVP or fully fledged, may attract imitators.

It has also indicated that negative feedback on an MVP can negatively affect a company’s reputation.

At the start, this comment addresses Lean Startup, not MVP. This noted, it is conceivable that a company could release an MVP without appropriate communication and qualification and receive negative feedback that reflects poorly on the company as a whole. I’ll also posit that this is an edge case if not a corner case outcome.

Many developers of mobile and digital products are now criticizing the MVP because customers can easily switch between competing products through platforms (e.g. app stores). 

The underlying argument for this position is that your product needs to be better than the rest in your competitive space, which is predicated on there being existing market alternatives for your product offering. The recommendation is to not build an MVP; rather build an MAP, a Minimum Awesome Product.

My initial two thoughts on this are, firstly, this is a defence of the old ways. You imagine you know what’s awesome, and you build it. Secondly, this is contexualised by app development. Conceivably, this is a one- or two-person show with a limited scale and scope. Even still, developing in an iterative fashion is advisable. If it takes you a year to deliver a product you feel is awesome but the marketplace doesn’t concur, you’re a year out with no revenue to show. If this was an internal product, you’ve contributed no benefits, and you are still at the starting gate.

Also, products that do not offer the expected minimum standard of quality are inferior to competitors that enter the market with a higher standard.

This criticism misses the point of viability. If viability means that you need to meet a higher standard, then that is your minimum viability. If your product is an automobile, an MVP is not to test a wheel or a tire. If you are producing a product in an existing market, market expectations define what is minimally viable. If you feel that whatever you are building won’t be viable, you’ve answered your own concern.

A notable limitation of the MVP is rooted in its approach that seeks out to test its ideas to the market. Since the business’ new product ideas can be inferred from their testing, the method may be unsuited to environments where the protection of the intellectual property is limited (and where products are easily imitated).

This edge-case criticism has little to contribute. In essence, there are two arguments. One, Intellectual Property is involved, and, two, the product is easily imitated.

We’ve already discounted imitation. If your product is easily imitated, being an MVP isn’t disadvantaged over a fully-fledged product. Perhaps your pet rock idea — digital or otherwise — just isn’t that worthwhile of a pursuit.

As far as I.P. is concerned, what is your MVP revealing that your end product isn’t. If the end product is the Intellectual Property, how do you know there is any market for it if you don’t somehow survey the market.

The criticism of the MVP approach has led to several new approaches, e.g. the Minimum Viable Experiment MVE, the Minimum Awesome Product MAP, or the Simple, Lovable, Complete.

For this last batch, I’ll respond en masse. I’ve got nothing more to say on Minimum Awesome Product, other than make your Minimum Viable Products awesome.

Simple, lovable, complete seems to be someone hoping for a catchy slogan in a Live, Love, Eat sort of way. If your V requires lovable, make it so. Otherwise, this has nothing to contribute to the MVP conversation, which is hopefully relatively simple, and it’s certainly complete depending how you are defining complete. Defining done is a perfect candidate for its own segment.

Minimum Viable Experiment adds little either. By definition, an MVP is an experiment. You should be continuously testing and learning. You should be evaluating whether to persist, pivot, or perish. If you persist, the experiment has been successful, so far. If you pivot or perish, it’s been a successful experiment as well. Why? Because an objective was to learn. If you learned that your value hypothesis was incorrect, it’s still learning. Keep learning.

One thought on “MVP or not MVP?

Leave a reply

Your email address will not be published. Required fields are marked *