Jacob Wenger, CPO at Shortwave, on building a standalone business on email

When we launched Shortwave, there was a large contingent of these former Inbox by Gmail users who really connected with our product. Many of them are even thanking us for bringing back Inbox, which is not exactly how we frame our product—they're inspirations from Inbox, but we’re trying to evolve even the things that Inbox brought. I would say the earliest signs of product-market fit we're seeing are with that group, that contingent of people.

Permalink

How do some of the opinions Shortwave has about email affect the design of the product?

One of the opinionated things we're trying to do is change the look of emails and deprioritize certain things. We're trying to build a product that spans a spectrum from these asynchronous discussions that you normally have on email all the way to synchronous chat that you have on messaging apps and tools like Slack. 

We think it's better to have these in the same tool, but it also means that our UI needs to be much more chat-like. This implies that we need to be really good at making sure we’re parsing the history of emails well and not showing you these large blocks of indented forwarded messages.

It also means that we do a lot of work to do things like hiding signatures by default—hiding them behind the dot-dot-dot. 

If you're looking at something in a chat-style email, you don't want to see signatures after every single message if it's just a one-sentence message. We think the UI of email matters a lot, and it changes the way you interact with it. We find that when teams adopt our product, they end up sending emails that are a lot shorter—more like they would be in a tool like Slack and without the extra, unnecessary aspects of email, which is, "Hey there," at the top and a "Thanks" sign off at the bottom.

There have been various products in the space—Mailbox, Sunrise—that were shut down after getting absorbed into a bigger company. I'd be curious to hear how you think about building a standalone business on email.

All of those products were definitely an inspiration for us. A lot of those brought new innovative product designs and features to their apps. Mailbox brought swipe actions. Inbox by Gmail brought bundles. All of these features are an inspiration for us to continue to push the boundaries on the innovation we can do on the product side.

They also showed us that the business fundamentals are really important. All of those tools had good single-player consumer experiences, but they didn't really have a path toward actually getting people to pay for them and serve real business use cases.

You can look at the calendar app Cron as another example of this—a company that is taking an app and trying to think about the business use cases up front and make sure that you have customers who are going to be relying on your tool to do their job and therefore will pay you in order to support all of the users we want longer term, who maybe are using it more for personal use cases and the pricing is too much for them to pay.

Permalink

What's the thesis for why folks will pay for Shortwave on top of what they’re already paying Google for their email via Google Workspace?

The market, to some extent, is already showing its willingness to do this with other apps. Zoom is a great example of an app that comes pre-bundled with Google Workspace. You have Google Hangouts or Google Meet, whatever they call it now. Despite that, you have a tool that has come in with a better user experience that people prefer using and has taken over that free tool by storm. I think there are also newer players in this space. I think Pitch is another good example here, replacing Google Slides with a paid offering. 

Ultimately, the way we look at it is that email is a critical tool for a lot of businesses. If we can build a product that makes those business users more productive and better teammates and make it easier for them to collaborate, even if it is a small percentage, we're confident that businesses will pay for it because over time, the benefits will outweigh the costs.

You mentioned that to build a good team email client, you’ve got to build a good one for individuals first. Can you say more about why that is so?

We’re trying to build a team email client in the sense that each person on a team will bring their own personal account and have their own personal inbox. 

There are other classes of team email clients like Front, where you have a shared inbox, and you're trying to get everyone on board and share an email inbox. With a tool where you’re actually bringing your own email account, in order for you to make use of the team features that we have, things like channels and being able to replicate those features in email, we first have to download your email and make it so you're not overwhelmed with the number of notifications you're getting with your personal email. This is why we have a lot of individual email features. 

First, though, we need to focus on making sure that individuals who just bring their email can use us as a regular email client and can be successful at that.

Permalink

With a prosumer email tool like Superhuman, the primary value prop seems to be speed, to get through each individual message as quickly as possible. How do you think about Shortwave’s positioning in respect to Superhuman with regard to product as well as that value prop?

Superhuman is definitely a great product, and their focus on speed is very impressive. It’s a very fast product, and they seem to be doubling down on that heavily. Ultimately, I think our philosophies as a company are a bit different. 

