Ep. #13, Prosumer in the Enterprise with Rahul Vohra of Superhuman

Grant Miller: All right, Rahul. Thank you so much for joining me.

Rahul Vohra: Thank you for having me.

Grant: Cool, let's jump right in. Tell us a little bit about your background. How did you get here?

Rahul: Before Superhuman I started Rapportive, we were the first Gmail plugin to scale to millions of users. Then back in the day I also--

Grant: I was a Rapportive user. I remember.

Rahul: I wish I still had the database, I could tell your user number. Do you remember when you started using it?

Grant: No.

Rahul: It was probably 2010-2011. In 2012 we ended up selling that to LinkedIn, where for a period of time I ran all of our e-mail integrations.

Now I'm the founder and CEO of a company called Superhuman, where we make the fastest e-mail experience of all time.

Grant: Amazing. It sounds like you've been in e-mail for a long time.

Rahul: Sure. Although I would more broadly characterize it as "Productivity."

Grant: OK. So you think about e-mail from the perspective of productivity, not just from sending and receiving e-mail. In what way?

Rahul: In the way that our whole raison d'etre. Our goal is to literally make you brilliant at what you do, and e-mail just happens to be a part of that.

On average it's about three hours per day for a professional, so our goal is to help you do that time faster but then one day going beyond e-mail as well.

Grant: For a "Enterprise software founder," I say that with air quotes. You've really been focused on this productivity and work process, but do you consider yourself an enterprise software founder?

Rahul: I'm probably the least qualified enterprise software founder you'll ever interview.

Grant: Right. But all you think about is being more productive at work.

Rahul: So maybe from that sense, yes.

Grant: Yeah. It's an interesting perspective because you're not really focused on a lot of the enterprise ready features.

We were talking earlier, when you look at Superhuman there's no admin experience.

I'm a Superhuman user, I've been one for a long time, I pay for six accounts at Replicated.

There's no way for me to go in and do anything about those accounts.

That's a very different perspective from how we normally at EnterpriseReady talk about how to build enterprise software.

How do you think about your approach to go to market and your approach to getting people to use your product in an enterprise software sense, what makes this work?

Rahul: I think you have to mirror the product to how people are going to buy it. First of all, no one was really buying e-mail before we came along.

We had to figure out what it was that people would buy. We quickly realized that it was speed, it was joy, it was flow and the sensation of getting through your inbox really fast.

Once you know that that's what people are buying, how are they going to buy it?

It turns out that having an admin dashboard doesn't really make a difference to the reason that people buy.

Having an amazing product, on the other hand, is everything. So we've put all of our time into figuring out how to build an amazing product.

Grant: What do you focus on to make sure that the e-mail experience is better? What are the key tenets of an amazing product for e-mail?

Rahul: We have a saying inside of Superhuman, which is "What we make people feel is just as important as what we make."

What we actually make is joy in software form.

So the heritage of product management inside of Superhuman is very unlike the normal discipline of that anywhere else.

Most companies, you'd be worried about what users want or what they need or what they say they need.

At Superhuman we don't really worry about that. Instead, we obsess over how users feel.

This is very much like game design, I used to be a game designer back in the day way before Rapportive. If you think about it, a video game doesn't have to exist.

There's no requirement for a video game to be the thing you're trying to achieve is a state of mind in the user, and it's the same for Superhuman.

Were trying to figure out how to get users to a into a joyful state and into a state of flow.

Grant: That's really interesting. As I'm just processing this, it's think about "What would put a user into a state of flow with getting e-mail done."

Is that state of flow different for my personal e-mail than it is for my work e-mail?

Rahul: I don't think so. I think flow is a well-understood phenomenon. We all know when we're in flow, we know we're not.

But I don't think you would pay for flow in your personal e-mail. Rightly or wrongly, I don't think we value that time.

But we do value the time that we spend on our work e-mail.

Grant: But people use Superhuman for both work e-mail and personal e-mail, right?

Rahul: Yes. Although we don't let you use it if it's only personal e-mail.

Initially it was work e-mail only, but we realized that if you were in Superhuman for your work e-mail and Gmail for your personal e-mail, then there was this cognitive dissonance as you were going back and forth and it was difficult to fully adopt.

So we changed our strategy to be work first, personal secondary.

Grant: That makes sense. I use it for both and I find myself transitioning between both e-mails pretty quickly with the keyboard shortcuts.

Rahul: Great.

Grant: It works perfectly for me. OK, just to help provide a bit more context around productivity, what else do you think lies in the productivity space?

How else are people spending time to get productive, or what tools are they using?

Rahul: There's this new generation of productivity tools that we were just talking about earlier.

We're seeing a ton of take up for companies like Notion and like Airtable and like Zapier. We run Superhuman on a combination of all of the above.

Grant: Do you think about to-do lists as part of that?

Rahul: I think so. I think to-do lists though are a very difficult area to enter. Because like e-mail, everyone does them their own way.

Then there's this interesting tension between productivity and collaboration, so Airtable and Notion are primarily collaboration tools first and then productivity tools second.

Whereas to-do lists like e-mail are productivity tools first and collaboration tools second.

Grant: Interesting. So, what are people writing about? Is it--? Because I use a lot of Google Docs as well.

Are people writing in e-mails some of the same stuff I'm doing in Google Docs? Creating foundational documents and strategy docs, or are they--?

Is e-mail primarily just the back and forth and figuring things out about those assets?

Rahul: This is the magic of e-mail . Because it's such a powerful, flexible tool you actually get both of those things.

Roughly 50% of the e-mails that we send and receive are one-liners, it's like the e-mail I sent you earlier. "Hey, I'm running 20 minutes late." That was one line.

Most of our scheduling e-mails are one line going back and forth, but also, e-mail lends itself to those long form thoughts, documents, letters.

And that's where you get this extreme flexibility and power compared to something like Slack or any other chat platform.

That's a huge deal because you can take the time to frame your thinking, to go deep as you need, and then the recipients can triage, file, and sort as appropriate.

