The zombies are not coming



The zombies are coming to destroy your mobile app - the mobile spoon

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.

In startups lingo, it's called Shipping and it's exactly what we started feeling nervous about: are we ready? Is it too early to ship? The usual...

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 partner 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 zombies!”


The zombies are coming to destroy your mobile app - the mobile spoon
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 on the App Store
  3. We can stop the zombies if we create “invitations only” popup that will help us filter in small groups of users in a gradual way. 

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!

The zombies are not coming - the mobile spoon


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

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

We waited...
We waited for a few days, to be honest.

Needless to say, the zombies did not show up.


The zombies are coming to download your app!


No special activity...
In fact, besides occasional users who tried the app, we didn’t witness any activity.
  • We’ve started calling our early adopters who made an effort and signed 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 any problem with the app
  • We’ve 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 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 figure that one out” kind of challenge:
  • 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 as special fields usually need to be).
  • 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?). 
  • Comparing strings - "Friend " is not equal to "friend" which caused the invitation code to fail... 
  • We could easily solve that extra space problem by “trimming” the text… (a basic thing in UI development) 
  • Unfortunately, we (🙋🏻‍♂️me again!) chose not to…

The result was that the few users who did try to install and try the app - failed to do so.

We’ve found typos, extra spaces, verification codes instead of invitation codes and other goodies in our logs.

We had to 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]).


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


After a few days of waiting for the zombies to show up, we disabled the early adopters module and put an end to this magnificent farce.
It didn’t bring in thousands of 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.  


Missbeez app - beauty and lifetime services on-demand.


The moral of this 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 at least know that you’ve found gold, which is probably much better than 20 cautious 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 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 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 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.



Comments