Onboarding and 10 perilous Off-ramps

Mar 31

Onboarding and 10 perilous Off-ramps

Conversion and Activation

Acquisition is not the problem. Just ask the insiders at Clash of Clans, Slack or Fortnite!

If you have cracked Activation [or conversion], Retention and Revenue then your marketers crank up acquisition spend – much easier said than done, but at that stage the financial equation says that if you ramp spend then you get more revenue.

Only a few companies get to this point – when being smarter for the clicks than competitors ads means more traffic, more conversion, more revenue. The marketers continue to get budget as they’ve found what Eric Ries calls the “engine of growth”.

Cracking Activation

All eyes are on the Product Manager, Designer and Engineering to drive down Day0 abandonment. There is limited time to Activate the user before their attention deficit leads them to another problem, another game, another solution.
If the user hits problems in the first session, then they are unlikely to come back – these are Top-of-Funnel bugs  and they can kill your business.
 
This should be a science, there are many blog and Medium posts on Best Practice BUT….we’ve seen many enterprise, B2B and consumer Apps make the same repeatable mistakes. So here is a checklist of gotchas your team should sanity check that you’ve removed from your early users experience.
These Top-of-Funnel bugs are “off-ramps”.
attract-retain-convert

What are the off-ramps?

Off-ramps are the places where users leave your App. Literally the analogy is that your App is a freeway with lots of users and some, typically 70+% on Day 0 depart before getting to the destination you built the freeway for!

Solving for this is not the topic of this article, but you begin by tracking all usage to discover where the users churn and experiment to fix areas.

Here are the broad classes and specific examples of off-ramps:

Basic Functionality

The App crashes or is broken

This should be a no-brainer, good QA, beta test groups, exception handling, load testing are all the entry level things you should be doing prior to release.

Loading takes too long/Server performance

More subtle, make sure that the App has been designed to be “quick as a bunny” in the first “job-to-be-done” [See our other posts discussing JTBD]. The user will tolerate a splash screen, but let them get access to data and results quickly. Often when an App launches and there is a initial spike of load – your backend developers should make sure the servers are provisioned for the spike, NOT the pre-launch traffic. Also ensure the JSON data the App is pulling is minimal so that data flying over cell networks is not slowing the user experience.

Does not work off-line or in poor network conditions

Web Apps rarely work off-line, but mobile Apps are expected to operate sanely when there is zero or one bar on the phone.

Wrong App

Was your marketing driving users you never wanted? Does your App ‘look-and-feel’ appear different to whats in the Appstore. Are you using different names and terms?

Gates and Barriers

It’s often said that Products die of “self-inflicted shotgun wounds”. Here are several ways for Product Teams to shoot themselves in the foot.

Carousels

Picture this. The user hears about an App from a friend/colleague – they get curious, download the App ready to solve a need, yes the user has a “job-to-be-done”. Excited, they open the App for the first time and they are confronted by a 5 screen swipeable carousel telling them exactly what their colleague had already told them. They quickly swipe through and dismiss this full-screen barrier and get on with the job. OK, so no harm done? Why optimise an App for the lowest common denominator, why not optionally offer struggling user the carousel instead?

Demanding registration before an “aha” moment

This has to be my pet-hate. Why are Product Teams, so in a rush to capture a user? So they can spam them with email later? A better solution is to let the user get a great experience first and THEN they will gladly go to next base with you.

User meets in-App payment requirements too soon.

Just because Apple does this doesn’t mean you should. They are a trillion dollar company, so people know what they are buying. You still have to prove your value – convince them first of how valuable you are, then place the payment gate at a point where you are on the cusp of taking it away.

Creepy Moments

I didn’t know what to call this but if you’ve seen the Netflix series “Dirty John”, then this is the moment where the user feels “something is off”.

Private Data Requests

Why the hell do they need my birthdate? I don’t even trust this App yet. Progressive Onboarding means you can allow the user to complete their profile on their terms and their time. They will surrender that data in exchange for value you deliver.

Prompts for Push, Location, Address Book, Filesystem

Same as above, don’t ask for what you don’t need untill you are delivering value. There is some pretty good tools and patterns available to explain to the user “why”.

Poor Single Player Mode

Users generally want to feel they’ve joined a community and they are in safe company.

No first-time user data

Sometimes a new user some example data or a walk-through to get started.

Failed Invites to teams or friends.

In the pirate metrics of AARRR, this is the “Referral” step and critical to driving viral growth and reducing acquisition costs. If it breaks you are losing a significant competitive advantage. If invites are being sent via email, check your invites don’t got to spam folders. If you are suing social, make sure all authentication bugs/fails are handled elegantly.