They can say, "I want to deal with this one now, this one tomorrow, I want to put this one away on long term reference, and I'm going to delete this one."

Grant: How do you balance that idea of deep thought that's happening and the creation that's happening inside of an e-mail client, versus--?

I know a lot of the focus for Superhuman, especially early on, was on speed. Like, "How fast is this client?"

Interestingly I remember back when you were still pretty early in the throes of building this. Everyone would just describe it, "It's so fast."

That was the key thing. It's just so fast. "Superhuman, why do you use it?" "It's so fast."

Talk about how those two things play together, and then also your obsession about speed. I'm always really interested in that.

Rahul:

It comes back to the idea of flow. Flow is the sensation of being fully-immersed and even enjoying the activity that you're doing.

How do we get you into flow? One of the ways is speed. That's pretty simple, I think, to understand. Imagine if the product wasn't fast.

Basically imagine any product, imagine Gmail and you click on an e-mail or you do a search and it takes seconds.

It only takes a split second for your mind to start to wander, and you start thinking about something or worrying about something else. Then that distraction can turn into Hacker News or a new tab or something else entirely. The next thing you know you're no longer doing the thing that you thought you were doing, and that's bad.

That is poor productivity. Some of us have more willpower than the rest of us and are able just to power through that, I know I'm not one of those people.

I suffer from distraction. The way to get around that, of course, is speed. If you don't have the possibility of distraction, then you won't be, and you'll be in flow.

One of the things that Superhuman does, this little trick actually helps people go 15% faster, is it auto-advances you when you triage an e-mail.

Let's say you're looking at an e-mail, you hit archive and immediately you're looking at the next e-mail.

In fact, before you've had the chance to think about "What is it I'm going to do next?" You're looking at the next e-mail.

Whereas in G-mail and every other e-mail client, the default is you're back at the inbox. The inbox is scary, it's distracting, or it's exciting.

It has new things at the top and you get pulled out of flow again. So, that idea that you auto-advance through your e-mail helps people go about 15% faster.

Grant: It's speed of how you actually individually process the e-mails that are in front of you, but there's also--

You focus on speed of the actual client itself, and measuring the response times in milliseconds.

Rahul: Yes. That's right. When Paul Buchheit sat down to build Gmail, he had this rule which was that everything would take place in 100 milliseconds or less.

That's because that's the threshold at which things feel instantaneous.

You don't have the opportunity to be distracted or even to lose focus during that time.

Nowadays, Gmail isn't like that. As I said, things take many seconds and search is even longer. So, we just decided to bring that rule back.

Maniacally focused on it from the earliest days, the very first thing we did was build a performance framework where we could measure how long every single thing that the user interface does actually takes.

Grant: So you're instrumented down to every action that someone is doing, you're measuring and then sending that data off to Datadog or some other source? Or is it just an internal tool that you built?

Rahul: We don't share the data with a third party, it's collected centrally and analyzed.

Grant: That's just metadata about using the application, you're saying? Every click or something, you're recording the speed at which that took.

Rahul: Yeah. If you hit a key we'll measure how long it takes for that to actually take effect.

Grant: So you've used that to make improvements in the product to make sure that there's no area that takes longer than a hundred milliseconds.

Rahul: Absolutely. What we found, and I think as engineers we intuitively know this to be true but we have the data to show it, is that products get slower over time.

The more features you add, the more code there is, slowly but surely that code takes time to run and the thing gets slower.

The only way to mitigate that is to instrument for performance ahead of time to decide a threshold.

The right way to pick these metrics is to pull a pair of percentage and speed.

For example, we might say that we want 99 % of message shows to appear in 100 milliseconds or less.

Grant: Sure.

Rahul: We might say we want 99.9 % of key presses to take effect in 10 milliseconds or less, because you do not want lag when you're typing.

Grant: In the infrastructure software world we refer to these as SLOs, Service Level Objectives.

Rahul: Gotcha, OK.

Grant: Then "These are the things that you're measuring." You're saying, "We need to make sure that these activities happen within this threshold."

Then Service Level Agreements, SLAs, are based on top of those. So then whatever you make the agreement with your customer is actually an SLA.

That's how we talk about it in the infrastructure software world.

Sounds like you've come to the same conclusions around "You have to have these thresholds and percentages that you want to happen within that time frame."

Rahul: That's fascinating. Yes, we have about 25 SLOs, and about 15 of which are really core.

Grant: So you're measuring those constantly, and if you have a learning set up and if something goes out-- Or before, you probably do it because you deliver a client.

You're probably just testing it before you ever release the client, so you'll never release something that it's going to take that long. Right?

Rahul: Actually, we do the release.

Grant: OK.

Rahul: Maybe we should rethink how we do this, but the way it works today is we make a thing because we believe the things should be made.

Then we release that and generally speaking, people like it. But that typically does make the software slower.

It's only really after it's in the hands of thousands of customers that we have the data to know what impact it's having at scale.

Then we can go back in and make everything fast again. We go through this cycle repeatedly.

Grant: Because you might just kick that feature out if no one's using it.

Rahul: Yeah, exactly.

Grant: So this way you're not over-optimizing things that aren't going to be used.

Rahul: Right.

Grant: That makes total sense. One of the things that I love about Superhuman and I think that a lot of people are starting to talk about is the onboarding process you've been using.

Obviously you have some very different perspectives on how people should go to market, or different ways they could go to market.

One of your go to market techniques has been this very intensive onboarding process.

I've heard other startups talk about emulating that, so if someone wants to emulate that what is so unique about your onboarding process?

Can you tell us just how it works end to end, as much detail as you possibly can? I'm really interested in the dynamics of it.

Rahul: Sure. For those who don't know, we do in-person onboardings typically over a Zoom video call. They're about half an hour in length each.

The contents of the onboarding is you get to meet one of our wonderful onboarding specialists, we have a increasingly large team of folks who do that role now.

They're not only experts in e-mail, they're also these gurus in productivity.

Grant: You were the first onboarding specialist too, right?

Rahul: I was, by accident. I did the first few hundred myself and we really stumbled onto this strategy.

