Is the MVP approach always viable?

Finding product-market-fit is a key success factor for any new product. It is also a key responsibility for any product manager. The minimum viable product (MVP) approach is great at doing just that. But lately it has been questioned. People claim that it is naive, limited or not applicable to their market (or customer base, or vertical, or product type).

Just like any other approach it cannot, or at least should not, be taken literally. It is not about building something that is simply viable. It is not about building something that is feasible and capable of working successfully (the definition of viable). Instead it is about successfully solving a problem for a selected set of users (often early adopters).

To do this you need to fully understand your users and what problems they need help solving. Is your user trying to get from A to B? A car without wheels is not an MVP that solves their problem, but a bike might just be.

A bike is definitely easier/cheaper/faster to get to market than a car. It may not satisfy all potential customers, but you have a better chance of getting market traction with a bike than a car without wheels. That market traction gives you valuable feedback that help you shape your product. A car with no wheels give you zero market feedback, besides the obvious (it’s missing wheels).

But is the MVP approach always valid? I would claim yes. Assuming you don’t take the definition literally, but instead focus on the mindset behind it.

But how about … ?

In the rest of this article I’ll cover some objections I’ve come across, and provide my take on each of them.

“I build hardware products, MVPs are for software! Hardware cannot start with a limited feature set.”
Of course it can. Hardware can be designed for future expansion. Doing so means lower cost and shorter time to market, compared to a full-fledged solution. You can prepare a hardware product for future performance improvements, as well as for future functionality expansions.

I build hardware products, I can't build an mvp?! Wrong! #mvp Click To Tweet

Building an robotic lawn mower? You can design electrical traces and leave space for infra-red, rain and heat sensors even though they are not there from day one. Building a TV? You can again leave space for “smart TV” components that may not be there in rev A.

“But I build B2B applications. My CRM/ ERP / Documentation / Intranet/ Storage product has competition. I can’t launch with LESS features than them!”
Wrong! Of course you can. Established products has a legacy they need to manage. They have functionality that was needed in the past, or that was asked for but never used. Established products often support multiple technical platforms. And they will often have a diverse customer base, which has grown organically over time.

You have the luxury of finding a sub-market or niche where you can satisfy your users needs without a long laundry list of features no one will ever use.

I build B2B products, I can't get away with an mvp! Of course you can. #mvp Click To Tweet

“But I am in vertical X. I need to integrate with an existing ecosystem that my vertical depends on. Integration is 95% of the work – so no MVP for me!”
Again I disagree. Sure there is value in integrating with existing systems. It may even be necessary to get to certain sub-segments of your market. But it is not mandatory. No vertical I have ever seen has 100% of their problem space partially covered by existing products. That means in any vertical, you will find sub-segments, certain users or certain problems that can be addressed or solved without that integration.

Find your users, find their pain points and give them a solution better than todays. That will be enough to get a chunk of users on board, who will help shape your product.

“But I build games! I can’t possible launch half a game!”.
Sure you can! You may not be able to scale back on graphics quality, sound effects, music or the story. Doing that might kill the experience, and when it comes to entertainment you can’t make such a sacrifice.

I build games, I can't possibly build an mvp! Sure you can! #mvp Click To Tweet

But who said you need all game levels/maps/scenes on launch day? Who said all possible in-game objects have to be there day one? No one! Build the basics, build a framework, draft a story and deliver a highly entertaining product. Allow your self to leave some parts out for later delivery.

TL; DR

Trying to find product-market-fit? Trying to build something your users or customers truly will use and love? The minimum viable product approach is a great way to get there. This is true no matter what type of product you are trying to build. It is also true no matter what type of market segment, vertical or type of problem you are trying to address.

In my opinion the minimum viable product approach can be used when building hardware, software, business-to-business, business-to-consumer, enterprise, infrastructure, gaming, entertainment or any other type of product.

The difference between an MVP and a full-featured product will vary depending on the type of product. But there will always be a difference big enough to make it worthwhile taking the MVP route.