Onboard your users — lesson learned from Superhuman

If you’ve been on Twitter recently — roughly 5 billion tweets have (most likely) clogged up your feed with sentiments such as:

“Superhuman has moved me — both physically and emotionally.”

“This tool saved my marriage — I shall sacrifice my first-born-child for the cause.”

“I lived in a world void of happiness. Since I met Superhuman, I can now hear color.”

For those who don’t know — Superhuman is an email client that costs $30/month per user…

Now, your first thought might be:

“Goodness Brendan, who are you following on Twitter? Maybe switch it up a little? We’re worried for you and your feed. Love, Mom.”

Shortly after, you might say to yourself:

“How are they charging this much for an email client AND receiving such praise?”

So, I began to dig and a recurring theme presented itself:

To use Superhuman, you have to go through a 1:1 onboard session with their team.

In our current world of immediacy — where robot-baristas will mix your double-espresso-mocha-latte whilst accelerating 0 — 200mph in 0.3s with a Tesla roadster— it shocked me people would be willing to hop on a 30-minute call to learn email??

Obviously, demos and onboarding, complete with personal Account Managers, are nothing new in the world of B2B SaaS. But, most founders building a tool like Superhuman would probably slap together a (garbage) self-service onboard flow and hope for the best.

Now, instead of trying to guess why Superhuman uses this strategy — we copied it…

— — — — — — — — — — — —

Before we get straight to it — a little context:

While stalking Superhuman, we simultaneously were speaking with users about the shortfalls of our product. Several similar conversations led us to rebuild the entire foundation. Not the most fun thing to do, yet it presented an opportunity to switch up our process…

— — — — — — — — — — — —

After going heads-down for 4 weeks, the first-version-of-the-newest-version of Toybox was ready. Instead of simply sending out a poorly-worded-mass-blast email stating:

“Hey, we built something new. Check it out. Danke.”

We slapped a “beta” sticker on and emailed everyone letting them know if they wanted “exclusive access” — they’d have to have an onboard session with yours truly: me.

— — — — — — — — — — — —

Since early December, we’ve sent out emails to our 5,000+ subscribers, have booked 75 sessions, have onboarded 45 users/teams and been ghosted by the remaining. We’re currently following up with the ghosts (i.e. people who booked time but never showed up to the meeting).

— — — — — — — — — — — —

Superhuman has it right.

To onboard every user takes a lot of time. Simultaneously, it has been the best use of our time. This process allowed us to kill several birds (hopefully pigeons) with one stone (HMU if you know the person who has mastered the art of murdering multiple pigeons with a single stone — or call the police — either one). In a nutshell, with one 30-minute onboard conversation, you will:

1. Build empathy with your users
2. Create personal connections with your users
3. Test the usability of your product
4. Teach your users how to actually use your (shitty-MVP) product.

How did we do it?

When embarking on this onboard journey, we decided to forge our own path. Both Jono (co-founder) and I have never gone through Superhuman’s actual onboard flow (I’m sure it’s much better lol) but here’s how we did ours:

Structuring our emails:

To send the emails — we created some simple drip campaigns using Autopilot.

I cannot recommend Autopilot enough. In the past, I’ve used Marketo, Pardot, Mailchimp etc. and this is by-far-and-away the best bang for your buck.

The first email was a blast to our entire list. Within Autopilot, we set a delay of 3 days to send a follow-up to those who did not open the first email.

AutoPilot Drip

We then segmented the users who clicked the link in the first email but did not book an onboard session and sent them a different email.

For the email itself, we went with a plain-text body to make it feel more personal. We tested both Calendly and YouCanBook.me for actually booking the time of the meeting. We had some issues with both tools regarding time-zone differences but I’d still recommend either over the back-and-forth of trying to find a time that works :)

There was some confusion with the copy in this email based on the responses. Because of this, we tried a few variants for our follow-ups.

Onboarding our users:

We use Zoom for video conferencing. I mean, it just works…

The general flow of the onboard session is as such:

1. Hello, I’m Brendan.
2. How are you doing?
3. *Make a quick crack about the weather.*
4. Chuckle-chuckle.
5. End Scene.

