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,