The reason that we were doing them and I was doing them in the beginning was any number of things.

I was doing pricing analyses, I was interviewing users, I wanted to watch people in the first half an hour of using the product to find all the bugs that I didn't know existed so we could fix them.

As it turned out, it also was an incredible way to onboard users and we just had this decision internally where it was like, "This is going to be it. This is the way that we scale."

As crazy as it is, and literally everybody tried to talk me down from scaling this.

But I was like, "Nope. This is going to be our weird thing that we do." We did decide nevertheless to scale it.

The way it works today is you get invited to Superhuman, it's still invite only. You fill out a survey, the survey has 15 to 20 questions where you qualify, basically.

You say, "Here's how I do my e-mail."

If the qualification looks good, if we believe that you would be successful with the product, we then invite you to sign up for an onboarding. We then authorize your credit card.

We don't actually take any money at that point, but we do authorize the credit card and for anyone considering implementing this, I would highly recommend doing that.

That's a good way to not let in folks who aren't actually serious about fixing the problem that they may have.

Then you schedule a time, and we use Calendly for that. On the Zoom video call you'll get to meet one of the onboarding specialists, and they're all lovely people.

Imagine the effusivity of a an Apple store greeter, and after a little bit of pleasantry they'll ask to see how you do your e-mail.

They'll actually ask you to do some e-mail. They'll have a look around the structure of your inbox and understand what your workflow is.

Once they've got a good grasp of your workflow, they'll then get you into Superhuman.

They'll configure anything that needs to be configured, and then they'll show you how to do your e-mail twice as fast as you were doing it before.

They'll even show you how to get to inbox error if you weren't previously doing that before as well.

Grant: The interesting part is you say "They watch you do e-mail currently."

Are they looking for, is there a set of 20 different patterns that people do e-mail? Are there three primary patterns?

How are they bucketing people in to then create the experience they should have in a Superhuman product?

Rahul: There's a certain number of patterns, that there are folks who archive e-mails like you do.

There are folks who delete e-mails. Some folks just let the inbox grow and become hundreds of thousands of e-mails long.

Some people care about the unread numbers, some care about the total number.

Then you get really complicated setups where some folks are using Gmail's multiple inbox feature.

In all of those cases, we can do it and do it better and faster. But in order to know what to recommend to you and to truly personalize it, we do have to understand how you're doing it today.

Sometimes we'll actually recommend changing workflow. For example, if you're not archiving e-mail and if you're micromanaging an unread number, which is crazy if you're hitting a shortcut or even worse clicking a button to continuously mark things as unread.

Then we'll actually talk through the benefits of doing it a different way, of archiving your e-mail instead.

Grant: OK, so part of it is even helping people understand how to be more productive in e-mail, which is realistically probably something no one's ever tried to show them.

Rahul: Yes. Which is strange if you consider that we spend hours a day on this thing and no one has ever taught us how to do it properly.

Grant: That's funny, that's a great point. When people join your company and they come from different places and having used e-mail personally a lot, or if they're younger they're used to messaging apps.

To come in and then no one trains people how to use e-mail, no one trains you how to be most productive on e-mail when you first join a company.

Rahul: Yeah. It's absurd.

In fact, the bigger the company you join the more e-mail there will be. It can quickly become a dominating force in your life.

Grant: That's really funny. I read GTD, Getting Things Done. That was the pattern that I emulated, and I'm sure that's a fairly common pattern that you've seen over time.

Using your inbox as your to-do list, basically trying to accomplish anything that can be done in less than two minutes, you should do right away.

Using a "Read later" concept to move things around a little bit. There's just a handful of patterns that I think getting things done, GTD, that methodology prescribes.

Rahul: We definitely do recommend most of those things. Obviously if you can do a thing very quickly, you should just do the thing.

Things like "Read it later" or "Snooze," or whatever you want to call that feature. Those are controversial features and ideas.

There is an argument to be made that you should only ever really look at an e-mail once or look at a thing once.

If you continuously snooze it to later, then you're doing multiple reads and over time that can become very inefficient.

However, some people are able to use that feature to become way more productive.

So we take a fairly agnostic point of view on that. It's there if you want to use it, and it can be incredibly useful if used properly.

Grant: So you're training people how to use e-mail, which is something that we should all probably do in our companies anyway.

That's valuable in itself, just showing people how to become more productive in the thing you're having them do for so much of their day.

You're showing them how to use Superhuman, and Superhuman introduces a bunch of different strategies for becoming a power user.

Keyboard shortcuts is the one that jumps to mind at first. There's other things you guys think about, but you train people on using keyboard shortcuts. Or is that--?

Rahul: We do, yes. That's another huge part of the onboardings.

For those listeners who don't know, the product is very aggressively keyboard shortcut-driven, in fact it's deliberately annoying to use with the mouse.

There are very few buttons, they're not particularly big, you probably shouldn't be clicking them.

Grant: They're hard to see.

Rahul: Yeah, but on the other hand it's a complete joy to use with the keyboard.

Grant: Sure.

Rahul: That's because we believe in this keyboard-first world for desktop software.

Look at any trader on Wall Street or any analyst, they're not clicking around in Excel. They're whizzing around it using the keyboard, and they're working twice as fast as you and I might if we were using the mouse.

Our goal is to get everyone to that level of productivity.

Now, not everyone is a developer like you and I and has grown up with keyboard shortcuts.

But what we found is that doesn't actually matter if you have people who are sufficiently motivated to turn up for an onboarding session.

It doesn't matter what their background is, they'll be able to learn keyboard shortcuts.

Grant: Yeah. I didn't use them very often before Superhuman, and then it became now I expect them everywhere, because they just make you faster.

It's funny, when I hit Command + Enter and something doesn't send, I'm like "What's wrong with this thing?"

These become the expectation, which is great because you're establishing new patterns that I think other people can hopefully use.

The advantage would be for everyone to follow the same patterns, and to leverage the same keyboard shortcuts to do similar actions.

Send, search, these things you're doing over and over in different applications. If they can all follow a similar pattern I think it's advantageous.

