Traps of Superhuman Onboarding 🪤⤵
Revisiting the non-obvious traps of concierge onboarding, why a founder’s weekly staff meeting is titled, ‘Speed and Focus,’ and weaving growth into engineering from the early days.
Welcome to the forty-fifth edition of The Baton. A fortnightly newsletter that brings you three, hand-curated pieces of advice drawn from the thoughtful founder-to-founder exchanges and interviews taking place on Relay and the interwebz. So, stay tuned!
In this edition, you’ll find instructive and inspiring pickings from the brains of Sunsama’s Ashutosh Priyadarshy, Monte Carlo’s Barr Moses, and Tara AI’s Iba Masood.
#1: “You really do want software to be scalable” — Sunsama’s founder, Ashutosh Priyadarshy, reexamines the much-revered Superhuman’s concierge onboarding practice. (Source: Relay)
There were a couple of factors that sort of coalesced that moved us from concierge to self-service onboarding. Initially, it was just my co founder, Travis, and I, who were doing all the onboarding. A two-person team.
And very quickly, within a few weeks that is, we got to a point where our calendars had literally nothing else but onboarding calls, perhaps 12 a day, each.
We were learning a lot. Sure.
But in order to build what customers were asking for, we had to start paring these down urgently from at least Travis’ schedule.
Then we decided to hire someone who would do nothing but customer onboarding. Soon enough, even this person had their calendar booked wall-to-wall.
Thus the question was, ‘okay, if we want to keep growing this way, we’ll need to:’
- hire another customer onboarding person,
- train them,
- make them an expert in the product,
- and continue this process over and over.
Going through the training routines, a part of us felt that we were almost building this meta product which was our customer onboarding.
And that made us ask: Did we really want to go down this path where we’re going to need to hire a small army of people to onboard customers? Wouldn’t it be better if we were pouring our efforts into making our product more intuitive for the end user, instead?
Once you start thinking about the unit economics of this method, it’s hard to say that this will ever make sense. Unlike Superhuman, we weren’t rolling in 10s or hundreds of millions of dollars in venture capital. We had raised a fairly modest, $2.4m round, after YC.
We wanted to be a lot more careful about how we were spending our money and we felt that it would be better spent on product development.
Plus, you really do want software to be scalable.
What we did to transition was to take all the things that we were aiming to teach customers in the onboarding process and productize them. Chiefly, what that ended up looking like was a daily planning ritual that guides you step-by-step through the process of planning your day.
This feature (a core Sunsama feature) didn’t even exist until we did concierge onboarding. In fact, it came about because of concierge onboarding. And once we rolled it out, the conversion rates were better overall, and, surprisingly, churn was down.
…
And then, at the very top of the funnel, there was a particular user behavior that clashed with the concierge way of doing things. A lot of our customers were and are people who tend to be fairly autodidactic.
They’ve built their own processes for how they manage their day, how they plan their work. So, to be told, ‘hey, before you can use this product, you need to, like book a call, wait a week, and talk to some guy,’ just doesn’t tally with their expectations. And instead makes people feel as if their hands were tied in some way.
If you’re able to generate the right kind of excitement around that process, like Superhuman has done a really great job of highlighting invite-only exclusivity. For them that works really well. Probably making the product more special. But we weren’t deeply committed to that kind of exclusive approach.
Our biggest hesitation with getting rid of the concierge onboarding was that we wouldn’t have that face time with customers to learn how they thought about their day, their pain points, which they’re kind of expressing to you as they’re going through the onboarding.
So as we went self service, we switched to a 14-day free trial. And then after people upgraded, we gave them the option to do a 1-1 chat with either myself or my co-founder, Travis.
Not as many people take that option. But we still fill out our calendars one day a week with customer calls. All of our best product insights and improvements have come from just talking to customers.
You still need to find a balance.
From time to time, we stop doing these calls when we feel ‘okay, last month we talked to a bunch of customers, and there are these big points of feedback in the product that we’re hearing again and again, and need to address.’
At that point, it’s actually more important to spend the day actually building the things that the customers need as opposed to just hearing the same thing over and over and not being able to act on it.
#2: Committing to the “thirty-minute version” of everything — Monte Carlo Data’s co-founder and CEO, Barr Moses, on the cultural apparatus required to deploy speed and focus, together. (Source: GGV Capital)
A big value or a sort of controversial value that we have is called ‘measure in minutes.’ Which speaks to the time and urgency…So earlier in my career someone told me for everything that you’re trying to do, you can do the three-week version, the three-day version, or the thirty-minute version.
And at Monte Carlo we decided early on, we’d always do the thirty-minute version. Now, it doesn’t mean that we do anything illegal, or that we do bad quality work, but rather means that we distil the work to the one or two things that really matter and we let all the other fires burn.
And that takes extreme thinking or dedication to what’s the only one or two things that matter and we only focus on them, and that translates to what we call ‘two company objectives’ that are now and forever.
And every function has only one or two things that they work on that are most important. It’s really about speed and focus. Those two terms are not part of our values, but something that we think a lot about.
My weekly staff meeting is called ‘Speed and Focus.’ To remind everyone what’s important…I’m truly obsessed about that. And I would like to retain that as we grow as a company.
I don’t know how we’re going to do it. But I’m determined to make it happen. I wake up everyday thinking about how do we move faster. My team members know it and they’re obsessed about it.
Sometimes I’ll do something and my team is like, ‘wait, why can’t you do that today, why aren’t you doing that next week.’
I recently ran a survey, to get feedback about myself. I do this twice a year. An open survey to the company. Completely anonymous. Then I actually share the results transparently, a 100%, I don’t mask anything…
And someone gave me feedback to move faster. And I was like, ‘who’s the brilliant person who said that, I’m so happy.’
So it’s become a self-reinforcing thing where people are holding each other to those things. That’s really what we’re hoping to achieve with the values.
As we’ve scaled we’ve obviously had to do things differently. The first hires that we made on the people function were two culture managers, and that’s what they’re dedicated to. They’re dedicated just to our culture.
What they do is spend a lot of time thinking about our values and how to permeate them across the company.
#3: Setting up engineering for growth — Tara AI’s co-founder and CEO, Iba Masood, documents the workflows and culture that drove 1500% YoY growth. (Source: Relay)
We did our beta launch in April 2020.
And ever since then, as we took the first steps towards building out a team, we’ve been thinking about one specific thing: How do we set up a methodology where growth is ingrained in our culture?
How do we make sure that growth as a discipline isn’t removed from product, engineering, and design teams, and instead becomes a core driver for their work?
Which meant devising structures, processes, and workflows that a) empowered engineers to make their own decisions and b) had an integral level of routine built in.
Thus we’ve had pods with 3-5 engineers structurally mapped to build around activation, retention, and some of the other parts of the growth funnel. We don’t just target an “upgrade to Node 16,” we say, “upgrade to Node 16 so we can iterate faster and ship weekly.”
Having a growth-focussed “why” behind improving tech debt doesn’t just help devs focus better but it also helps the wider team (marketing, sales, non-engineering) stay well-informed on the core product initiatives.
And on the routine piece, I believe we were able to mostly switch seamlessly to remote work because of practices we had already been experimenting with.
And an early process we debated quite a bit over was the ubiquitous yet often misunderstood, Sprint. Sprints, when done well, can be the lifeblood of startups. We also knew that we could only adopt sprints into our culture and into our product, if we could tie them to growth.
You hear a lot about OKRs these days. But the thing with OKRs is that it can be really difficult to tie them to the day-to-day work and to make teams care about them. Because, unlike sprints, OKRs are typically a bit too far removed and top-down.
So for early-stage teams in particular, and even for product teams at larger companies that need to accomplish a certain goal or to get to a certain version of the product, sprints can be the ultimate unit of productivity.
That is, the performance and effectiveness as realized in the weekly (yes) sprint is an excellent leading marker for monthly, quarterly, and annual success.
Here’s a sample weekly sprint goal: Release new user onboarding to reduce avg time to land in the product.
That sprint goal ties directly into the product funnel. And it can be shipped in a weekly/bi-weekly sprint. Of course, it might take some time to actually realize the outcome after a release, however, when engineers understand that outcome, they know exactly why a release matters.
To zoom out a little, this sprint goal stems from an OKR, which was to “improve funnel conversion by 56%,” that is drastically improve conversions from sign-up to activation to payment. A part of which was to better user onboarding.
In this particular case, we experienced a 7-fold reduction in friction for our users. Our prior product “land time” was 5 minutes and 32 seconds, and our new 6-week avg was 43 seconds. Which was huge.
…
We also, as urgently, wanted to figure out:
How can we structure sprints to be effective and incredibly more involving for our teams, versus being task-oriented and rote? What does it take (and this is still a WIP) to consistently have top-down goals and bottom-up solutions meet?
For speed of delivery, but more importantly, for effectiveness, it helps that people are adequately well-rested and that that’s baked into the routine.
If you’re seeing engineers committing code late at night, you’re likely witnessing signs of burnout. And founders, CTOs, engineering managers should make it a personal priority to be intentional about proactively identifying such signs of distress amidst the team.
In this sense, the term, sprint, can be misleading. Because essentially shipping valuable features is really a marathon. Some features can take 10 weeks to build, but the work is to break that 10-week marathon down into digestible, workable chunks.
Plus, a big 10-week project has more than a whiff of a top-down task and it can be difficult for teams to be continually compelled and energized behind goals with such huge timeframes. But the sense of ownership on a clear weekly goal is remarkably different.
This also ties to pull-request workflows and collaboration. If a pull request is very large it becomes really hard to review, approve, and have a useful conversation about.
…
Going back to deeply knowing customer problems, aside from being strong believers of using our own product, we document and share all customer conversations with our engineers. As they cannot attend most of these calls live, having enough on their plates already.
As a result, they’re able to place customer journey issues within a broader context.
Until next time,