I would say Superhuman's aim is to get their users to inbox zero as quickly as possible. Shortwave’s aim is to get users to “inbox organized.” Our theory is that inbox zero is actually not an achievable goal for many people and is what causes a lot of stress of feeling like you need to get to this end state which, for busy people, is very difficult.

I think the other side is that our target customer is slightly different. Superhuman is built for power users. That's why it is very keyboard-centric. Their command palette is also very heavily geared toward power users. We’re trying to build a product for median users—that everyone at a company can use. That implies we need to not hide too much functionality behind keyboard shortcuts and behind power features that only a smaller subset of our customers are actually going to use.

It still means we need a great user experience.  We need to have keyboard shortcuts. Those are still things that exist in Shortwave and are a focus for us. However, we need to make sure that whenever we're building features, we're building it for a user who may not be a CEO or a founder and may not be as tech-savvy.

Permalink

When it comes to building a new email client in 2022, what do you see as the big challenges? What is something particularly difficult about this?

There's such a broad feature set, so there are lots of parts. You think about a tool like Gmail. It’s a set of a ton of different features, and you can build your own workflow on top of it. Some people heavily use 'stars.' Some people archive everything in their inboxes. Other people keep things in their inboxes and use the unread status. Other people use labels. There are so many different features that you can build your own workflow. So, when you're trying to build something that is to replace Gmail, and you want people to migrate to your tool, you have to make sure that they can migrate their workflow onto yours. We’re trying to go with a very opinionated workflow that we think is the best way for the average person to manage their inbox.

It revolves around our 'pin,' 'snooze,’ and ‘done’ features. In order to do that, though, we still need to understand how everyone is using labels, how everyone is using stars, and how we can map them into our system. I think migrating workflows is a big piece here.

The other piece is there are large technical challenges. Every time someone signs into our service, we have to pay a large upfront cost to import a lot of their email and store it. This is not a small expense and is also not a small amount of work to import years and years of people's emails. There are a ton of technical challenges here. We have offloaded a handful of these by building on top of Gmail. They handle spam. They handle deliverability for us, and this allows us to focus on the actual user experience. We’re trying to differentiate ourselves in this sea of many different email clients.

Permalink

Can you talk about the Shortwave tech stack Specifically, I’m curious whether you use email APIs like Nylas, and how you think about build versus buy on a high level.

Our tech stack at a high level is that our web and iOS apps are built in React and React Native, and on the backend, we're running on Google Cloud. Our backend is written in a language called Kotlin. We don't use any services like Nylas. Instead, we interact directly with the Gmail API. The main reason we do this is because there's a lot of interplay in Shortwave between the client and the server, more so than in most email clients. This gives us flexibility—interacting directly with Gmail gives us the flexibility to really tune that the way we want. 

Some examples here. When you're talking with other users on Shortwave, we actually deliver your messages in real time via a side channel. You can see typing indicators and get messages immediately, and we still send it over Gmail on the backend. Being able to control the entire server aspect of this gives us the control to do both of these things at the same time in parallel. 

Another example is that we do a ton of work taking HTML emails and, when possible, converting them into a rich text format that we've defined so that you get a consistent display experience. You get the same set of colors, you get the same text, you get the same formatting, and this is all possible because we’re actually doing all of this on our servers when emails are coming in. As far as build versus buy, I think there is a right time to do both.

We’re buying in a sense when, by using Gmail, we’re offloading a lot of the spam and the deliverability to them. We’re focusing on the areas we consider to be our core competencies and our core differentiators, which are the actual user experience and the workflow. The key here is don't outsource your key competency and focus on the areas that are the largest risk for your company. 

The largest risk here for us is not necessarily that Gmail will cut off our access but rather that we won't build a differentiated product that actually achieves product-market fit. Whatever we can do to focus more time on that and less time on building infrastructure, the better.

Permalink

A lot of the early team of Shortwave was on the Firebase team. I'm curious if there are lessons from that experience that have carried over about building products?

We learned a lot of lessons during our time at Firebase—a few we've carried over. 