Rahul: I would agree.

Grant: Cool. So the interesting part here is you have this team.

Did you develop a training that you're providing for this team, so you can onboard someone who's excited about productivity tools but they're not a trained onboarding specialist.

That's not a skill set that you can just put into, Indeed.com and find thousands of people who know how to do onboarding for e-mail, so you must have a pretty extensive training program that you put people through. Is that right?

Rahul: We do, yes. For folks thinking of implementing this, I would say that you can go through four phases, I think we went through about four distinct phases.

Phase number one was the founders should do it, the founders should do the first few hundred onboardings and understand what should be in the onboarding, what should be not in an onboarding.

When I was doing them initially they were one and a half hours each. Then I got them down to an hour long, and now we do half an hour onboardings.

That's through the process of iteration and trial and error, you'll figure out what's important.

I think step two is have a member of your senior leadership team do the same. Not you, but someone who understands the product, the strategy, the positioning, everything inside and out.

In our team that was Gaurav, who's our head of growth. I started to slow down the number of onboardings I was doing, and he started to speed up.

He at peak was doing about 25 a week, and that went on for a few more months.

Now you have two people in the company who both really deeply understand this process, and I think at this point you should start hiring for it.

But instead of hiring specialists, I would hire generalists. What we did at that point is we hired two onboarding generalists, although we didn't call them that at the time.

I think the actual job title was "Full stack growth." To operate all the way across the funnel, everything from a little bit of marketing through to the onboarding, through to customer support and outreach after the fact.

The reason you want generalists, by the way, is to your point. There is no training in place, you just have two people in the company who happen to know how it works. So you need scrappy entrepreneurial types who can learn by osmosis and quickly on their feet.

Then they became offers to onboarding specialists over time. We really started to tighten up the process, we got it down from an hour to half an hour long.

We figured out how to systematize Zoom, Calendly, Stripe, Zapier and wired all these things together to make a really efficient onboarding system.

When it became really clear that this whole enterprise was working, that churn rates were low, retention was high, virality was through the roof, we decided to really step on the gas and hire a lot more of these folks.

That's when we created the onboarding specialist role.

That's also when we invested in training, so now there's an eight week long training plan for any new onboarding specialist.

There's a certification at the end of that called "Becoming Superhuman," so you have to prove through a little mini-exam that you know what you're doing and that you're ready to do it for real.

There's a really fun shadowing process along the way as well, where you get to sit in on onboardings as they happen and then slowly you start to do them yourself.

Then you'll be watched by another onboarding specialist and critiqued as you go.

Grant: Along the way, were you just documenting the onboarding process you were doing?

The hour and a half version, did you have a Google Doc that you used and wrote down what you did?

How long did it take you to start to build some of the collateral around this?

Rahul: It wasn't me specifically, I'm not a particularly well-organized person and documentation is the least of my skills. So this was our head of growth, Gaurav.

Grant: OK, so once Gaurav started doing it, he started documenting it in order to create a process?

Rahul: Exactly, yeah. We're talking about your dear friend William earlier, you need that person. Someone who's extremely organizational, very process-driven.

Gaurav trained as a strategy consultant, so he was excellent at execution. You need somebody like that to run this kind of an organization.

Grant: Yeah. Is he still running it?

Rahul: He is.

Grant: OK, cool. He's built that up and now you're hiring lots of folks in here.

Because that feels like that will be the key bottleneck, is how many onboardings can you do in a week?

Because you have a human factor there where you're doing these.

Now obviously you can do three times as many per person than you could two years ago when you first started doing it, but that will be an area where you'll need to really expand.

Rahul: That's right. We're at about 45 onboardings per person per week.

Some folks in some weeks will stretch to 47 or maybe even 50, and we're always looking for ways to get more throughput in any given week.

Grant: Then the benefits are primarily, you mentioned users engage and they know how to use it.

They're retained and they are more viral, they talk about it more. Is that right? Or are there areas where it's really helped, or what's the primary thing you've gained?

Rahul: I think the primary thing that you gain is the ability to turn every user into a power user of your software.

Then there are some definite business advantages. Yes, churn is way lower. Yes, retention is way higher. Yes, virality is way higher.

Ultimately you end up leaving people with a really great positive connection to the company, and to the brand.

I think this is definitely one of the ways where you can build a world-class brand, because everyone who has ever used your product will have spoken to an expert about the product.

Grant: From the moment that I was onboarded I remember, I still send feedback.

I'm sure you get a lot of feedback from folks when they run into little things, or they have questions.

There's probably more engagement from users well after the fact because they created this personal relationship.

Rahul: Speaking of feedback, that's actually one of the things that we train on.

One of the last parts of an onboarding is training you how to send us feedback if you have an idea or if you run into a bug or something.

As a result, we get a ton of feedback because we're specifically asking for it and showing you how to do it.

I think at this point we have north of 26,000 individual pieces of feedback that we've triaged and logged.

Grant: It's going to be harder for you to get all the features that I keep requesting.

Rahul: Fortunately, it's not 26,000 different features.

Grant: Yeah, cool. That's super interesting and helpful.

I think for anyone out there that's building an enterprise software company, spending time with your early customers in this way feels like probably--

It's a lot of time, it's a lot of effort. But I think the interesting piece is this isn't just the person you're selling to, it's like you're actually enabling every user.

When I brought my team onboard they all had to go through this exact same onboarding.

It wasn't like I just got trained and I invited them, they also had to get trained.

Rahul: Yeah. We've experimented with letting users onboard each other, but we found that being a customer is nowhere near the same level of expertise with the product.

Actually more importantly, nowhere near the same level of expertise when it comes to training and coaching.

Product knowledge is one thing and I can imagine that a really highly motivated user could learn everything there is to know, but there's a definite skill set in listening, watching, teaching and training that we select for when we're hiring for this role. Most customers don't have that because that's not their job.

Grant: Because you basically only use e-mail one way, your way. You've basically been training everyone to use it, to try to evangelize your own way.

Rahul: Right. Whereas what we try and do is understand your way, and then help you do it better.

