The most difficult aspect of building a minimum viable product is knowing when it's ready to go to market. That question invites the dreaded two-word follow-up despised by most entrepreneurs and engineers:

"Define ready."

Get that part wrong, and you're facing the proposition of launching a product that everyone hates or no one uses. It's a pretty powerful demotivator. 

Let's tackle it head-on.

A Tale of Two Camps

There are two camps when it comes to building an MVP.

The pro-MVP camp will tell you that a minimum viable product, with its barebones approach to developing the engine that powers the customer experience, allows creators to bring ideas to market quickly and inexpensively. That lets them test the viability of those ideas with real, live customers, without a lot of up-front, sunk costs. Then they can make sound decisions about how to move forward to product-market fit. 

The anti-MVP camp will point to the vast number of broken and crap apps in the marketplace, all trying to make a quick buck off a bad idea. 

I'm not here to judge. But I will state emphatically that those crap and broken apps aren't MVPs. Those are just cash grabs. And cash grabs have been around for ages.

So the philosophy behind a minimum viable product isn't the problem. The problem is all about when they get released.

Defining 'Ready'

There also are two camps when it comes to releasing an MVP.

The opinions tossed around within the pro and anti-MVP camps result in two camps around the release of those MVPs. Each of these camps wrestles with defining "ready" in a different way.

One side is worried about releasing too soon and having their product publicly shredded on the open market. No one wants their first impression to be a bad impression. So as a result, startups often overbuild their product without any kind of market input or feedback, which is just delaying the inevitable--a complex, full-featured product that no one needs. 

The other side can't get the MVP out to market quickly enough, and they cut corners where corners shouldn't be cut. 

And therein lies the million-dollar MVP launch question: "Which corners should and shouldn't we cut." The short answer is, "Don't cut anything to do with the customer," because bringing innovation to market means translating innovation into benefit for the customer. 

But to get the best answer, break that question down, and answer these five questions:

1. Does the customer need this product? 

My word choice is very specific here. It's not about whether or not the customer wants the product, which is easy to determine and usually leads to false expectations of high customer demand. 

The customer has to need what you deliver with your MVP. Once they get a sense of the value and the benefit, they won't easily give that benefit up. Furthermore, there can't be any other solutions out there that fill that customer need better than yours. 

If there is no measurable customer need, don't launch the MVP.

2. Will the market accept this product? 

The "viable" in MVP is about market viability, so your MVP should be testing market acceptance. But often, that test gets substituted with a test of technical viability. That's what results in crap and broken apps. An MVP should never be used to test whether or not a product works. 

In fact, before your MVP goes in front of real customers, it should not only work and work well, it should be properly positioned and clearly priced. 

If any of that isn't true, don't launch the MVP. 

3. Can the product be delivered and used without friction? 

The "minimum" in MVP means minimum function that provides maximum value, and that also means minimum friction for the customer brought about by maximum effort from the company. 

The corners you should cut to achieve those minimums are those pieces that make it easier for your company to operate, not the pieces that add value for the customer. This is where you use your duct tape (webhook applications, third-party services, spreadsheet patches), sneaker-ware (humans manually doing tasks that computers will automate down the road), and vapor-ware (any part of the product that is rigged, hacked, or patched).

If any of those hacks impact the customer experience, don't launch the MVP.

4. Will the product scale? 

While duct tape, hacks, and patches will get your MVP to market more quickly, you should have a plan to replace all of those things with real, robust functionality. And again, you should be able to replace any of those components without impacting customer experience. 

If you don't have a plan and a timeframe to get to scale, don't launch the MVP.

5. What determines viability and how do you make the call?

Once your MVP is on the market, then what? This is another huge stumbling block for entrepreneurs and innovators, and results in products stagnating and failing. 

There will be one of three outcomes of your viability test. Rarely, you'll see an unqualified success. Sometimes, you'll be met with total failure. Most of the time, the results are inconclusive. 

So to give your MVP its best chance of moving on to actual version 1.0, define what makes it a success, in terms of customer adoption, revenue, margin, and profit. Then set expectations for what determines a success and a failure. 

Anything that falls in between those two thresholds means you'll need to readdress the feature set, which is time-consuming and expensive. So make sure the area in between success and failure isn't too wide, and prepare yourself to move forward with version 1.0 if you succeed or pack it all in and go home if you fail. 

If you're not ready to do either of those, don't launch the MVP.