If you’ve ever used a new product that seemed like it wasn’t finished, that probably wasn’t an accident.
One of the sneaky lessons I’ve learned in 20-plus years as an entrepreneur is that there are good reasons to release a product that’s not quite ready for prime time. What you learn can end up being the difference between building a good product and a potentially great product.
A minimum viable product isn’t just a theoretical idea. The truth is that every new product launches as a minimum viable product — some are just more viable while others are just more minimum.
The secret for going from good to great is that the market will not only validate your idea, it will tell you what to build, what not to build, how you should sell it, and how much you should sell it for.
If, that is, you launch your product with the right amount of minimum and the right amount of viable.
Why Minimum Viable Products Fail
There are basically three reasons why MVPs crash and burn:
The First — and Here’s Another Secret — Is That They Were Never Meant to Succeed
- Despite the conventional mythology of startups, we don’t live in a world where you can walk outside, spot a market inefficiency, and fill it before anyone else does.
- 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.
So yeah, sometimes entrepreneurs fail on purpose. Well, not on purpose, but we swing without expecting to hit home runs every time. Sometimes we just want data.
The Second Way to Mess Up a Perfectly Good MVP Is by Not Embracing ‘Minimum’ Enough
- If you’re an entrepreneur and you’ve ever launched a product you were totally comfortable launching, you’ve made a mistake. Everyone should be a little bit scared before launch.
- 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 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.
For every imaginable use case thread, you have to pick a point, build a wall around that point, and let the customer go no further.
The Third Way an MVP Fails Is When It’s Not ‘Viable’ Enough
- And this is what detractors point to when they say that MVPs are a bad idea.
- 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.
So how do you find the moment of truth between fear and overconfidence? Here’s a checklist I go through to make sure I’m both minimum and viable.
A Checklist for Minimum Viability
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.
You should know where the outliers are and, more importantly, when they begin to cause trouble for the customer. Then make concessions at those beginning points so things don’t get out of hand.
- Like I said before, build a wall around the outliers. Depending on what kind of product you’re building, that could be checks for proper data entry, a kill switch at a certain input level, or in the worst cases, an escape hatch to make the customer whole and get them out of the system.
- 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 knowledgeable. If it’s a website, that website should be easy to update.
You’re going to be learning a lot from your customers. Don’t fall behind.
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.
In other words, if you can’t thoroughly test a feature or even a whole feature set, consider keeping it out of the MVP. For the core functionality, make sure you rope off the outlier points and test the hell out of the core.
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.
The best way to do this is a pilot program, beta group, focus group, or any other time-limited test in which you offer the product to strangers to use without limits and for free.
- Strangers : Not your team, your friends, or anyone you know. You want honesty.
- 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.
Getting a customer is easy — when compared to keeping a customer. Your MVP will tell you a lot about what additional steps need to be taken to keep a customer long enough to deliver the kinds of margins that will make your product viable.
Be prepared to capture this information in a way that lets you act quickly when you get it.
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.
That’s not how MVP works.
You need a data strategy, whether that’s a collection of services like Google Analytics, Salesforce, Hubspot, and so on, or just manual entry into a spreadsheet or two. This strategy should give you hard data during the MVP process that you can act on and build on as you move closer to launch.
Be sure that you will get a statistically significant set of data back. Don’t launch to silence.
* * *
When you build a product and a company, you’re not just making and selling a thing or a service. You’re making, defining, and curating the market for your unique solution.
And that’s actually the hardest part of entrepreneurship. It’s not building something no one has ever built before. It’s not selling a product without credibility and a track record. Those things are difficult, sure — damn near impossible sometimes. But the true test of an entrepreneur is finding the market for that thing that’s never been built before, and figuring out how to sell into that market.
You can’t do that without a product on the market, and if you wait to enter that market until your product is supposedly perfect, you’re taking a huge, assumptive risk.