Grant: Yeah. Which makes tons of sense. I think this onboarding piece has really been a unique offering that you've-- Or, a unique approach you've taken.

It goes hand-in-hand, but I think it's related to this trend that I think Superhuman is.

It's the only example that I can think of, but this idea of prosumer in the enterprise.

The consumerization of IT has been this idea for a long time, just bringing better experiences into enterprise software.

Stop using some Java UI, start making software feel like software that we use in our personal lives.

I think you see that all over the place, where design has become an important part of software and where usability of applications and onboarding has been important. But how would you define the pro-sumerization of enterprise software?

Rahul: I think we're still in the wave of the consumerization of the enterprise.

Grant: For sure.

Rahul: We do expect our software to become increasingly polished and delightful, and we expect the same quality from our business software that we do from our consumer software.

We're just at the start of this wave of pro-sumerization of the enterprise. I think it's perhaps easiest to understand through an example.

Let's take the example of our new board member, David Ulevitch, who joined from Andreessen Horowitz.

He was previously the CEO of Open DNS. At that role, he would be in his inbox constantly, constantly triaging to ensure that he never blocks anybody on his team.

He then sold that company to Cisco and then he ran their security business.

He joked to me that when he was at Cisco, he became a human e-mail router.

Now he's a VC at Andreessen Horowitz and being brilliant at e-mail is more important to him than it's ever been before.

So it didn't matter whether he was a CEO or a corporate executive or a general partner at a well-known VC firm, his needs as a prosumer have been ignored for years.

Yet there were tens of millions of power users just like him all across the world. So, I think this wave will be characterized by building high-end premium tooling for the busiest people. E-mail is just the start of that.

Grant: Yeah, it's almost like-- I'm going to relate it to having an executive assistant.

Which is this way that those same people generally get more effective is by having someone assist them with a lot of the tasks that come up in day to day work.

Is Superhuman the software version of an assistant, in that case? Does that make sense?

Rahul: I think I understand the analogy, but I wouldn't characterize Superhuman as software assistance.

I think EAs are incredible, I'm fortunate to work with one and they can make your life tremendously easier and make you way more productive at work.

I think I would broadly agree that the set of people who work with an EA should have prosumer software, but the set of people who should have prosumer software is wider than that.

Grant: Yeah, I agree.

Rahul: It's much, much wider than that. That's why it's an interesting business opportunity.

Grant: An EA, you're going to pay $60-120,000 dollars a year, whereas prosumer software you can maybe buy for--

Superhuman is $400 bucks a year, basically. $360, and then you could add on a handful of different software applications and come in at orders of magnitude less than what you'd spend to hire someone.

It should open the market up by orders of magnitude as well.

Rahul: It's an interesting pricing segment. Consumer stuff is generally $5-10-15 at most dollars per month.

Enterprise stuff seems to start at around $50 dollars per seat, median seats-- Median Salesforce seat is $125.

So you end up in between, which is why Superhuman as a pro-sumer piece of tooling is $30 dollars a month.

Grant: How did you land on that price?

Rahul: We did a pricing analysis. If you recall in phase one of our onboarding development, when I was doing all the onboardings, one of the things I was doing was pricing surveys.

So when I sat down with each user, I would show them a demo of the product and then I would say, "Before we jump in, do you mind if I do a quick pricing survey with you?"

So we used the Van Westendorp pricing sensitivity questions. I think I showed you this at the time.

Grant: Maybe.

Rahul: So there are four questions involved, you ask "At what price would Superhuman be so expensive that you would not buy it?

At what price would Superhuman be so cheap that you would be worried about its value and therefore you also would not buy it?

At what price would it be expensive, so you'd have to think really hard about it but you would still actually buy it?"

And number four, "At what price would you consider it a bargain for the money?"

Now most companies in tech orient around the fourth question, the bargain for the money question.

Because they typically are creating or entering new markets and they want to get all the users as fast as possible.

But if you're building for premium users, if you're doing this pro-sumerization of the enterprise thing, then it makes much more sense to orient around the third question--

Which is "At what price would you consider it to be expensive and you'd think about it, but you'd still actually buy it?"

Because that way you're charging the premium that the product is also delivering.

Grant: It likely will change over time. I think people will start to realize over time how much value they're getting from Superhuman and probably willing to pay more.

Rahul: Exactly. So we regularly do this survey, and when I did it in those first onboardings the median answer was $30 dollars per month to the third question.

When we more recently surveyed our users, we found some degree of price elasticity.

Meaning that folks would be willing to pay more than we're currently charging today, up to about $35 or $40 dollars.

I suspect that the longer that people use the product, that the more willing they will be to pay for it. But of course, our focus isn't on that.

That's not our business model, our business model is to charge a premium but fair price for the value that we deliver.

Grant: Do people end up putting this on personal credit cards and expensing it?

Or are they getting a company card, do they already have a card because they're a founder and they're executives?

How are people paying for it right now?

Rahul: 60% of our seats are either paid for directly by the company or paid for by the user and then expensed to the company.

Grant: OK. Only 60%?

Rahul: I think so, yes.

Grant: So 40% of people are paying personally and not expensing it?

Rahul: Yes.

Grant: That's a higher percentage than I would have expected.

Rahul: The way that we look at it is those folks find so much value in the product that they're willing to buy it personally.

Maybe they have a manager that doesn't understand, or they're in a less enlightened company where you can't easily expense things that you probably should be able to.

Nevertheless, they are still able to, or still rather willing to buy the software.

But then the other 60% of our users, they are at an enlightened company where "Yes. Obviously, this thing is to make you faster. You should be able to buy it."

Grant: Makes sense. Is there anyone that just said, "We have to roll this out to everybody in the company."

Or is that-- I know you're against that, right? You don't want everybody using it unless they do e-mail all the time.

Rahul: Yeah. We get that request fairly frequently and we pretty much almost always say "No." A lot of companies are obsessed with the notion of wall to wall.

Slack for example really wants to be wall to wall. It's just not a thing for us. We want to be in the hands of the people who do e-mail for work, and for whom work is e-mail.

