Let’s talk about why you haven’t launched your product yet, and how you can get it to market today.

Launch delay is a company killer. The startup graveyard is littered with ideas, prototypes, and even full-blown MVPs that never saw the light of day. Most of the good ones, I can assure you, were beaten by a faster competitor. And I’d be willing to bet that happened because the products themselves were over-engineered to the point of paralysis.

You can’t let this happen to you. Look, I get it. We’re innovators, we’ve got a bit of dreamer in us, and we’re perfectionists. But we also don’t want to build the absolute best and most awesome product that nobody ever heard of.

The truth is, there’s never a perfect time to launch and there’s never a perfect MVP candidate. At any given moment, there are a million different reasons why you shouldn’t launch your product.

Let’s remove those reasons.

Step 1: Narrow your scope by going back to full manual

I’ll be honest with you. I’ve been struggling with a new product myself. Engineering paralysis can happen to anyone, including those of us with over 20 years of startup experience launching dozens of new products.

In my case, this new product is not only something we’ve never done before, but it could ultimately be the first step in changing our business. It’s also an inherently complex product, and it will ultimately require a lot of automation and technology. So I’ve got pressure plus difficult, and that’s never a fun equation.

The problem I had is the same problem that delays a lot of MVP launches. Every time I got close to launch, I found myself tripping over one more uncaught detail that would ultimately doom the product. This forced to me to come up with a series of fixes and workarounds.

I cycled like this for a couple weeks, then it hit me. I was trying to launch too much too soon. So the first thing I did is go back to full manual and totally de-scope the entire MVP.

I’m a big believer in crawl before you walk before you run. Every new product ultimately comes from a manual origin that’s nothing like the product itself. A blunt example: Microwaves are essentially fire in a box. That’s ridiculous, but no matter how much automation you strip away to start with a crawl, you’re never at full manual. You can always go more manual.

To solve my problem, hell, to even see my problem, I had to go back to full manual. Once I started there, I solved something like 90% of my launch impediments. The MVP won’t be sexy or innovative, in fact it won’t be anything like the product I eventually hope to deliver. But there’s a reason we crawl, and that’s to prove the product will eventually run.

Step 2: Shift your focus from the product to customer results

As a result of narrowing my scope and ditching most of the automation, my MVP is no longer what I imagined, but it’s still the minimum viable version of the eventual product I’m imagining.

So what I need to be thinking about now are the results my customer should expect, not how my product is going to achieve those results.

I’ll use Uber as an example here. Uber sells a pretty simple concept: Push Button, Get Ride. Now, if we were to strip away all the automation needed to make Uber operate, you can imagine that once that button is pushed, a whole bunch of people would be scrambling to find the rider, find a driver, dispatch the driver to the rider, and then use a physical credit card swipe to complete the transaction.

That’s basically how a taxi service works, so it’s pretty close to full manual.

The MVP mandates that the core process is the top priority. So the offering still needs to be Push Button, Get Ride. How we get that done, whether it’s APIs or a bunch of people scrambling behind the scenes, really doesn’t matter to the customer as long as they have a button to push and a safe ride shows up in a reasonable amount of time.

What we’re trying to prove with our MVP is that concept is viable, not perfect.

Step 3: Prevent the critical mistakes, don’t sweat the small ones

When we’re trying to get something new to market, it’s easy to get bogged down in the details of everything that could possibly go wrong. The truth is there will always be one more thing that will go wrong before we launch, and then one more thing immediately after launch, and then many more things after that.

What we need to do is understand the worst case scenarios of the outliers and weigh the risk to the business and, most importantly, to the customer. We need to eliminate the big risks to the customer, meaning we need to ensure their safety, security, and privacy, as well as prevent major inconveniences for them.

Those small-risk outliers though, they will always happen. If they don’t happen often and they don’t bring much pain, we shouldn’t cross those bridges until we arrive at them. And we’ll never arrive at them if we don’t launch.

Step 4: Remove customer friction first

When we start to build automation and innovation back into our MVP, we need to start automating and innovating on the customer side. The business side can wait.

Back to our Uber example, the customer needs an app with a button. That’s the first half of the “Push Button, Get Ride” offering, so that’s where we start. Now, let’s say that all we have is that button and the customer’s mobile number. The next step in the “Get Ride” process is to figure out where the customer is. If all we have is that mobile number, we can go still go full manual and have a dispatcher call them and ask them where they are.

But that sucks for the customer. So the first step in removing customer friction from the product is having their GPS tell us where they are. Once we figure that out and make it work, we move on to the next automation step closest to the customer.

Note that these steps may not be linear. The next biggest customer friction point might occur at the end of the process, like having to pay with a physical credit card. So the next automation step might be collecting payment through the app instead.

The goal is to replace the most customer friction with the easiest fix. The challenge is to do that in a manner that allows us to scale without killing our margins.

The main reason we need to hold off on automation until after we launch the MVP is because we won’t get a true sense of where the friction causes the most pain until we actually get the product out there.

Step 5: Limit your audience and launch a pilot

Here’s the best advice I can give you about an MVP. Never, ever launch an MVP without a pilot and a limited customer audience. Ever.

Even if you’ve conquered all of the technical and logistical challenges that your product will produce. Even if you’ve scoped properly and tested 100 times with 100 friends over 100 days, something will go wrong. A lot of things will go wrong.

You want to mess up at the dress rehearsal, not on opening night.

There are a lot of ways to limit a customer audience. You can make it invite only, you can limit location, you can launch it with a single large customer or organization. It doesn’t matter how you limit the customer base, you just need to know the upper end of the impact so you minimize your chances of having to shut the whole thing down when things inevitably break.

With a limited pilot, even if your MVP is a disaster, you’ve narrowed the scope and the audience to a level where you can minimize the damage and eventually keep swinging for success.

That’s what we perfectionist dreamer-innovators do best.