LOL jk lolz (great joke). The actual flow is as such:

• A quick introduction and I lay out how the onboard session will go.
• I then ask — before we start — if they wouldn’t mind describing what they’re working on and why they’re interested in [THE NAME OF YOUR BIZ HERE].

That bolded question above is GOLDEN. It sets the stage for the entire session you’re about to have. They’ll start describing the pain they’re currently experiencing and why they think you’re tool could help solve it. Now, don’t just let them answer this in a hot-sec and move on. Dig deeper and keep asking why — this is where all the juice is. If you’re still trying to figure out the true-problem you’re looking to solve and wtf you actually built — this is where you’ll find some of those answers.

• I then send over the link to our beta and ask if they wouldn’t mind sharing their screen (for some of the sessions — especially where there are multiple team members on a call — I’ve demoed the tool myself and followed-up with instructions and links after).

Side-note. I also use Notion. Within Notion, I have a large table where each row is 1 onboard session. I then create a “Page” for each session that I can open and take notes in. It’s the best and I love this tool soy much.

• You might have a trillion features but now is not the time to show them all. You want to constantly be referring back to the problems they described and tailoring the entire experience around those. For instance, they might say: “we constantly lose track of logged bugs because some are added in Jira and others are thrown into Slack.” So, instead of showing them how the Asana integration works — you’ll focus your time showing them how they’ll never lose a logged bug again because all are centralized blah blah blah.
• Once we’ve gone through how it works, I’ll ask if they have any other questions, comments, or feedback. Often times, we’ll get some good insights here but be cautious — I’d definitely discount any feature-requests given at this moment since the user hasn’t actually taken the tool for a spin.

Side note part-duex. During the sessions, users may ask how certain things work or what clicking X will do. When this happens, you don’t need to automatically tell them the answer. Take note of where they got hung up and ask them how they’d envision it to work or what they think it does. This acts as a mini usability-test. Once you do multiple sessions, you’ll see recurring trends and areas where users are confused/get held up. You can then fix these problems and see the results in subsequent sessions.

• Normally, the entire session takes between 25–30 minutes. In the end, I go over the beta details and that by being a part of it — it allows them to have a voice in Toybox’s evolution and the features we build etc…

Post onboard

After the meeting has ended, I’ll send off a quick email thanking them for their time and letting them know if they run into any issues, have any questions, or are looking for new features — to reach out via email, intercom, or text/call (I give everyone my personal cell-number).

Why do all of this?

Firstly, we haven’t gone full Superhuman. We’ve built an (absolutely terrible) self-serve onboard flow, which allows people to sign-up without talking to us.

We do that because our current product is pretty straightforward (far simpler than Superhuman). However, (especially in the early stages) no matter how simple or lame you think your product is — taking the time to personally onboard your users is insanely beneficial.

Reasons why it’s “insanely beneficial:”

1. Build empathy. You learn who your users are, what problems they have, and why they think your solution could help.
2. You create personal connections. For them, it puts a face to the people behind the product they’re using. This allows them to feel comfortable to reach out if issues occur or if they want new things. For you, it puts a face to who you’re building your product for. This allows you to stay grounded in reality when prioritizing what to do next.
3. It acts as a mini-usability test. This obviously doesn’t excuse the need to do full-blown usability tests, but when it’s only two people in your apartment without much time — it’s a great added benefit.
4. It makes sure your users understand how to use your product. Your self-service-onboard-flow probably blows. Because of this, your funnel is a leaky-ass bucket. Doing these sessions can help patch that up.
5. You can write some content about it when you’re done :)

— — — — — — — — — — — —

Thanks so much for reading! We’re planning on ending the “beta” in February and will post again to see if these sessions resulted in higher-conversions, increased engagement and so forth.

If you onboard your users, I’d love to hear how you structure that process and other benefits you’ve gleaned!

Lastly, if you and your team build software and do QA — check out Toybox! It’s the fastest way to gather feedback and report bugs on your site or web app. If you’re interested in testing out our beta and going through the onboard flow above — email me at Brendan at toybox systems dot com, DM me on Twitter, or feel free to book some time with me here.

XOXOXO

Gossip Girl (Brendan)