That's roughly a third of any given company. That's also going to support the price point. I think if we were wall to wall, then we'd have to lower how much we were charging.

Grant: Interesting. Because then if someone's using e-mail twice a week because they're a developer and just doesn't get e-mail, then they don't really value it.

Their company is not going to value paying that for them.

Rahul: Yeah. So imagine, let's say for the sake of argument that the product was $10 dollars a month and it was a thing that everyone had.

The people who don't have high e-mail volume won't see the point. They'll be like, "I don't know why I have this $10 dollar a month thing."

That will become the narrative of the product. The people who do have high e-mail volume will think it's amazing, but then you're not actually getting the value you should.

Grant: Yeah, you're right. It's such a different perspective than most software companies take.

Most people think about "Expand. Get as many users on board as possible, sell as many seats. "

That's a generally contrarian thing to do, but it sounds like you really believe that's a core value proposition.

It's a core belief that "We're not going to expand to people who aren't going to use it."

Rahul: Correct.

We only want customers who are actively using the product every single day.

Grant: What are the core reasons for that?

Rahul: I believe that is what you do to build a long-term sustainable business. Revenue is a side effect of success. What success actually is, is a large number of people using your product. So that's the thing we're optimizing for, not just the set of people being large but the fact that they're also using the product.

Grant: And loving the product.

Rahul: Yes.

Grant: You talk about this a little bit in your--

You wrote this great piece for First Round about finding product market fit. In that you described this whole process of segmenting, and finding your real users.

That really illustrates what you're talking about here. You don't want to sell to people inside of a company that aren't going to use and love your product.

Rahul: Yes.

Grant: I don't want to dwell too much on that product market fit thing, I think you've talked about it a few times.

And if anyone hasn't read it, it's an incredible piece about Rails framework for how to basically quantify product market fit.

Rahul: Yes. There is this metric that you can use to determine whether or not you have product market fit, which is you ask your users how they would feel without the products and then you let them say they would either be "Very disappointed,""Somewhat disappointed" or "Not disappointed."

It turns out this has been benchmarked on hundreds of technology companies, that--

If you get more than 40% of your users saying they would be very disappointed without your product, you almost certainly have product market fit and you'll be able to grow quite quickly assuming you can keep that percentage high.

Another really interesting thing about-- I didn't come up with that metric, by the way. This was Shaun Ellis who benchmarked this back in the day.

What we came up with was this really powerful, iterative method for optimizing that number.

Once you have it, what do you then do next in order to keep on increasing it every week, every month, and every quarter? That's what the content of that post is all about.

Grant: You also segmented the responses to figure out who your real target user was.

Rahul: Yeah, that's the thing with product market fit. There are actually two variables. There is the product and the market itself.

So what I advise that companies do is that they run the survey. You get your initial number, in our case I think it was 22%, which is obviously significantly lower than 40%.

But then you look at who those users are, who are the users who really love your product? Who could not live without it?

You should consider re-segmenting your approach around that user.

That means everything from changing your positioning, changing your marketing, changing your copy, through to just not onboarding or not accepting or not selling to users of other kinds.

Grant: Did you take Superhuman away from anyone that wasn't in the right segment?

Rahul: Of course not. But we definitely stopped going after certain segments.

Grant: "You don't use e-mail enough. No Superhuman for you."

Rahul: That would be something.

Grant: Yeah. OK, so this methodology is interesting because when I think about selling into enterprise software companies one of the differences is that all users are not created the same.

You have the buyer, you have the decider, you have all these end users and you have all these different people inside of a company that's using your software.

I'm just trying to map this on, because it feels like in a world where all users are equal and in a prosumer world this model works really well.

I'm trying to figure out how it would be different in a world where an engineering manager is making a decision for the engineering team, and the engineering team uses it, and then the CFO is paying for it. Does that make sense?

Rahul: It does. Here's what I would recommend in that scenario, is that you run two parallel sets of surveys.

Philosophically, I still believe that we should be building software that's useful and loved and gets the job done, whatever the job happens to be.

I would run the survey for the engineers. Let's make sure that they would be very disappointed without the product and that it's really fulfilling some need.

But they're probably not the only user type in that scenario, we also have engineering managers who may need to run reports, pull data, manage their team.

I would also separately survey them, and if it turns out that the engineers couldn't care less about the product but the engineering managers love it, well then you might be able to grow a business.

But sooner or later a competitor will come along who scores on both, and they will almost certainly be able to outcompete you in that scenario. So, I would run two sets of surveys.

I'd make sure both the end users as well as the deciders really love the experience of your company, even if they're not using the product.

In the case of the CFO, I think the way it would work in most companies is that they will just defer to the engineering manager.

The engineering manager has a budget, they can go and ask for more if they need to, but at the end of the day they're deciding what software to buy.

Grant: Yeah, I think to your point it basically adds an extra layer of complexity because Superhuman thus far was able to segment out and say "We're going to focus on the end user experience and making sure this is great."

And then you say, "OK. These folks over here don't use e-mail enough, let's not focus on them. Let's only sell to people who are doing e-mail professionally."

In a world for most enterprise software companies, they're going to have an extra layer of users on top of that.

So they're going to, to your point, need to do a secondary survey and then try to build the things that will satisfy both of those users and make them both get over 40. Right?

Rahul: Yes.

Grant: Yeah, OK. That's super useful. That's great. Again, check out this post. How do they find it, what do they search for?

Rahul: If you go to Google and search for "First round Superhuman," then it should be the top result.

Grant: Perfect. So let's talk a little bit about some of your fundraising history, because I've known you for a long time and this is the first fundraiser you've actually announced, I believe.

Rahul: That's correct.

Grant: So the Andreessen round, $33 million, just very recently. Who knows when this podcast will get published, but very recently you raised this big round from Andreessen. But you've raised money before that, right?

Rahul: Yes. We had raised about $18 million before that.

Grant: Can you talk through that funding history? Who was involved, how you did it?

