The zombies are not coming

Or: How we totally screwed up our product launch thinking that they are…

Two years ago we launched Missbeez, a marketplace for lifestyle services on-demand.

The first version of the app was available for iPhone only and included 2 apps: one for the customers (busy women ordering beauty services straight to their homes 24/7), and one for the service providers (self-employed professionals looking for ways to expand their customer reach and grow their business).

Two days before our app submission due date, we started to feel nervous about our ability to deliver.

We got closer to the Shipping date and doubts started to grow: are we ready? Is it too early to ship? Should we make another round of improvements? 

Classic mistake #1: founders always fear that their product is not ready for release, but guess what? Your product will never be completely ready, and the cost delay is always higher than the risk of having problems in production. 

Back to the story: 

So back in those days, we’ve been testing our apps but didn’t have the capacity (or tools) to do proper load testing, and suddenly those 500 early adopters who registered upfront (through our early-adopters landing page) seemed like a risky volume.

- “Who knows what will happen when those hundreds of users will download the app and start messing around with it simultaneously!”.  

That’s me BTW, scaring the hell out of my co-founder 2 days before launch...

- “It will be like one of those zombie scenes where the heroes hide inside an abandoned warehouse surrounded by dozens of raging zombies!” 

You release an app and a minute after, thousands of zombies are killing it, right?

We agreed on a few things that seemed very reasonable that evening:

1. Zombies exist.
2. They will attack us and crash our servers the minute the app will become available in the App Store
3. We can stop the zombies if we create an “invitations only” mechanism that will help us filter in small groups of users gradually.

Classic mistake #2: thinking that customers will just come, create viral loops and network effect (after all, we did mention it in our pitch deck, right?) that will make the founders rich and famous. 

The story continues: 

So following that horrifying evening, we developed a beautiful full-screen popup that showed up right after the sign-up form. and asked users to enter their invitation codes.  

We sent various invitation codes to our early adopters and submitted the app for review.

Please Apple, please approve us and let our conquest begin!

We were ready for the zombies!

[Read: Lessons learned from our App Store screenshots redesign]

A few days later our app was available on the App Store.

We waited...

Few days... 

The zombies didn't come...

Oh, except for this one: 

Which leads me to mistake number 3: 

Classic mistake #3: Thinking that the early adopters that signed-up on your landing page are already your raging fans and will immediatly use your app once it's published.

Guess what? Nobody cares, and even your early adopters are not waiting in-line to give your product a try. They will do it whenever they see fit, and it might take a while.  

We started to feel the disappointment, and wanted to push things forward: 

• We called our early adopters who made an effort and signed up in advance, but for some reason didn’t even download the app. Most of them said they were just “too busy”. 
• We explored our MixPanel and crashlytics logs to see if there was any problem with the app.
• We checked our server's internal logs 

We’ve discovered a few interesting things that week:

1. Our early adopters were very anxious to register through our website, but somehow, when it came to downloading the app itself and using it - they were much more hesitant.
2. The first organic downloads were mostly bots scanning the App Store. 
3. Our “invitation-only” popup (the one we added 2 days before the launch date) sucked. Seriously sucked...   

It took a bit of an investigation in our internal logs to realize our genius iOS developer (that was me 🙋🏻‍♂️) really messed up with the early adopter's module.

In fact, the result was so bad, it felt like a riddle… something like: “let’s see if you could pass the test and get access to the app":

• The labels sucked
• It popped up immediately after the SMS verification code, as a result, many users thought they needed to re-enter the verification code (instead of the invitation code). 
• It was case sensitive (who does that!?).
• The text field had “auto-complete” and “auto-capitalization” attributes turned-on (Someone forgot to turn them off (Yep. Me again))
• As a result - entering an invitation code such as “friend” would automatically change to “Friend “ (notice the capital F and extra space at the end?) resulting in accidental mismatches. 
• Comparing strings - "Friend " is not equal to "friend" which caused the invitation code to fail... 
• We could easily solve that problem by “trimming” the text and lowering the case… (a basic thing in UI development) but guess what... 
• Unfortunately, we (🙋🏻‍♂️me again!) chose not to do that for some bad reason…

The result was that the very few users that actually did try to install and try out the app - failed to do so quite miserably due to our silly "invitations-only" popup. 

By checking the logs, we've found typos, extra spaces, verification codes instead of invitation codes, and other goodies that simply prevented our users from onboarding the app. 

Talk about optimizing for conversion rates... 

We had to roll back the early adopters module.

Luckily for us, we had an on/off switch for this module, which is a great way to control your mobile apps once they are released.


It didn’t bring in thousands of zombies, of course, but at least it helped the few that did show up get started easily without any friction.

And that leads me to one of the most important lessons we've learned: 

In the early days of your product - there’s practically nothing you can do that will tear your product apart.
You can send thousands of invites, cut your prices in half, give out free coupons and nothing bad will happen, simply because the volumes are very low and you're just trying to build some initial traction. 

Gaining traction takes time.  

The moral of the story: 

1. Be bold

Whether you are launching a new product, new feature, or exploring a new idea - do it with full confidence and full power.

Release it before it’s ready, tease the world with it, invite the zombies in, let it break! 

In the rare scenario that your product will collapse under a zombies attack you will know that you're on to something, and that have plenty of time (and money) to fix your product. 

2. Always have a backup plan

Being bold is cool, but always include an on/off switch as part of your new features so you can easily rollback whenever bad things are happening in production.

10 product development practices that will give you full flexibility and control on your mobile app

3. Invest in your logs

Don’t settle with the standard tools. Add your own, based on your specific needs. 

We’ve created a useful logging mechanism that sent us a user-friendly description of everything that happened in the system via emails. 

It acted as a log for our non-developers employees, it had a great push functionality (since it used emails) and it created full visibility of what’s going on in the field - to everyone, not just the developers. The benefits of having such a system (on top of the technical logs) are that it helps field managers see what's going on or go back to events that already passed. 

4. Don’t get stuck on theoretical technical glitches

Technical glitches are usually easier to solve compared to creating initial traction, achieving product/market fit, or retaining your users. 

Don’t let technical challenges stop you from making your bold moves. 

You can always fix stuff along the way through frequent shipping.

Startups need to move fast, sometimes at the cost of sacrificing code quality, architecture, etc. 

That's OK.

Even today, with thousands of highly engaged customers, we are still using the phrase “the zombies are not coming” to remind ourselves that it’s OK to make frequent changes to the product and try new things, even if most of them fail.

That's it for this one. 

Before you drop off, don't forget to subscribe to my newsletter and become 23% more awesome than average.