If Your Startup Wants to Build a Great Product, Launch It Before It’s Ready

It could mean the difference between building a good product and a potentially great product

Image for post
Image for post

Why Minimum Viable Products fail

There are basically three reasons why MVPs crash and burn:

  • If you want to invent a great product, you’ve not only got dream up a unique and elegant solution to a big problem, you’ve got to solve that problem first, you’ve got to solve it right, and once your solution gets traction, you can’t turn back.
  • Thus, some MVPs are just practice runs to test assumptions around the problem, the solution, and the market.
  • Sometimes you get lucky and get it all right the first time. But most of the time, you fail. That’s the trick with startup: Fail early, fail often, and go back to the drawing board.
  • A lot of entrepreneurs, builders, makers, and inventors have a hard time dealing with the fact that some of their functionality should break when the use case for that functionality is at an outlier point.
  • If you try to build for every use case imaginable, you may end up building too much of your product around those outlier points. And when those outliers occur in a way you weren’t prepared for, they wind up taking down a lot of product functionality.
  • But go back to what I said about all products being MVPs. If the product is shit — too many mistakes, too much friction, not enough support— it doesn’t matter if you call it an MVP or not.

Your product is ready for outliers

You can go down a deep, dark rabbit hole trying to imagine every single way your product is going to perform less than optimally once it’s in the customer’s hands. But the remedy isn’t as simple (or complex) as an instruction manual.

  • Be proactive about educating the customer, and direct them where you want them to go when they need help. Catch them before they go somewhere else, like social media.
  • Wherever you send them, make that solution totally flexible. If it’s customer support, your support team should be available and knowledgable. If it’s a website, that website should be easy to update.

Your testing is thorough and complete

You may not have to fix every bug, but you have to handle every bug. Just like building a wall around outliers, don’t spend forever trying to make the product work exactly the way you want it to every time.

Your product is ready for real world use

There is a huge difference between a testing environment and the real world. Ask any developer — it’s the difference between testing an app on an emulator and testing it on a target device. Make sure you’ve tested in the real world, with real use cases.

  • Without limits: Let it break, let them use it any way they want to.
  • Free: This is optional, a discount is fine. Just give them something in return for their feedback, and make sure they have a quick and easy way to give feedback.

You have a process that’s full lifecycle and defined

You’re not just testing the product; you’re also testing the market, the transaction, the delivery, and the support. All of these processes should be ready to handle the full lifecycle of the product — from when the customer first discovers it until they stop using it forever.

Your data strategy will prove or disprove viability

This is the most ignored but most fatal step. A lot of entrepreneurs just want the product out there, and they rely on gut reaction to prove or disprove viability.

I’m a multi-exit, multi-failure entrepreneur. Building Precision Fermentation & Teaching Startup. Former Spiffy & Automated Insights. More at joeprocopio.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store