Because I know you also have this interesting perspective, like "Always be fundraising." Can you talk a little bit about your fundraising strategy?

Rahul: Yes. My perspective is "Never be actively fundraising. Never be out there actively soliciting investors for money, but always be open to the idea that you could take money if a sufficiently good investor was interested."

So, that's one thing. The second thing I would say is "Always be raising one round ahead of traction."

Raise your precede when you would normally have nothing, raise your seed when you would normally be raising a pre-seed, and A when you are normally doing the seed, and so on and so forth.

First bit of funding for Superhuman came in late 2014, I was recovering from my LinkedIn experience and taking some time off, trying to figure out what I was going to do next.

I was talking with our mutual investor and good friend Ed from Boldstart, and he ended up writing the first check into Superhuman.

Grant: OK. He had known you for a while, was excited about what you did at Rapportive, then just wanted to be involved in whatever you were going to do next.

Rahul: Pretty much. I was bouncing any number of ideas off him, and one day towards the end of summer I called him up and I was like "Ed, I have it."

He says, "What are you going to do? Do you have a deck?" And I was like, "I do, but it has only one slide."

So I send it over to him, and it was just a screenshot of Gmail with all the bits that I didn't like red-inked out.

I said, "Are you looking at it?" He was on the phone and he said "Yes."

He's in New York and I'm in San Francisco, and I said "OK, cool. I want to build Gmail, but it's going to be really fast and it'll be very pretty and everyone's going to pay for it, and everyone's going to love it."

And he was like, "Amazing. I'm in. Can I wire you some money, please?" I said, "I don't even have a company bank account yet."

Two days later, he wired me the money. So that's how we raised the first $750K, and even that was done in tranches. He wanted to invest a million at that time.

I said, "I don't want a million dollars. I'll take $250,000 dollars to get the ball rolling.

Then a few months later, I let him put another $250K and a few months later, another $250K after that.

By the end of that year, we had about 750 raised.

At that point, I went back to all of the Rapportive investors who made anywhere from 3-5X their money on the sale of that company.

So obviously, they were very excited to invest again, especially given it was thematically the same.

Grant: Sure.

Rahul: That brought us to about $2.5 million dollars raised.

Then First Round got wind of what we were doing, and invited me to come in and show them what I was doing.

Again, I didn't have a deck. Although by this point we had a prototype, so I walked in and I said, "We're building the fastest e-mail experience of all time."

They were like, "We don't believe you. Can you please show us?" So I showed them the demo and they were like, "That is really fast."

Then they said, "Can you please come in and pitch the partnership?" And I don't do partnership pitches, I really dislike them.

So I didn't do them for this round of financing, I didn't do them back then for the seed round either.

I said, "I really don't want to, but I will happily meet each of your general partners individually." Similar idea to onboarding, so I--

Grant: You'll onboard them into Rahul.

Rahul: Exactly, welcome to my crazy world.

So I did the product demo for each channel partner at First Round, and answered each of their questions individually, and they were more or less the same.

You could have argued it would be more efficient to do it in a partnership meeting setting, but I'm not very good in a group conversation.

I'm much better one to one. So they ended up investing another $1.6 million, which took us to about $4.1 million.

That's what we called our seed round, was that first $4.1 million dollars that was raised at a variety of valuations with the First Round tailing it out.

Then I had this board meeting with Bill, Bill Trenchard from First Round. At the time, we were only building desktop software.

I remember saying to him that, "For anyone to seriously use our software we were going to need a world-class mobile experience."

And he asked me, "How long would that take to build?" I said, "If anything, it's going to be harder than the desktop app.

I think it will take at least 24 months to make it amazing from the point when we start." He said, "Can money compress that?"

I said, "No. This is a quality game." He's like, "Then we need to get started ASAP."

And I said, "Yes. But we don't have the money to do that. $4.1 million is just about enough to pull it off on desktop. We need that and more to also pull it off on another platform."

And he said, "Then we should go out and raise money."

So then we did an interesting strategy that turned out to be super effective for raising the series A, which is I didn't go out and hit the market for a series A, I like to do this thing of interstitial rounds.

So I did this between the seed and the A, and between the A and the B.

The post-money valuation on the seed round was $16 million dollars, and I knew I wanted to raise a very healthy A, so I went back to Ed in New York and I said, "Here's the conversation I had with Bill.

We're going to raise some money, we're going to build mobile. Now, how much money do we think we're going to raise for the series A?"

We had a bit of back and forth and I was like, "I think I'm going to aim for $10 million. $10 million sounds like a really healthy amount of money."

And we can both agree that we want a great valuation, let's say 10 on 40 post money, 50.

I was like, "Yes. This sounds amazing, let's go do that."

So I said, "I'm going to let you invest at half that valuation. I'm going to let you invest at $25 million. Not too much money, like half a million dollars, let's say. That way we get the ball rolling now, I can hire a mobile engineer now, and you get this amazing discount into the series A."

Of course, he was all over it. He was like, "Yes. Let's do this." Literally signed the documents right there, and then other investors got wind of what was going on.

They were like, "We really want to get in on this $25 million dollar round as well. Especially if he's going to raise 10 with the post money at 50."

But the thing is, you can take on that much money at 25. You can only take on maybe a million dollars, and when that caps out you're like "All right, this is done."

If you want to invest, you now have to invest $10 million and it has to be at a pre-money of 40 with a post money of 50. That was how our series A got preempted.

I went to market raising a small amount of money at 25, and we got so much inbound interest that it became $10 million on a post money of 50.

Grant: You didn't really have a lot of users at this point. Did you have some early users, or people paying you at this point yet? Or not?

Rahul: We didn't have any paying customers at that point. We had maybe 10 users.

Grant: Your early investors are the people that were just beta-ing it out basically, trying it.

Rahul: Exactly.

Grant: But you had a great product that people saw the potential in.

Your story is so perfectly aligned to building this, because one of things I remember is you always talked about building all the things into the e-mail client that need to be there by default.

Everything you did at Rapportive, like snoozing and remind me, and all these other things that people were using plugins to solve, "There should just be one e-mail that does that for you."

