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 looking for ways to order lifestyle and beauty services to their home or office 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’ve been testing the apps, but didn’t have the capacity to do proper load testing, and suddenly those 500 early adopters who registered upfront through our website seemed like a risky volume to begin with.
- “Who knows what will happen when those hundreds of users will simultaneously download the app and start messing around with it!”. (That’s me, scaring the hell out of my partner 2 days before launch…).
- “It will be like one of those zombies scenes where the heroes hide inside an abandoned warehouse surrounded by dozens of zombies!”

We agreed on 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 on the AppStore
  3. We should create an “invitation only” popup that will allow us to gradually let the zombies in…

Following that horrifying evening, we developed a beautiful full screen popup that showed up right after sign up.
We’ve sent various invitation codes to our early adopters and submitted the app for review.
We were ready for the zombies!

Few days later the app was available on the AppStore.
We’ve waited.
We’ve waited for a few days to be honest.

Needless to say, the zombies didn’t show up.

In fact, besides occasional users who tried the app, we didn’t witness any special activity.
  • We’ve started calling our early adopters who made the effort to sign up in advance, but for some reason didn’t even download the app, saying they were just “too busy” 
  • We’ve explored our MixPanel and crashlytics logs to see if there was a problem with the app
  • We’ve checked our server internal logs 

We’ve discovered a few interesting things that week: 
  1. Our early adopters were very anxious to register through our website, but when it came to downloading the app and using it - they were much more hesitant.
  2. The first organic downloads were mostly bots scanning the AppStore. 
  3. Our “invitation-only” popup sucked   

It took a bit of an investigation in our internal logs to realize our genius iOS developer (that was me 🙋🏻‍♂️) really messed up the early adopters module.
In fact, the result was so bad, it was more like a riddle… Something like: “let’s see if you could figure that out” kind of challenge:
  • The labels sucked
  • It popped up immediately after the SMS verification code was entered, 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)
  • As a result - entering an invitation code such as “friend” would automatically change to “Friend “ (including an extra space at the end)
  • We could easily solve that extra space problem by “trimming” the text… (a basic thing in UI development) 
  • For some reason we (🙋🏻‍♂️) chose not to…

The result was that the few users who did try to bypass the early adopters module (and there weren’t a lot of them) - failed to do so.
We’ve found typos, extra spaces, verification codes instead of invitation code and other goodies in our logs.
We had to somehow roll back the early adopters module.

Luckily for us, we had an on/off switch for this module (as we do in most of our features [here’s why]).
After a few days of waiting for the zombies, we disabled the early adopters module and put an end to this magnificent farce.
 It didn’t bring those zombies, of course, but we’ve learned a lot from this experiment:
In the early days of your product - there’s practically nothing you can do to tear your product apart.
You can send thousands of invites, cut your prices in half, give out free coupons and nothing bad will happen.
(And the same goes with new features in an existing product).
Gaining traction takes time.  

The takeaways from this story: 
1. Be bold. 
Whether you are launching a completely new product, new feature, or exploring a new idea - do it with 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 totally fail to survive a zombies attack you will at least know that you’ve found gold, which is much better than 10 incremental iterations. 
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 in the case of a rare zombies attack. 
You can read more about best practices when developing a mobile app in here: handling the long tail of mobile apps.
3. Invest in your logging
Don’t settle with the standard tools. Add your own, based on your specific needs. 
We’ve created a really 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 a full visibility of what’s going on in the field - to everyone, not just the developers.  
4. Don’t overestimate the importance of some technical glitches. 
Technical glitches are usually simple to solve compared to creating a product market fit, creating healthy unit economics, and retaining your users. 
Don’t let technical challenges stop you from making your bold moves. You can always fix stuff along the way. 
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. The risk of breaking something is usually minor compared to the benefits of constantly exploring new things and gaining that knowledge about our customers.
In fact, as the cliche says: a week without learning something new is a week lost. It’s your duty to keep changing and polishing your product (like a curling session!) as it’s the only way to keep improving it.