One is to talk to customers. Generally, a lot of developer tools made it  really hard to interact with any sort of community if you were a user of that developer tool. We started very early on saying we wanted to talk with customers at every stage of the development process and have really good support for our existing customers. We’ve brought that to Shortwave as well by trying to have great support, replying to users quickly, and making sure we include them throughout the process. 

Very early on, we started an alpha, where we brought in a bunch of users, even when the product was still very rough. We have been iterating with them for years. By the time we launched a few months ago, we already had many years of users trying out our product and giving us feedback. 

Another lesson we learned is you have to design a workflow, not just a disparate set of features. This goes back a little bit to what I mentioned about Gmail. I would say Gmail is a product that has a disparate set of features, and it's a build-your-own-workflow. We think that it’s better to have an opinionated workflow that makes common things easy and intuitive and then makes hard things possible.

We thought about this in Firebase—of designing APIs so you could do real-time sync really easily. If you needed to do something that was really complex, it took a bit more code, but it was possible to do. Similarly in Shortwave, we want the common actions—pin, snooze, done—to be front and center. If you want to do other things, we want to make them possible, but those are the things that might be hidden behind an overflow menu or a bit less in your face.

Permalink

Why “inbox-organized” rather than inbox zero?

I think in many ways, we do view your email inbox as a to-do list. In most email clients, you don't really get the tools to manage it like that. You end up with a wall of chronologically sorted threads, and each one is its own independent unit. This essentially means you have a laundry list of work to get through. It doesn't give you any power to treat this like a to-do list that you don't want to bring to zero right now. 

We want to focus on inbox-organized so you essentially know that if anything is new, you need to act on. Otherwise, you want to have a list of work that’s prioritized the way you want it prioritized, but it doesn't necessarily mean that it’s all done right now. Very few people are ever going to get through the whole list. Especially if you're a person at a business where you have a long list of stuff you want to build, you're not going to get through all of your to-dos on any given day. So we’ve built features which support not getting through everything.

An example here is being able to drag and drop in the Shortwave inbox and change things from the chronological sort and make it so you can sort in any order you want—being able to drag one thread on top of another one and create custom bundles, where you can name it and write out the task that you want that’s related to these two threads, instead of having them at different parts of your inbox.

Permalink

How do you think about the customer education and onboarding side of helping folks get onboarded with this new approach to email?

I think one of the main reasons Superhuman ends up doing in-person onboarding is because it helps with the retention of users in understanding how to use the product. At some point, this becomes unscalable, although they are definitely attempting to scale it as much as they can. 

For our product, where we're trying to appeal to median users and everyone who works at a company, it's not a scalable solution for us to say we're going to onboard everyone for 30 minutes with an in-person onboarding. We think about this like, “How can we design the product so that the workflow is as intuitive as possible without having to have someone over your shoulder explaining it to you?”

Part of this is through a good onboarding experience. We have this thing—we call it Shortwave 101—which walks you through the main 'done,' 'pin,' 'snooze' workflow when you first sign up. There are definitely many iterations of it that we’ll build in the future, but we’re focused on getting people up to speed without them having to actually talk with us face-to-face.

How do you think about Shortwave’s positioning against Gmail and Outlook?

The short answer here is that for a while, we're going to be built on top of Gmail, and we’re focused on getting the user experience right. We think that we can complement Gmail very well, and we do as much as we can so that we sync data back and forth between Gmail. If a user wants to go back and forth between our products, they can do that seamlessly. 

Ultimately, Gmail is a product that's used by, I think, 2 billion people now. It’s such a wide and diverse set of people that it’s a very large market in and of itself. We're not necessarily trying to replace Gmail right now. We're trying to find our own place within the Gmail ecosystem.

Longer term, we have ambitions to move beyond Gmail. To support other providers like Outlook. To provide our own hosted solution. Right now, like I said, we're focused on making sure that the user experience is right. Ultimately, the biggest risk to us as a startup is that we're not able to build the user experience that people want on Gmail. If we're not able to do that, then the rest of those things don't really matter. So our attention is on that part.

Permalink

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.