Rahul: Yes. Especially for first time founders, one of the big things you have to convince early investors is that there isn't execution risk.

That you will be able to hire a team, you'll be able to write high quality code, you'll be able to market it and so on.

Fortunately, as a second time founder, I don't have to spend time and neither do you.

Because also a successful second time founder, we don't have to spend time convincing people that we know how to execute.

We can have a higher level conversation, like "Give us the idea. Are you good or not, and how much money is it going to make down the line? How big could this thing actually be?"

If you're fortunate enough to have that level of conversation, then you can easily run a fundraising strategy like we did.

We did exactly the same thing in-between the A and the B. The Wall Street Journal helpfully leaked all of our numbers a few weeks ago, so I'm not revealing anything.

The post-money on the series B that we just did was $260 million. I ran an $80 million dollar round a year before, so once again one piling into the other.

Grant: In the $80 million dollar round, from what I remember, I think you brought a lot of angels into that round.

Rahul: Yes.

Grant: I think this is actually a really interesting part of it, because you have some incredible angels.

I don't know if you want to name a few of them, and they are all users as well. They use the product, they love the product.

Talk a bit about the benefits and why you've got angels involved and around like that.

Rahul: Sure. Some of the folks we have involved, Des and Owen from Intercom, John from Stripe, Nat from GitHub, and so on.

There's a quid pro quo here, which is I really believe that the folks who are early to a platform ought to be able to benefit financially if that thing happens to do well.

Then obviously, of course I want the company to do well. So this was a way of aligning incentives near perfectly.

If you let leadership in the company or in a customer's company rather, invest in yours, not only will they benefit if the company does well but they can also evangelize both internally and externally for the product that you're building.

Grant: I think for your audience, which are people who are doing e-mail professionally, CEOs and founders and other folks like that.

You have lots of other non-executive titles in there, but the people you have involved are the super power users, the top of that game.

They're able to use themselves as example, and say "I use this and this makes me more productive."

So that trickles down, where a lot of people are-- They're aspirational people that people want to be like. I think that's one of the things that Superhuman has. It has a very aspirational brand.

Rahul: Yes.

Grant: Bringing in aspirational investors who become part of your surface area and part of your evangelism is a really smart move, and a great way to do that.

Rahul: Thank you. It was by design. The idea is, if folks check out the First Round article I wrote, I use this concept of the highest expectation customer.

The highest expectation customer is defined as the most discerning person in your demographic, and critical about them is that others want to be like them because they consider them to be clever, judicious or insightful.

If I were to generalize this strategy, and if I were an enterprise founder, I've asked myself the question "Who is my highest expectation customer?"

Maybe in the example we were using earlier, you literally want to come up with names. It's the top 300 engineering managers in the valley.

Now let's set aside a pool of my next financing round, if it's 500 engineering managers let's set aside $500,000 dollars and each let them own a piece of the company.

Grant: Yeah. That's really interesting.

There's so many angles on this because number one, I think you're building a piece of software from the most discerning user requires a lot of effort and money and attention.

So I think for so long we've talked about MVP, "Get something out, get people to use it, get feedback."

And this is a different approach. You're saying "You have to build. There's so much noise in the market, you have to build something so good that they can rise above the noise.

To do that, you need money any you need time, but it's a different approach."

I think one of the valuable things of you telling the story of your fundraise is to show that it does require money and time.

It's not like this was just a thing that somebody built over a weekend.

This was a very intentionally built piece of software that you have had a team of great engineers focused on for a long time in order to get it to this point.

Rahul: Yes. I'm five years in at this point, and we've been writing code for four years.

It's funny you mention "Intentionally built," our second company value is "Be intentional." So I'm glad that comes through.

Grant: Yeah. Almost everything that you do is very intentional.

Even in your fund-raise, you can tell that you've thought this through.

You being a second-time founder, you've made mistakes previously like we all have.

You should still make a few mistakes now, but you can know some those things that are going to come down the road.

But I think it's a great example of a counter to the narrative that's become so popular.

For other people to go to emulate this in order to produce prosumer software in the enterprise, I think it's probably an approach they'll have to take as well.

So some of the things you're doing to model this out and sharing right now, I think are really important.

Are there other tools that you're like "Someone needs to build the Superhuman for X in this category."

Rahul: Two that I see very frequently as requests are Superhuman for calendar.

I think that with the demise of Sunrise we don't have a good third party calendar solution right now, and I see very common requests for Superhuman for personal CRM.

"Help me be better with people."

Grant: Yeah, both of those are fairly related to what you're doing. I can see why people would request it, because they're so close.

But there's probably a dev environment that people would love to have as a prosumer experience.

Every profession probably has something where they really would love a pro-sumer type experience.

Rahul: I completely agree. I'm beginning to see more and more of these pop up, many of which actually reference Superhuman as an explicit source of inspiration.

A jury who was previously at Coinbase is now working on an app called Linear, and Linear is issue tracking for developers but it's deliberately built with the Superhuman product principles.

It's blazingly fast, everything happens in 100 milliseconds or less.

It's keyboard shortcut driven, it's a full-screen desktop experience that I believe just works offline, so on and so forth.

That's our product playbook, that's our philosophy. I think if you build those things, you build them to high quality and it's not easy, it takes many years to do that.

Then you can credibly play at the pro-sumer for enterprise.

Grant: Yeah, but there's a high bar. Because you're trying to satisfy the most distinguishing user, that's a very high bar.

All right, Rahul. Thank you so much for being here, this was awesome.

So many weird angles we took and different ways we went, but I really appreciate your time and your insights on this.

Rahul: Thank you so much for having me.

Grant: Yeah. This was a very different Enterprise Ready podcast where we got to explore counterpoints to how you can go to market in enterprise without a thousand admin features and role based access control.

That's super granular, so hopefully this inspires some folks to take a different perspective and try something new.

The one thing that's true is you can't always follow the same formula. So folks, you've reinvented a formula here. Hopefully folks can take some inspiration that.

Rahul: I hope so.