The Changelog: Software Development, Open Source - Designing and building HEY (Interview)

Episode Date: August 7, 2020

We're talking about designing and building HEY with Jonas Downey, the lead designer behind HEY. In their words, “Email sucked for years, but not anymore.” We were super interested in how they went about solving the problems with email, so we invited Jonas on to share all the details and a behind-the-scenes look at the making of HEY.

The initial thinking behind Hay was focused more around Jason and David and some of these other people at the company who do a lot of external email. It's kind of focused around their problems first. And they're very high-end email people. Lots of emails. Jason probably individually get 300 pretty legit emails a day from people, not just from robots or bills or whatever. So that kind of is its own class of users unto itself. And those are the people who would be maybe most interested in a tool like this because it helps you tame that flow, keep things under control, keep it less chaotic.

And it's a slightly easier problem to design for because those people are high energy about email. They care a lot about it. They have a lot of opinions. It's easier to kind of suss out what they need. As we developed the product, we came to notice that the point of the hey inbox is that it's only the stuff that's meaningful enough to you that you should see it relatively quickly when you check your email. When you check your email, you might well have 30 new messages and a normal

email client might have 30 unread things. Typically, maybe two of those are important enough that like they actually warrant your immediate concern. The rest of it maybe two of those are important enough that like they actually warrant your immediate concern. The rest of it's kind of not that important. And traditional email clients don't distinguish those things very well. Being with her changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at changelog because of Rollbar. Check them out at rollbar.com. And we're hosted on Linode cloud servers. Head to linode.com slash ChangeLog.

Do not underestimate the power of the independent open cloud for developers. Yes, I'm talking about Linode. Linode is our cloud of choice, and it's the home of ChangeLog.com. What we love most about Linode is their independence and their commitment to open cloud. Open cloud means being unencumbered by outside investment and maximizing value for the community, not shareholders. And that's exactly what Linode represents. No vendor lock-in. Open at every layer. If you want to learn more, head to linode.com slash open.

Again, linode.com slash open. Again, linode.com slash open. All right, welcome back, everyone. This is the ChangeLog, a podcast featuring the hackers, the leaders, and the innovators in the world of software. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, we're talking with Jonas Downey, Design Lead at Basecamp, and the lead designer of their newest product called Hay. In their words, email has sucked for years,

but not anymore. They fixed it, and we were super interested in how they went about solving the problems with email, so we invited Jonas on to share all the details of designing and building Hey. So how do you solve email better? I guess you release a thing called Hey. That's one way.

But designing it, building it, a lot of fun stuff. We had a conversation recently with Ryan, Ryan Singer, of course, talking about ShapeUp. And he talked about how you'd used ShapeUp to build Hay. But you also mentioned Jonas as the lead designer behind that, in tandem with Jason and David, of course. So we want to get you here and talk to you about Hay and what you're doing with solving email. So welcome. Thank you. That sounds good.

What does it mean to solve email? I guess that's a big problem, right? How do you even begin? Well, we didn't start by wanting to solve email. We kind of found ourselves in the position of solving email after having explored some things. When we started out, we were originally looking at maybe making a successor to our product called HiRise, which is a kind of a CRM tool, came out in like the early to mid 2000s. And we had used High Rise a lot at the time and then kind of drifted away from it. We actually spun it off into its own company at one point and kind of found that we, the problems that we had when we made High Rise, we still had, but we had kind of just stopped using that product. So I thought, well, what if we made a new one? Why don't we take a new look at that? We had issues around external communication,

things like talking to accountants, dealing with marketing people, taxes, you know, any of that kind of stuff where you have to deal with outside vendors. We have a few people at the company who do a lot of that. And the communications is completely opaque. It's like those people handle those problems. But if one of them goes on vacation or one of them goes on maternity leave or whatever, the stuff is all tied up in email and no one has any visibility into it. So it's very hard to like hand off work to someone else when you have all these outside relationships. Yeah. So we kind of started thinking about that. It was like, how do we make a product that solves that problem better and started exploring some things

and we based the initial idea around real things so we gathered conversations that we'd had internally and made a prototype using real content to sort of bake off if we had ideas and we kept iterating on it and eventually realized that in order to do the things that we wanted to do, we needed to just own the email. It was like, we weren't going to be able to really do a good job of it and do some of the innovative ideas we had without just building

an email service full out. And then having made that decision, we decided, well, if we're going to make an email service, there has to be a personal version of it, too. So that's kind of how we ended up getting started into that. It was sort of a backwards entry into it. That's interesting to think about HiRise. I have been a 37signals more so than Basecamp user for a very long time. So I've used HiRise, Backpack, you know, all the things essentially. Like, you know, been around essentially.

And it's interesting to think about that, that Hi Rise essentially in a lot of ways was just like capturing and organizing email as a CRM, attaching to people and different stuff like that. And you all as tool makers, problem solvers, have been really solving the problem of how to handle communication. And that threads a lot into email. In many ways, it gets trapped there. In ways base camp is you know email in the cloud you know to some degree as it messages back and forth in silos very you know very specific scenarios with titles and stuff like that so

you've been already handling this i didn't consider that and i actually never thought that you all would have done an email service of some sort so when you when this was announced when hay was announced i was like okay that's different i didn't expect you to ever tackle the actual beast itself so congratulations on the courage for one but then two maybe how far back does it go that you were you know you'd kind of alluded to some of these problems you were solving how far back did you begin to do these early prototypes? How far back does a solution stem? I mean, you mentioned HiRise, of course, was pretty far back, but outside of HiRise after that?

Yeah, it goes pretty far back. So one of the things that kind of drives this is we use Basecamp for all of our internal communication at the company. And that communication is really carefully kept. Like everything's together. We all use the same tool. It's tidy. It's easy to deal with. And so the contrast of that from our external communication, which was the opposite, it was a mess and not unified at all, was pretty stark. And so the original HiRise kind of did try to solve that. But I think the reason that it fell

down a little bit for us and why we stopped using it was that the integration with email was rough. They're like, the only way to get email in and out of it was basically to forward email in and out. Later, we, I think down the road, there was a Gmail integration that worked with it, but it was like still kind of clunky. Yeah. So we were like stepping our foot into the idea there, but we didn't have the tech and the ideas and the wherewithal really at that point to make it work the way we wanted. And then a few years later, Jason and I had worked on some prototypes around that same kind of sales CRM tool idea that was closer to what Haby became. This was in like 2014. We started messing around with some ideas and we prototyped out something that was pretty interesting. It was more sales focused, but it was kind of in the same spirit.

And then around that same time, David and Jason decided to focus the company entirely around Basecamp for a while. So we sort of like did some prototypes, got something kind of interesting and then walked away from it because we decided now we need to refocus and do our Basecamp thing. So it kind of sat on the table for a long time, but these issues didn't go away. We still had the problems, and we've kind of been stewing on them

in the background for now probably a better part of six years. We finally got back into it around 2018. That's when we first started working on what became Hay. So it took about two years to go from the initial prototype to the release. If you guys intend to point, intend to solve some of the problems you were trying to do with HiRise, I'll be a Hay user on the business side for sure, because I really enjoyed HiRise and what was missing was the control, right? The manual processing of forwarding things in or pushing things in purposefully intentionally was sort of hard because CRMs are just difficult anyways. I mean like just – I've never used any of them, even HiRise, and you all are behind it.

So you tend to make more simple, usable tools, but that was still difficult to use just because of the nature of the beast. It's just difficult. And so if, hey, on the business side, sure, it's in personal stages now, and eventually you'll have custom domains or business accounts and stuff like that. So if you're going to resolve the high-rise problem and you can do it better because you control the entire flow of email, I'll be a user. Yeah, so that's more or less what we've done.

I'll be a trier at least, maybe not a long-term user. We'll try it again. Yeah. We'll try again. That's pretty much what we've done. Yeah. Now, HiRise has some kind of offshoot features that I don't know are all that likely to make their way into Hay

like it does deals and cases and things that are kind of sales-focused. I like that, too. I mean, that was interesting, especially as an organization. Maybe not everybody. Maybe Basecamp's a bit of a different type of company, but most businesses, I mean, I guess all businesses need to make money, but maybe not everybody in the company needs to be involved in deals and proposals and stuff like that. So there were some interesting aspects to that that does get tied to email, but I can see that there are outliers in comparison to what you really need to do, which is relationship manage and deals and proposals are just sort of like an additional layer on top of that. Usually in the case of most businesses, but not so much unanimous across the board. Right.

Yeah. The Hay approach is going to be more, slightly more generalized around how you work with external communications as a company in the whole. So yes, the sales team might use it, but so might the programmers. It's not just for one sort of narrow use case. The thing that's interesting about Hay is that when we first built it, we built it as a company tool first, and then added the personal capability second.

So all of us at Basecamp had been using it as a communications mechanism for us at the company before we even decided to make the personal thing. So it already exists. Like we already have that and we have tools built out that help with collaboration on email and things like that. So it's the Hey for Work version is going to be great. And we're sort of spoiled because we've been using it already for two years. Are there any kind of hardcore Basecamp users just kind of confused by the Hey tab in the service? You mean like in Basecamp how there's a menu called Hey? Yeah, exactly.

Yeah, well, the Basecamp Hey menu was sort of the spirit of the Hey inbox. We more or less took that, the Hey menu in Basecamp, and turned that into the product in a way. So it's kind of a fun story where each product kind of feeds the other one a little bit. And when we come back and start working on Basecamp again, I'm sure some hey stuff's going to find its way back in there. When I think about personal email, a couple of thoughts I have.

The first one is that everybody uses it very differently. Whenever I have conversations with somebody about how they use email, there's lots of strategies. And my other thought is that many people don't really think it's broken. I think at the extremes it breaks down. If you get massive amounts of email, it breaks down. I think when spam was more of a problem, that was a breakdown to a certain degree.

But I'm not sure if it's broken. So when you guys were going to attack this, how did you solve for those two? First of all, what were your insights about what was broken and what could be better that manifested in Hay? And then we'll get to the other thing, which is how do you deal with people all using it differently? But let's start with what was broken. You're right about that,

that there's a lot of different ways that people use email. The initial thinking behind Hay was focused more around Jason and David and some of these other people at the company who do a lot of external email. It's kind of focused around their problems first. And they're very high-end email people, right? Like David and Jason probably individually get 300 pretty legit emails a day from people, not just from robots or bills or whatever. That kind of is its own class of users unto itself.

And those are the people who would be maybe most interested in a tool like this because it helps you tame that flow, keep things under control, keep it less chaotic. And it's a slightly easier problem to design for because those people are high energy about email. They care a lot about it. They have a lot of opinions. It's easier to kind of suss out what they need. So we started with that. And then as we gradually brought hay to more of the people at the company, a lot of us aren't like that at all. We're like common email consumers where we mainly get

newsletters and marketing emails and receipts from orders and a handful of real emails from humans a week, but not that many. Right. So for us, that's a very different problem. It's not so much about filtering, you know, trying to deal with all these people emailing you. It's more about how do you keep all this like robot noise from sort of taking away your attention when it doesn't need to. Right. They're kind of in in the end the same problem, but the angles that you come at it are different. In both cases, it's a volume issue, it's a picking out what's important issue, it's being able to get back to the things you need to get back to.

Those are all consistent across all people who are using email. So part of the thing was figuring out what's the feature set, what things do we need to handle as many use cases as we can, but also what's common across all people that we can kind of make a unified front. So what came of that was this idea of the inbox, the feed, and the paper trail, right? Let's start with the inbox. So let's just talk about the title. I'm not mispronouncing it, listeners. It's not an inbox. It's an I-M-B-O-X. I think this has been the main thing I see people comment on right away.

It's like, what? So when Adam said courageous earlier, I thought, well, they're pretty courageous with their renaming of the inbox to the M-box, which to me makes me think, is it like an instant message box? I was trying to figure out what it meant,

and I had to click through to find out. It has to do with importance and immediacy, I guess. Whose awesome idea was the inbox? That was definitely Jason's naming. That was a controversial thing, even at the company. Internally? Yeah. When we first started out, it was an inbox with an N,

just like all inboxes. Normal, yeah. And then as we developed the product, we came to notice that the point of the Hey inbox is that it's only the stuff that's meaningful enough to you that you should see it relatively quickly when you check your email. When you check your email,

you might well have 30 new messages. In a normal email client, you might have 30 unread things. Typically, maybe two of those are important enough that they actually warrant your immediate concern. The rest of it's kind of not that important. Traditional email clients don't distinguish those things very well. Or they use artificial intelligence to try to guess if something's important, may or may not be. So after we had built out these flows for how to screen people into Hey and choose where they go and decide what's important to you and what's not, the Hey inbox became really just the important stuff.

So we decided that calling it a traditional inbox with an N was sort of doing a disservice because a lot of people hate their inboxes. The Hey inbox is not the same as a normal inbox. And we, it would not be honest to call it one. Yeah. So we came up with this name inbox. Now, of course people have lots of reactions to that. Some people find it like viscerally uncomfortable because it's like, it's like a misspelling. Yeah. But, um, the thing we liked about the name, though, is that when you hear it, it almost doesn't matter. Like the M and the N sound are so close, you might as well just mishear it so you can't tell.

So people will understand what it is without us having to explain what it is necessarily. Like they'll get like, oh, that's kind of the inbox. Right. What do you think about it, Adam? Yeah, I kind of got it right away. I mean, I did watch some videos and I was paying attention, but that is the truth with inboxes that people do hate them. And I think that you generally want to see things that are important, so that makes sense. But I mean, hopefully it's not a shtick that goes away. Hopefully it sticks for the long term and it becomes a defining factor for hay

because I think it's what you use email for is for the important stuff. And if that's what the inbox is for, then there you go. Yeah, I'm 100% on board with the feature. I think the idea that this is not, everything goes in your inbox, right? That's where everything lands. This is not that because it's been pre-processed.

It's been screened. It's only the important stuff. So that's a great lands this is not that because it's been pre-processed it's been screened, it's only the important stuff so that's a great feature I think the term inbox, like you said it's so close I think you might have even said it a few times earlier in the conversation and maybe nobody noticed because you have to read it and I think there's an uncanny valley to it

where it's so close to the same word and just one letter that I said it was courageous but maybe my problem is it's not courageous enough maybe you guys should same word and just one letter that i said it was courageous but maybe my problem is it's like not courageous enough like maybe you guys should have just come up with a whole new word to describe what it was and that would have been more palatable to more people is it a big deal no it's not a it's not a big deal but it's just you know we tend to focus on these things like inbox what what's an inbox you know we yeah we did buy bounce some other ideas

that were close. There were kind of two things we like about inbox. One, that it's close, so it says inbox without having to explain it. And two, it reminds you that this stuff should be important. So not only does it say what the feature is for, it also is like a little bit of a nudge. Because as you're using Hey, you might well let some stuff in there that actually isn't important. And it can be easy to just kind of let it get gross again.

So it's a little bit of a constant, hey, by the way, this is the important box. Keep it important. It's worth noting, though, to understand the basic flow of email into, hey, can you break that down for us just so we know generally how, you know, as a Hey user, how you will get email, how you have to screen it, et cetera. And kind of like, it's meant to be processed by the person. So it's for future terms moved appropriately so that the inbox can legitimately be imported emails. Right. Break that down for us. Yeah. So I'll compare it kind of to how Gmail works.. Everybody probably has a Gmail account.

The way Gmail works is all email comes into one place. Gmail uses artificial intelligence things to try to sort things into a few other buckets. There's a promotions tab where you get marketing email. There's a social tab where Facebook notifications go in there. It tries to do some stuff for you. Otherwise, you're left to your own devices. It's just like stuff pours in. In Hey, first of all, everyone is blocked at the gate. So before anybody can email you at all, you have to agree to let them. So there's a

thing in Hey called the screener. It's sort of like screening your calls. You open it up and it shows a list of all the people who have tried to email you. And you get to say yes or no, sort of in the way that you would like on Tinder or something. You'd be like, yeah, I like this or no, I don't like this. Along with that, you can also specify where you want emails from this contact to arrive if they email you later. So the default, if you say, yes, I want emails from this person, they just come into your inbox like normal. If you decide that like, actually, this is an email from some e-commerce site, and I don't really need to see it all that much, but I need like, I need to keep the receipts. You can file that in the paper trail, which is like a place for that kind of stuff. Or if it's a newsletter or some long form content that you're interested in

reading, but it's not that important, you can read it passively. You can file that person into the feed. And then anytime those emails come in, they'll be in the feed. And the feed and the paper trail are kind of buried back a little bit in the app. So you can get to them, you can check them whenever you want, but they don't notify you. The stuff in the feed and paper trail has no read or unread state. So you can read it if you want, ignore it if you don't care. And that kind of leaves you left with the people who you said yes to and email you into the inbox and that's kind of what you see automatically in the app. So the whole system is based around your designations. It's not the system trying to be smart for you.

It's about giving you places to decide where you want email to go and then taking care of all that filtering rules for you so it's just easy. Going back to the extremes Jared mentioned, And then taking care of all that filtering rules for you so it's just easy. Yeah. Going back to the, I guess, extremes Jared mentioned, which was maybe the low extreme, which is someone who gets just normal email. And maybe the Jasons and DHHs of the world where they just get like hundreds of legitimate emails each day. That can be both hard and easy. Like I'm not sure.

I'm surprised, actually. I'm really curious what David's opinions might be about this about this obviously he likes it since he's a he's behind it but having to screen that much email maybe you just don't you know and maybe just sits at the gates maybe i don't know i mean i can see how somebody who gets light email that's okay for but somebody who gets heavy email, it's a necessary burden, I suppose. Yeah, it does kind of push back the burden a little bit into another place. One thing that's sort of nice about it is that people are less, like contacts are less numerous than individual emails. So in traditional email, you might have one contact that like blasts you with emails all the time. So you don't have

to screen every individual email this and do you just screen that person once and you're done. So it is some work, especially at the beginning when you're first getting the system set up and you're getting a flood of all the email you normally get from all the people and you've never screened any of them before. There's like a two week period where it's kind of a lot of work because you're like, you get a lot of email, you have to say yes and no a lot. Once that's done though, it kind of settles down unless you're a Jason and David person where you're getting cold emails just constantly from all over the internet.

For the most part, the contacts you have are kind of contained and then it gets slower. And we, we, Jared and I may not be a Jason or David, but we get lots of cold emails from lots of different people that are generally legitimate-ish. I would use the ish on there because they think they're legitimate. We think they're not very legitimate. It's like we want to read them, but we don't want to respond to them.

It's a challenge. We're unique, I would say, though, because we run a media company and people want to reach out to us in similar fashion. We're like a baby Jason and DHH. We're not quite adolescent yet in comparison to their email volume, I'm sure. There's an interesting psychology when you're in that circumstance too where in the old model, when anybody on the internet can cold email you and it lands in your inbox,

you feel some degree of obligation to deal with that thing. You're like, Oh, this person emailed me. I better get back to them. Even if it's to say, I'm not interested or I don't want this, whatever it's there. And it's like an obligation. So people anywhere on earth can just like put stuff on your to-do list at any time they want without your choice. Right. And that's one of the things that we really wanted to push back on. Is it like, actually, how many of those cold emails are worth your time? It could be that maybe it's half. I don't know. Maybe it's less than half. But when you put it in the screener and the system gives you a way out, it really reduces that obligation. And especially if you're like an inbox zero person and you're a person who feels like I got to be on top of this thing. It's just an easy way

to be like, no, you know what? that advertising dude who wants to get on my show and wants to pick my brain at lunch for 15 minutes or something, I'm good. I don't need to talk to that guy. It gives you an out, which is kind of liberating in a way. How does it identify a person? Is it simply their email address or is it smarter than that? Yep, it's just by email address. In the future, we're going to look at doing some stuff at the domain level as well as by person. it simply their email address or is it smarter than that yep it's just by email address in the future we're going to look at doing some stuff at the domain level as well as by person because

there's some circumstances where you want to be like actually anybody at this company that i'm working with who's an accountant can just come in like it's like that's my accountant and there's 10 people at that domain and they can just all email me and it's fine right yeah so we'll probably add some stuff like that down the road but right now it's just one-to-one. Also, a common trick of spammers, nobody can enforce the actual email address from address. You can just say you're from anywhere. It's easy to impersonate people that you aren't.

Is this in addition to default spam prevention and those kind of things where that stuff's not making it into my screener queue? Yep, that's right. We have a spam filter up front, so known spammy stuff won't even make it to the screener. You just won't even see it. There is a spam box, so you can check that periodically

to see if there's something in there. On top of that, we do have some machinery to try to detect stuff like you're saying, spoofed email addresses. It's an inexact science because there's lots of ways to do that. And you have to also allow some stuff that you might not want to because email is just kind of fundamentally messy in a few ways. So some stuff will leak through and we're still tightening that up. We don't have it totally hammered out yet, but we try to avoid spam and spoofing to the extent we can which is why it takes courage to build this kind of thing i mean you got to handle a lot of

different problems spam is one of them that's just a gigantic amount and then you know the where and i guess the target that your servers become so security is a gigantic issue when you become an email service the trust that it takes to be that domain etc so like sending from you know foo at hey.com for example there's a lot of you know a lot of foos out there you know a lot of well a lot of stuff that maybe not a lot of foos but a lot of i don't know how that relates to or how you protect your domain the trustability of it at like a security level or sendability level but there's a lot of a lot of gotchas in that world that you know a google could take on not so much that a base camp isn't a google

capable but just like you're just so massive you could deal with that just massive problem yeah that's absolutely right whereas base camp isn't google base camps generally like 50 ish people i mean not that you're you're not 50,000. Right. Maybe you grow a little bit more to sustain hay, of course, but still, yeah, it's a big problem is what I'm trying to say. Yeah, that was kind of the case with almost everything building this product, that just making an email service,

just doing the foundational things that you need to do to make that even operate, are all hard. Beyond anything new we need to do to make that even operate are all hard. Like beyond anything new we wanted to bring to the table, just like pick any detail of an email service. And it's hard, like rendering emails and sharing them to people is really hard because emails are designed in a way that makes them unreliable and kind of crufty and they don't resize properly. And they're written in a bunch of different ways and they have different compatibility with clients. Things like keeping the service up.

Email's a whole new level of criticality for us, past even beyond what Basecamp is. If email goes down, people can't get to their doctor records and they can't log into things. It's tough. Highly critical service. And then all the system stuff like you're talking about building up reputability scores for the domain yeah we've even had simple

things like lots of websites won't let people enter at hey.com as like a username because they're like they think the domain is fake it's too short yeah i'll be like no that's not a real address we're like yeah no it is though so so. So we had to reach out to all these website owners and be like, could you please allow us? Lots of stuff like that. So on top of all that, you're competing with free, right? You're competing with free and existing and giants. So as lead designer of this,

was there epic levels of pressure to make this very good? Because when you compete with free, it has to be super compelling, right? And so Jonas, you're in charge. Make this thing super compelling. Did you have a lot of pressure on the way you went about designing this thing? I don't think we didn't frame it that way for ourselves at the beginning. That is sort of the reality that we are competing with free products and that's just a hard thing to do. Part of the thing that's good for us is that since we are so small, we don't need to even be a tiny percentage of Gmail to be pretty successful. So like our sites were never on being Gmail or being Yahoo or being,

you know, getting a billion users on this. Like we actually actively don't want that. Like that's not a problem we are interested in dealing with or solving. We don't want to grow our company to the scale it would take to get there. It's just not in our DNA. So what we did want was, you know, to build a product that we feel strongly about that we think solves the right problems and sets people up in a new direction. You know, if we could get a couple hundred thousand people using it instead of maybe a couple million or billion or whatever. That's great. For us, that's like super good, strong quality product that we're happy to run.

So when you frame it that way, it takes a little bit of the pressure off. It's not like, oh, we have to show up day one and be as good as Gmail. But I think we got pretty far considering our size and the amount of time we gave ourselves to do it. Like I use it and I don't look at Gmail anymore. And that's pretty, pretty good. When dealing with application performance, you ask questions like which endpoint is triggering memory increases, are slow requests to a particular endpoint cascading to the app? Why is this endpoint slow for only a handful of users? Has this performance pattern occurred before? What changed since the most recent deploy? Those are just a few questions

easily answered by Scout APM. Scout is application monitoring that continually tracks down M plus one database queries, sources of memory bloat, performance abnormalities, and a ton more. Thousands of engineers trust Scout APM to help them uncover performance issues you can't see in the charts. Learn more and get started for free at ScoutAPM.com slash changelog. No credit cards required. Again, ScoutAPM.com slash changelog. So you're designing against free. You're trying to come out with compelling features,

even though you don't have to steal all of Gmail's market share, all of Outlook's market share. You can just carve off a little niche and call that success. Still, you want to be compelling. You want to convince people, at least some fraction of the market, that what Hay offers is better, for them at least, than what these other services offer. So we talked about the importance box, the inbox,

the feed, which is for newsletters and other such things you might read casually, and then the paper trail, which is for everything else. It seems like emails that you don't want to read but you may need to look up later. Is that distinction of these three buckets and then the design around those, would you say that's Hayes core offering or are there other aspects of Hayes that we haven't touched on

that you also consider core? Part of the thing is that when we set out we wanted to design something that's going to be kind of premium because if you are a free email user, you use Gmail, and you're fine with it, and you don't care about email, and you don't pay much attention to it, you're probably not going to go out and spend $100 a year on a different email service. So the people we're marketing to are going to be people who aren't that. You have to be at least somewhat intrigued by the idea of email not working for you

in order to even care. So I think our collection, our little ecosystem of features of Hey that make it premium are a few things. One is just the Hey.com address. It's just a cool email address to have. We spent quite a good deal of money to acquire that domain.

How much? A lot. I can't say. I can't say. It was enough. It's a solid amount. Was it worth it? Yeah. It's almost a product in itself, in a way. If you have a good, like Jonas at hey.com, it's a good email address, right? So that's one part of it. Was that immediately obvious? Like we need an awesome domain and hey.com is an awesome domain

or were there a bunch of other domains that you're like, this one's pretty cool but it's 2x the price or how fast did that process go? It was real slow. So the code name for the app was originally called Haystack. Which is actually a code name

we've used in the past. This is the second time we've made a Haystack that didn't end up being called Haystack. I think we own haystack.com. We had that. So we were considering calling it that. And then somehow Jason got the idea to call it hay.com. And he went down this long path of trying to buy the domain from the guy who owned it, who had owned it since the early 90s. Nice job by him. Good old virtual real estate, you know? Right. He grabbed it. And he was using it. He had a business on there and it was like his thing, but he was kind of ready to do something else.

Oh, that's good. So they went back and forth and the deal didn't go through. There was a bunch of different back and forth moments where we had it and we didn't have it. Around that time, Jason also had put out a call on Twitter to say, hey, does anybody have good domains? Just to see if we could get something else. And he got a laundry list of totally lousy, not good domain. What people think of as a good domain isn't really very good. So for us, we really wanted Hay. Hay was the name. Like we mentioned earlier, Hay is in Basecamp and stuff. It took about six months, but we eventually got the domain and that was it. That was probably a big moment.

So the domain is premium. Right. Yeah, so the domain's premium and then the screener is a really huge feature for us. It's like, that's novel. And then the other big thing that Hay does is it basically gives you a system to deal with this mess. And that's really what we're selling. We're selling this system that takes away this pain that you have in your life. And it's a hundred bucks a year for that, which I think is a fair thing. A lot of people make the argument, well, I could use Gmail or Fastmail and turn on 15 extensions and basically hack my way to the feature set of Hey.

And like, maybe you can't, I don't know. I haven't tried. Maybe you can do that. But that's not what we're trying to do. We're trying to make a product that's pleasant to use, that's thoughtful, designed all the way through, that solves these problems in a way that's new and interesting, and also protects you. That's the other thing. If you use Gmail, you're being advertised against. You're sort of a number in their system. And okay, the product's sort of designed for you, but it's also sort of designed for Google to make money. And we don't really like that relationship. Our relationship is that we want to make a really good product for customers who pay us directly. And we will protect them over our own, you know,

business interests or whatever, which is why we ended up doing things like blocking spy tracking in emails. We can take those stances because we aren't beholden to advertisers. We aren't needing to play in all these pots to make money in different ways. We make money for our customers and we make the best product we can for them directly. So that's another big part of it.

I couldn't help but be on Wayback Machine because you mentioned Hey.com was owned by somebody else. So I was listening for a second there, but I was like on Wayback Machine trying to find old stuff. And I'm sad to say I could not find anything or it's just broken. I'm not sure, but it was fun to try. Bummer. I'll look again later on. But in between now and then, you mentioned tracking, which I totally hate.

Email is such a terrible place for tracking. Everything from the pixels to the links, it's just horrible. I say this as somebody who sends an email newsletter that currently, I believe, still tracks, which we do hate, by the way. So if you get our email, we are planning to make some changes there because we totally hate that stuff. And I think that's something that's changed. Well, we don't really use it. It's just on because our service provider offers it and we just click. We can't turn it off.

Yeah, it would be very mean to turn it off. Anyways. The point is, is that I think over time people have grown this allergy to being the product, right? To get something for free and to be the product because they get it for free. And their data, their privacy, they're the subjects of all these you know exploits you know the what do you call the design where it's like you know the bad design help me out here jonas you're a designer or you were you dark like dark patterns dark patterns there you go thank you dark patterns rescue me from my word follow-ups here you know you're trying to like

cheat the user by terrible design that that makes you think one thing and is another. And not so much that Gmail is doing that. I'm not saying that at all. But like email is this world where that lives. And then you got the email that comes in that's trying to track you. Then you got your email client that's tracking you. It's just a bunch of tracking all with a raspberry pi on my local network i just become more and more aware of all these you know weird urls that my apps my websites my

different things ping back to and it's just like it's a disgusting world and it seems i'm assuming it seems based on this and other things that basecamp and Hey.com is against that. And that's the reason one, why it costs money, because you probably hate it just as much as me and Jared do, or at least I do. Yeah. It's a toxic soup out there. It's horrible. I think if people, part of it is it's invisible too, is that people don't even know this is going on. Exactly. That's the worst part. Unless you're paying close attention, it doesn't tell you you're being tracked. You have no insight into that unless you really dig in. If you're like a developer person, you can kind of see it behind the scenes. So obviously dislike tracking in all that form.

I think if you think of Gmail came out about 16 years ago, I think it was like 2004. Email's been essentially unchanged meaningfully since 2004. And I remember when I got Gmail, that was during the time when I still talk to people over email a lot. In the intervening years, marketers and advertisers and salespeople and scammers and all these people took advantage of the fact that email served this open thing. They're like, everybody has email. It's a way to communicate with everybody, get on their desk immediately. And they totally abused it. They abused the heck out of it in all these ways. They added all this tracking. They did all these like drip campaigns, marketing things. It's like filled to the brim

with tricks so that the email you get now compared to the email you got when Gmail launched in 2004 is just drastically different. And most of it is this garbage stew of tracking stuff, trying to convince you to take action in some way to go benefit somebody else, you know. So, you know, at Basecamp, we obviously don't like this practice in general. But that's part of the idea of Hey, too, is that if we can't do this, like if we can't make a service that defends people's privacy and stands for people instead of sales tactics and advertisers and marketing and tricks and stuff, then who can? It's like, are we just going to fold to big tech and just be like, nope, that's just the world now. Like everybody's just going to be tracked to the hills and just deal

with it. Too bad. It's free at least. So hope you like that. You know, it's like, that's not the world we want to live in. That's not the kind of product we want to design. So we feel like now more than ever, it's important to try to build something that's a contrast to that. Yeah. In our world, we're using G Suite. And I think we're using G Suite

just simply because it's useful in terms of it's never down. Not that we trust it. I trust it to be up. I don't trust it to, for all the other reasons. It's a cumbersome, hard to use tool generally. And I don't see it really being for all the other reasons. It's a cumbersome, hard to use tool generally. And I don't see it really being for me. It's essentially a Gmail offshoot. It's not really, it's essentially Gmail that you pay for. And it's got a lot of, a lot of issues. And I

think the reason why I've personally never made any changes away from it is because there's no bit, there's never been a decent contender. Yeah. It's also just really difficult to move. Like it's like, if you have a company on a thing, you're on G suite or whatever, There's never been a decent contender. It's also just really difficult to move. If you have a company on a thing, you're on G Suite or whatever, moving your company off of that is kind of tough. And we're working through ways to make that not as hard so people can move. But it's a pain. You have to really be invested in the idea. Or hopefully starting from scratch it's easier. If you're a new company, you can pick which platform you want to be on.

But yeah, you get a lot of benefits from the economies of scale that Google provides and that's legit. So it's very hard to compete with them. It's tough. In terms of moving though, I'm still catching up on where you're at with this feature set, but when I heard of it recently was that it was not possible to migrate your existing email into Hey. Has that changed before I ask you the next

question? No, that hasn't changed. So we might still do something down the road to support that we mainly at the beginning didn't want to be bringing in, you know, huge volumes of existing mail. And we also kind of believe that this is an opportunity for a fresh start. And you don't get that many opportunities for fresh starts, especially with something like email. We're like, sure, you could bring in 20 years of archives of Gmail. But what we found when we used it internally and didn't do that was that like, we really don't dip into the archives that much. And there's a bunch of ways to keep those archives. You can either keep them in Gmail if you want, or you can download them and put them in a client. So we kind of just thought, you know, actually it seems okay.

Like for some people it's a showstopper. Like if you're a heavy email archive person and it's like your to-do list and that's how you live, it might be a little tough for you. For most people, it seems like it's not that big of a deal. Like if you need to go dig something up, you can still get it. Yeah. I'm more like, it's my brain. If I, if I've talked to you in the last 10 years or in my email and I can trace back at least my own memory to spark a memory of how I knew you, how we met, how we interacted because I've since purged that RAM and moved on with my life. So, yeah, it's a showstopper for some because they want to import all their email, but you do let people forward in. So you can begin new so if you have gmail you want to move to hey.com or whatever it is you know you can or if you do custom domains in the future or when you i suppose do you can forward in which means you can from today you can create an account feel good about all the great things of it forward

email in but you can't import all the past archive and some right have said well that's kind of a weird and as the designer that's why i'm asking this question is like from a ux standpoint you're thinking okay i want people to use my app. I want people to use my thing and find it useful, but I can't keep them in this old world where they have to sort of hurdle the two, essentially. Stand between these two lines is like, here's my new email. Here's my old email. I've got to use my old email.

I've got to keep it or keep logged into it so that I can just use it for search, which is primarily what I would do. So if I said, hey, I'm done with whatever. I'm using Hey completely now, and only new stuff is in there. I've now got to adopt it. It's a big hurdle to adopt it because I've got to now change everything to get into it. At least that's my assumption. And then as somebody who uses my email as my brain, I've now got to still keep my old thing as simply archive and search, which isn't terrible.

But as a designer, you want people to get rid of the old thing and adopt the new thing and be like, ah, the world's great, and move on, right? I mean, as a designer, you want that. So you have to strive this line of like, well, what you used to have is kind of still useful in some way. Yeah, so there's a thing about making a new product from scratch, especially of this size and scale and challenge is that you have to be pretty picky about what you make time for,

because you can't do everything you want to do. So ideally, yes, I agree with you. Like I would personally love to be able to search my archives in here and maybe import stuff and would love that. I hope we can someday do it in some fashion. But we felt that relative to the time investment and the technical complexity it would take to do that, we could better use our time doing novel, interesting, opinionated things that would differentiate the product more.

So sure, it's a bit of a problem that you can't do importing, but that doesn't prevent you from being able to access your old email in some way. But not doing the things that we think makes hay different and valuable would take away from why people would be interested in even trying it in the first place. So we focused most of our efforts in the initial design around doing the fundamentals to the extent that we had to do them. Like emails have to render. You have to be able to forward stuff in.

You have to be able to get stuff back out. You have to be able to buy the product. Those are all things that are just like basic concrete that needs to be poured that have nothing to do really with the ideas of the app. And then spend all the rest of the time on the ideas. And then later, you know, we have hopefully years ahead of us on this thing. We can certainly make time in a future cycle to do an import feature. If we want to, we can absolutely do that. It just didn't make the initial launch cut

because we didn't feel like it was valuable enough. I'm telling two people who build products that are programmers that care about those things, it's a little easier for us to swallow that pill. Everyday users may not get that. Like the sizable investment it must take to just buy the sheer databases or the sheer hard drives or space available to import that amount of – the big play for Gmail was unlimited space essentially. Like archive everything, never deleted email, keep it forever. Right. of the big play for Gmail was unlimited space, essentially. Like archive everything, never deleted email, keep it forever. And that's a massive amount of data to sort of adopt just to sort of prop up a new product to compete.

Yeah, it's a difficult problem even to just build technically because a large import like that can take days. It could be a very long process to bring in. If you have even just like a 50 gigabyte archive or something. For someone to upload that, for us to process it, get it on the system, it's not quick. To design around it, we have to have a lot of systems in place for that and then handle the delays and everything. It's software, so we can certainly do that.

It's a lot. It's not just a quick thing that we can just hack together. Right. You have to draw a line in the sand and ship the thing at a certain point. Right. But one thing you can't skip out on is the design aesthetic. So you said you're going for a compelling premium product. And the design of Hay, the look and feel, is, I would describe it as kind of bright and bold.

You know, you got blues on whites, you got big, everything's big, big rounded buttons, not many drop shadows. There's like a hand-drawn aspect to it, like the Hey logo is like a hand that's drawn. And so if I was to describe the way it feels, I would say it was like kind of casual, bright, maybe informal, but bold.

Surely you had a part in these decisions as well. What were you going for with the design? Because you're saying you're going for premium. And I'm wondering if all that adds up to premium or what people feel when they first see the product. Yeah, well, premium is a big term.

I know. What I meant by premium was more that the people who would be interested in paying for this are probably premium emailers. Sure, power users. Yeah, in that kind of higher range of use. You're right.

You're spot on about how you're describing the aesthetic. That's exactly how it is. That's kind of what we're going for we really wanted it to be a sort of calming place, like one thing about email is that it tends to be very dense like if you go to Gmail today and you open it up, it's basically a spreadsheet like it's like the rows are tight, there's probably like 60 emails you can see at once there's like two columns of information. There's all these different things in a list, two types of navigation, tons of emails in a list. You click one of those, everything's dense.

We kind of wanted to open it up a little bit because that has a just stressful pressure feeling about it. It yet it's sort of power usury in a sense that like you can, If you're a power person, you can go in there and be like, I really have control over this thing because look, it has every widget. Right. You like your spreadsheets, right? Yeah, I like our spreadsheet. And that's certainly great. We don't have anything against spreadsheets. But we just wanted to take a different approach, which is all around giving you control back

and giving you a sense of peace about this thing. And that plays out in the design in a bunch of different ways. Some of it's aesthetic, where it's not as dense. It's there's a little bit more space, a little more room to breathe. There's not as much navigation and stuff's shoved all around. Another aspect of it is there's no archiving the system sort of just auto. It doesn't really archive. It's just, if you see something, you've seen it and it sort of drifts off like it would, if you were using Twitter, you know, it's like you read a tweet, you've seen it, and it sort of drifts off like it would if you were using Twitter. It's like you read a tweet. You don't know where that tweet went in a month.

It's just somewhere. If you need to get back to it, you probably can. That makes sense. But you didn't have to click on every tweet and be like, archive. It's like, why do I have all this obligation around managing this spreadsheet of stuff? So we tried to really pare back on some of those fundamentals of email and say, really question the assumptions. Do we need it to be the way email traditionally has worked?

And we decided, no, we don't in a lot of cases. I love the way that a lot of the design decisions have been pushed back on inherent obligation of the license to email anybody in the world, right? If my phone rings right now, I've got an obligation to answer it. Verizon hasn't given me the option to screen. They haven't given me the option to do the things that you're doing with email. And I like that that's part of the – it seems like the DNA. Is that the DNA from which you sort of like make the decisions? Like how can we question the obligations of email of past to do email of future? Yeah, I think part of that is, like I was saying before, how email has changed over the years.

That, you know, it used to be, it started as a person-to-person communications thing. And that part of it is still beautiful. That like anybody on the earth can email you and you can write them back. And like, it's great. It's amazing. There's no, no real owner of that. And it's an open platform and it's like the web in that sense. It's a beautiful thing, but it got kind of perverted over the years too, and abused in all these ways, like we talked about. So the modern email circumstance is that it's a huge amount of effort to keep up on. So people either feel guilty about it because they can't keep up. And so they have a red badge in their iPhone that says like 13,000 unread emails, or they keep up on it in a way that's stressful.

They try to do inbox zero and they're constantly checking their email and responding immediately. And like, it's a thing, right? And we wanted to come at it from another angle and be like, why is it like this? Why can everybody put this pressure on you? And why do you feel like you obligated to have to act on it? You shouldn't have to feel that way. And so we designed, hey, to sort of provide you with power as the recipient. Because email, as it was originally designed, the power is all with the senders. Senders can just blast and you as the recipient get the blast. That's it. Good luck. It's on you. So we tried to tilt that power structure a bit. It's not like totally tilted, but it's tilted

enough that you can defend yourself a little bit against this like onslaught of stuff, which takes away all that obligation feeling and makes it a more peaceful experience. Is there a natural strategy? Can you back this up? And Jared said earlier, which was, you know, there's people who have certain strategies to email. You mentioned, you know, inbox zero or keep it all and it's a badge of honor. But like, is there, it seems like you're just designed for success regardless. There is no true strategy.

It's just email as normal. And once you've read it or seen it, it sort of goes into the past. You can file it, you can screen, and just using it is the strategy, essentially. Yeah, basically by just using it, a lot of the effort you'd have to put in in a different email client just isn't there. And this manifests in a bunch of different ways.

So one way is that Hey doesn't notify you about email by default at all. So when you first sign up for Hey and you start getting emails in there, you won't get push notifications unless you choose to turn them on either individually for people or individually for a thread, or you can do it just for the inbox. Those are like our three ways of getting notifications. Another thing it doesn't do is counts. So we don't pretty much anywhere other than the screener say how many emails you have in any place because it's just stressful and it doesn't matter. It's not helpful. Like if you say you have 50 unread emails in this thing, like so what? Are you going to read all 50 or are you going to mark them't have read or unread states at all.

So that's another obligation. Like if you, in a normal email client, when things are unread, they're bold and they stand out and you feel like you're obligated to click on every single one of them just to like mark them red. You may not need to. Maybe you get an email from Amazon. It's like a shipping notification. You're like, yeah, good.

I see. I got it. It's fine. You don't need to click into that. You don't need to do anything. You're done. Like you saw it. I see I got it it's fine you don't need to click into that you don't need to do anything you're done like you saw it so we tried to do a lot of the stuff in hay around that where it's like seeing the thing is enough filing it somewhere is enough just looking at your email is enough

you don't need anything else the system doesn't, inbox is the sort of home, the previously seen and the inability to control this inbox zero mindset is lacking because you can do the screening, you can do the filing and you can have seen and things will go away, but the previously seen and a couple other things might trickle down below. Have you gotten pushed back on people who are like, I want a clean screen, I want to know I'm done, there's nothing bothering me, as you said before, obligations. You're sort of designed in some obligations there visually. Yeah, that's probably the biggest behavioral change that people struggle with when they first sign up, is that, especially if you're an Inbox Zero person,

you're used to the blank slate being the thing, right? It's like you get like an endorphin rush from when you don't see any emails. And that's like your way of thinking about email. And hey, instead of an archive, we do this thing where when you get an email in the inbox, it's unread. If you click on it, you've seen it. And then it goes down into this previously seen section, which is on the same screen, but it's kind of down below a little bit. And that's it. There's no archiving. There's no other action you have to take. You click it, you see it, it goes to this bottom section. Some people find that a little bit uncomfortable at the beginning because they've seen something, but they can, it's still sort of there. It's like within their field of vision, even though it's like just a little bit down at the bottom, they can kind of see it.

And they're like, ah, I'm upset. I don't want to see this at all. I want to inbox zero. So we are sort of encouraging like that idea actually in itself is sort of not good. But like the fact that you feel stress about just seeing that an email exists probably isn't great. It's like you've sort of trained yourself some habits that maybe aren't super healthy for you as a person in general. But with that said, we do appreciate that like some people just really don't want to see old stuff. So we're pretty likely we might add some options around toggling that off or hiding it if you don't want to see it. We'll probably end up doing that at some point, just for those people who feel really uncomfortable about it. The thing is that I've felt that same way at the beginning and you use it for two weeks and you're like, okay,

I get this. And you kind of stop, let your guard down a little bit and it doesn't feel so weird anymore. How much time does your team spend building and maintaining internal tooling? I'm talking about those behind the scenes apps, the ones no one else sees. The S3 uploader you built last year for the marketing team. That quick Firebase admin panel that lets you monitor key KPIs. Maybe even the tool your data science team hacked together so they could provide custom ad spend analytics. Now, these are tools you need, so you build them.

And that makes sense. But the question is, could you have built them in less time, with less effort, and less overhead and maintenance required? And the answer to that question is, yes, that's where Retool comes in. Rohan Chopra, Engineering Director at DoorDash, has this to say about Retool. Quote, The tools we've been able to quickly build with Retool have allowed us to empower and scale our local operators, all while reducing the dependency on engineering, end quote. Now, the internal tooling process at DoorDash was bogged down with manual data entry, missed handoffs, and long turnaround times. And after integrating Retool, DoorDash was able to cut the engineering time required

to build tools by a factor of 10x and eliminate the error-prone manual processes that plagued their workflows. They were able to empower backend engineers who wouldn't otherwise be able to build frontends from scratch. And these engineers were able to build fully functional apps and Retool in hours, not days or weeks. Your next step is to try it free at retool.com slash changelog. Again, retool.com slash changelog. so Jonas as you were speaking to the previously seen list and its lack of ability of being completely gone, I was over here thinking, I'm kind of an inbox zero person and I'm wondering how I would react.

So I've been poking around the product here a little bit. I definitely was looking for the archive button because that's just the way I use email is I archive it once it's done and I use it a little bit as a queue of things to do so it's kind of a to-do list it's kind of a to-contact list and I do like to clear things out even though I don't need the counts it doesn't need to be empty I'm not like super neurotic about it but I am a completionist and so I'm a bit of inbox zero person and I found maybe I was starting to think, how could I use this?

Because maybe I just wouldn't. Maybe I'd just go back to a traditional way. But how would you capture a kind of user like me who either needs to change their processes a little bit, or maybe Hay needs to loosen his opinion slightly, like you were talking about, maybe provide options for us to get those endorphins hits or whatever it is.

And I did find that you do have this set aside. I mean, it actually uses a pin as the icon, right? Like a, what is that called? Blanking a bookmark pin? A push pin, yeah. And what that does is when you click set aside on an email or the A keyboard shortcuts, by the way, nice job. All keyboard shortcuts are awesome in here

for the premium users, for the power users. When you do that, it goes back into your inbox or maybe wherever it was. It's in your inbox, but it's in the previously seen, but it's like pinned to the bottom in this little accordion. Like here's the ones that they're kind of like, I've read this. I don't want to

disappear because i am going to address it later i'm going to read it again later that plus you have the send email later kind of a thing uh email like reply later yep so these are a couple of things where i could see myself using that in order to accomplish what i normally do which is i'll leave it in my inbox my inbox right now has nine items in it, and two are unread. And the other seven are things that either I'm going to read them again, and then archive them, or I'm going to reply, or I'm going to go do something and then archive it. So I am kind of a manage a queue using my email person. And I've lived that way for many years, and I just like it. It works for me. I'm not stressed

out. And so I'm wondering if your combination of these things are helping people like me continue to do email in a way that's at least similar to the way we have been, but still take advantage of the stuff like the newsfeed, I think is a great feature. I don't like reading newsletters in my inbox because I'd rather relax and my inbox is more of like a work queue. So I like getting that out, but I also like keeping these things in. Can you speak to the set aside board and the reply later stuff? Yeah, absolutely. So the overall system of Hey is kind of a series of different places to put things to make your life a little easier and a little less pressured. So the first part of that is just by reducing the volume of email you get in the first place

by screening it out. So that helps. The second part of it is being able to file certain contacts into certain places like the feed or the paper trail so that you don't have newsletters and shipping confirmations intermingled with actually important emails from people that you need to get back to. So by just setting up those initial features by screening people in and out and designating where they go when they email you, you've already done a good job cutting down email into a much more manageable slice. So if you are an inbox zero person, it's less work to get to zero, right? Instead of having 50 things, it's maybe 10 in a day. So that helps. But then even once you've done that, just when you take a look at your email that you would have classified as important, some of it is important in the sense that you needed to see it. It's not necessarily important in the sense that you need to reply to it immediately,

or that right this moment is the right time for that email. So what we did was we looked at different workflows that happen for different types of email, and we designed features around those things. So the set aside feature is sort of like in a normal email client, you might have like a pin or a star, like Gmail, I think it's a star. And it's like a flag to say like, this is something I need to get back to, this is important, whatever. But the thing in normal email clients is when you do that, the email just stays where it was, or maybe sometimes it floats to the top of the list or something, but it doesn't go away. And so what we found was that when you have a feature like that,

let's say you have some bill you need to pay, but you're not ready to pay it yet. It's due in a week and you have to get paid before you can pay it. The traditional thing is you would just star it and then get back to it or you'd mark it on red and it sits in your way the whole time. There's no other place to put it. Maybe you put in a folder or something. So set aside is the place to put stuff like that, where it's like, I know I want this. I don't want it to go away. I want it to be available and in my vision still, but not like in the way of these other things that I'm triaging in the moment. So if you have that bill and you need to pay it, but it's not ready yet, you put it in set aside, you wait a week, you come back to it and pay it,

and then you take it out of there. That's kind of the idea of set aside. And it's still in the inbox in the sense that it's still in your face. It's not gone. It's just not like in between the other things that you're still going through. So that was sort of the motivation of that feature. And then the other thing that happens is you'll get email from five people you need to get back to, but you're busy at work during the day and you're in the middle of something else. You can't get back to them. But then you've seen the email and you know you need to reply, but you can't do it now. So you're sort of stuck. There's like a couple of ways in a traditional email client to deal with that. One way is to mark it as unread, even though you did read it, you have to leave it

unread to remember like, oh, I need to deal with it again. Or you might snooze it. Some email apps have like a snooze option where you can like send it away for a while and it'll come back to you again. We built reply later as a direct workflow to handle exactly that problem. So if you get five emails in a day and you want to write those people back, you can mark them all as reply later. It goes into a little bucket. And then when you do have time, maybe it's in the morning or the evening, whenever you're free, you can click on that and it will take you to a dedicated screen where you can, it lists only those emails from those people splayed out in open. So you can see the whole content. You don't have to click on them

individually and you can hammer out replies to each one in a row in a focused place and you're done. That's it. So it's a way to queue up emails and then reply to them kind of in a batch. And then that's it. You're free. You're done. So we just did a lot of thinking around these real human scenarios and work through those and decided like, how can we solve this in a way that makes it less friction to do these things? Did you do a lot of the, I guess, discovery of this around real people or did you look at other services that were trying to also solve for this and maybe have some good ideas but not doing them so well and a couple that come to mind is like i use same box for like same black hole stain later a couple

of things that are sort of feature sets of hay and then obviously when we talked to ryan he talked a lot about uh longitudinally looking at data sets and specifically talking about an individual user, their path through a workflow, whatever it might be. So when you define and start to design, do you look at individual humans or do you sort of scrutinize other services? What was the pattern you all used or did you just use both?

I actually used neither. Neither, okay. No real humans involved. Okay, good. Door number three. Well, some humans. Sure. So the data set approach is super great when you have an established product and an established company that's been running for a while and you can analyze it.

In this case, we didn't have that at all. We had nothing to go on. So there's nothing we could analyze, really. Well, David and Jason and those heavy users, so they were your but no real product data set. Yeah, right, exactly. It's like we couldn't get in there and dig through usage patterns or sort anything out like that because we just don't really have access to that. We had colloquial research from them having

been doing email for 20 years as company owners and struggling with it so i would say that's basically the root of where we started is designing something for ourselves like what's the tool that we would want to make our lives less painful in this regard definitely we always start there with any product for the most part and then from there it evolves out in a bunch of directions so like in this case we had some very root ideas early on. Like the screener was like a very early idea because Jason and David knew right away, like we don't want to get a lot of this email we get and it stinks.

So like, let's fix that. So that was like an early thing, but something like the paper trail didn't come in until way late. That showed up after we had built a bunch of these other features and I was struggling with having a bunch of stuff other features and I was struggling with having a bunch of stuff in my screener and I couldn't decide where to put it we only had the inbox and the feed which at the time was called the slow box which I kind of like

we had those two and so what we were doing I would end up sort of in this purgatory where I'd be like well I don't really want this in the feed because the feed is nice and like, it's good for reading, but like, I don't want receipts and junk in that. And then I don't want them in my inbox either. So I would end up with a queue of like 60 contacts in the screener. And I was like, something feels wrong. So I pitched this, I originally called it the bacon box. It's like a box for like kind of spammy email. That's not really spam. It's like bacon. It's like you, You still want it, but you don't really want it. You just kind of have to deal with it. Kind of transactional stuff.

I used to work on spam systems and there'd be spam and ham is how they would classify. So bacon box makes sense. Ham is like stuff that we thought was spam but it's actually good. Bacon's kind of better than spam but just a little bit better.

So I pitched that after having used the app personally for my own personal email for a month or two and finding that it was missing something. So a lot of the features end up coming out of that kind of thing where we solve some stuff, we have some ideas, build part of it, and then use it. And then we're still hitting these friction points, like how do we address that? And then we dig into that problem and figure, and then use it. And then we're like, we're still hitting these friction points. Like, how do we address that?

And then we dig into that problem and figure out a solution for it. Well, one of the things you've got to keep in mind is that, especially those listening and those checking this out for the first time, is like, you've got to start somewhere, right? You have to have some deeply investigated feelings about these things to change anything, right? So you've got to start somewhere. So even if, for example, inbox, if that does change to give more flexibility or control or toggle

ability to users like me or Jared that kind of, you know, if I could get to inbox zero, I would totally do it. As Jared said, he's not neurotic about it. I'm not neurotic about it. I wouldn't be like I have to be, but if I could, I might. So if your system enabled me to succeed better, it kind of upset me that my inbox couldn't be clean and sort of dealt with. So you've got to start somewhere is the point, though. So obviously, hey, it's new. You've got to begin somewhere. And I think the cool thing is that you care about solving real problems. So if your users come to you with real problems like, hey, this kind of bothers me, at some point you may give them tooling to say, OK, here's some controls.

Here's some levers, whatever, so you can feel good about this. We don't really agree with that framing, but we needed to have some deeply held opinions initially to get to a place where we all felt good about it because it was scratching our itch. And maybe we attract a lot of people who have similar itches and eventually we go down the itch metaphor too far and it gets crazy, but there you go. No, that's exactly right. At the beginning, when we were launching this, it's very important that the story you have to tell about it is really high contrast. That like, why are you going to convince somebody to is really high contrast that like you know why why are you going to convince somebody to go spend a hundred dollars on email when they could use gmail and not spend a hundred dollars you have to have a pretty compelling story and you don't do that by

towing the line and being like well it pretty much works like email except we have like two features and whatever it needs to be a line in the sand it's like no this is a new thing it's a new take it's different and we have a bunch of. And that's what you're signing up for. Now, that's the day one, though. So by day 1,000, we'll have heard from tens of thousands of customers who have used the thing and have sent us a bunch of feedback. And we may well shave down some of those opinions a little bit, or like you're saying, provide flexibility around them. We just did that for the inbox. And when we launched, there was no way to get notified,

get push notifications about everything that comes into the inbox. We just didn't ever build that. Then we heard from customers that are like, well, we're already filtering things out. And the inbox is pretty good. It's mostly what I do want to hear about. So I'd like to be notified about anything that comes in there. And we're like, yeah, that's a reasonable stance. It's not personally what we want, probably because we didn't build it in the two years we're like, yeah, that's a reasonable stance. It's not personally what we want, probably, because we didn't build it in the two years we made the thing. But it's fine. We're not so heavily opinionated about notifications

that you couldn't have that as an option. So we added that. And there's going to be tons of things like that. We may add an option to hide previously seen for people who don't like that. We'll fill in a lot of these missing pieces. But we wanted the initial launch version to be super core and tight and full of opinions

so that we could really punch down on that contrast. So as Adam said, we're on Gmail. My personal email has been on Gmail since the early beta days back when it was invite-only and it was so cool to get free storage because you had to pay for every email back then. But I never used Gmail's interface because I don't like it.

And I don't have to because they have IMAP. And so I use MailApp on iOS and I use, what's it called over here? I don't like the MailApp on macOS. I use Spark, which has its own interface and they build on top of Gmail things like Snooze and some of the features that you're talking about. And that makes me think about, hey,

because y'all are doing something kind of, I don't know if it's radically different, but you're doing something quite a bit different than a traditional email like Gmail is. And that makes me wonder if you then support traditional style, like can you connect into, hey, with IMAP and use it from a Spark app? Or do you have to be all in on Hay's web app

and Hay's mobile apps to use the service? It is a little bit different in that you can't use a different client with Hay as the backing service. You couldn't hook up Spark to Hay or hook up iOS Mail app to Hay and get email through it. There's not a technical reason we couldn't support that. It's more design and usability reason, which is that in order to do all of these different things

that we wanted to be able to do, we had to build a system that works differently than how email works. So if we provided an IMAP interface, people could use it as a service, but it wouldn't have any of these changes that we've made. Just the killer domain name. Yeah, I guess, right.

Maybe in the future we'll end up deciding, no, that's actually fine, we don't care if people just want to use it as a client. You could still use the screener feature once you're all set up and running. You wouldn't be able to screen, but you'd have the advantage of that your inbox would be the inbox, basically. It wouldn't be a one-to-one mapping, an iMapping, so to speak. That was bad.

But I'm just curious if it's like a foundational technical reason, or if it's just like, well, we want our experience to be there, so we built these apps instead of using iMap. That's pretty much it, is that we want to provide the experience that's novel. And giving somebody an iMap client isn't really that. But we could do it. We actually did build an IMAP integration for exporting, which we ended up not shipping because it was sort of challenging in a bunch of ways that weren't really even technical.

There's like all these politics around how you can get email into other providers. Like Google has like an approval process that takes a year to get through. It's like, it's a, you can't just export like a dot IMAP, big old 50 gigabyte file. And then, well, that's what year to get through. You can't just export a.imap big old 50 gigabyte file. Well, that's what we ended up doing. Our exports currently are Mbox format, which is basically just a box, and you can bring it into

a mail app or whatever. So we have the smarts and the wherewithal to be able to do IMAP, and we may well do it in some fashion down the road. But it was another one of those things where it was a huge engineering effort for an experience that didn't really match up with what we wanted to do. So that was an easy cut. We just cut that to begin with.

It's an easy cut, but on the other side, it requires you to build native mobile apps for both major platforms, right? So that's the trade-off is, well, we're not going to do IMAP, but we are going to build native apps for every platform that matters. Right. Yep, that was definitely part of it. But truthfully, we would have had to do that either way. I think there's very little likelihood we would have launched an email service

that was just like, nope, bring your own mail client. That just isn't the story we would want to tell. So we were probably going down that road regardless, and at that point you're good. Did you consider web only in terms of a PWA or just a web app that you could just install on your home screen and send through there? You couldn't get your post notifications, but like you said, you didn't want that anyways to begin with. Yeah, we could do that. The experience for that on the consumer side is harsh,

is the problem. People aren't really familiar with it, and it's not easily discoverable. People expect, if I'm going to pay $100 for an email app, I should be able to go to the app store and get the app. I shouldn't have to go to some website. And part of that is, that's not our problem so much as it is an app distribution problem. We'd love to be able to just put our software on the phone in a way that didn't require us to go through all these hoops and Apple and Google jumping and all this stuff. But that's just the economy we have to work in right now. It was pretty much table stakes. I don't think we could show up

on day one and not have apps. It wouldn't have gone over well. So what were some of the challenges there, aside from the obvious big controversial one, which was Apple and the App Store and the Hey app not being able to be updated, and that was covered very well in many places. Aside from that, design challenges, software challenges, you had a lot of stuff to design, right? Were you just trying to matriculate your web app into those mobile phones, or what, in terms of the design? We kind of have a design process for how we do this.

Generally, the ideas for the product start on the web. And I and some other people at the company in the core product team kind of do the initial versions, the web-based versions. And then because of our hybrid architecture for how we build our native apps, they can kind of consume the web views relatively easily without needing to do a lot of upfront work. And then we have mobile teams that can decide what stuff is worthy of turning into a native high fidelity interaction and what stuff could stay as a web view. There's lots of things in apps that don't really need to be native, like a setting screen that you don't go to very often. It's fine if that's not the highest fidelity screen because you go there once every six months and it's a list of things. It doesn't need to be that good.

But the inbox in an email app does need to be high fidelity because you want to be able to swipe rows and check things and have it feel fluid and scrollable and sync when you're offline and like all these things you would expect. So that's a case where it's worth a lot of native investment upfront. So we do a good bit of basically spiking things out, initializing things on the web, and then the native teams will build on top of that foundation. In this case, we also built a ton of new tech and stuff to make our lives easier to share components and navigation bits and little details across the platforms. We also had some tension around making the apps

all look the same and work the same. Because as we were building this thing, all the teams kind of were off in their own directions for a long time. Because we don't, you know, when you're making a new thing, you don't know what the thing is until you make it. And everybody has a different interpretation of what that might be. And everybody's kind of riffing on things and winging it. And, uh, at a certain point, relatively close to the launch, we realized like, Hey, you know, the apps don't match. It was like, they all, they had like different navigation and different things were surfaced.

And we were like, we probably should sync this up and get it tight. So we had to do some work to get everything kind of matching across the platforms. So I would say that was actually probably one of our biggest points of tension was just realizing we hit some point where we're like, we need to sync up before launch. Can you speak at all to the, I suppose, the initial inertia of people coming in?

Like obviously Basecamp's got a pretty wide megaphone in terms of influence. You've written books. You've defined methodologies. You create great web apps, and you're great leaders in many ways, individually and as an organization. So I could imagine that the, you know,

there's a lot of people trying out, hey, can you kind of talk through, I suppose, whatever you can numbers-wise in terms of who tried it out, maybe future anticipation. Obviously, maybe not a Gmail killer, but maybe a Gmail slicer where you slice a little off and take some. I feel like we actually were a little bit overly pessimistic about how this was going to go, which is probably a defense mechanism.

We kept giving ourselves excuses. We were like, well, if Hay didn't do well, at least we would have learned some stuff. You know, we were like basically trying to make it that like, there was no pressure on it being really successful at the outset. And, uh, our original launch plan was to, we had it in an invite only mode at the beginning. Cause we were trying to lessen the support burden. Initially we've, We've done enough launches in our 20-year history to know that opening the door on day one, being like, hey, the product's open, come on in, that it's totally overwhelming for our support team. It's too much and we can't do it. So we wanted to do more of a staggered launch and let people in gradually. Then all that stuff with Apple happened, and it greatly magnified the visibility of the app and drew a bunch more interest.

So I think at the peak, I'm pretty sure the wait list had like almost 200,000 people on it or something. It was really a lot for our scale, for what we were thinking would happen. And so we ended up just accelerating the launch by like a month. We were originally going to take about 30 days to go through the wait list, which at the time was not that big. And then we ended up compressing that into a week for a wait list that was like three times the size we expected to get. So that was a really chaotic time.

But the initial conversion rates and stuff were strong and it feels like a pretty good launch. It got probably the most buzz we could have expected it to get. So I think it's looking good. It's looking viable as like a pretty good launch. It got probably the most buzz we could have expected it to get. So I think it's looking good. It's looking viable as a long-term thing. Yeah. And if I understand the story correctly,

I didn't dig deep into it, but if I understand correctly, the situation with Apple, one, it was the second time David had to run in with Apple with their credit card issue and then now as an app maker issue. But did that sort of remove the requirement for the waitlist? Wasn't it something where with free and using the App Store and distribution,

it couldn't have this wait behind it? Something like that. Was the waitlist removed as part of that issue? I can't recall. No, they were kind of separate. The invite code thing was just like you had to enter a code in order to get through the signup. issue? I can't recall. No, they were kind of separate. The invite code thing was just like you had to enter a code in order to get through the sign-up. So you couldn't sign up for the app unless you had a code.

Right. I don't think that was really part of the Apple blocker. The Apple thing was more about how we sell the app and their argument was like it didn't work unless you already had an account and they didn't like that. There was some weird arguments going back and forth about that. But no, I don't think the code thing was a blocker.

I remember watching that happening play out and as every new, slightly bigger online publication began to report it, I thought, these guys couldn't buy this good of publicity. This is like the perfect storm for Hay because it's going to get worked out somehow on the other side. But that had almost, I would say, definitely mainstream tech news.

It might have had mainstream national news as well. It was a pretty big story. Yeah, it was right up David's alley. He's kind of been harping on a lot of these issues prior to this. So it was bizarre timing for them to make those changes and kind of go after us on it because they know who they're dealing with, I would assume. Yeah, it was definitely chaotic.

They do now. It was definitely a no press is bad press. It got so much attention. So much press. However, it was an existential concern for us. We were in a very tenuous position. If there was no way out, then you guys were, you have to be on iOS, like you said.

You have to be there, right? And they easily could have just dropped the app. It was nice of them not to, because we were fighting openly in the press. They could have been like, no, you're out, and then that would have been catastrophic for us. So we kind of lucked out. For those listeners who weren't around in June,

or have no idea what we're talking about, aside from what you said, is there like a best place rundown of that story? Like has David written it up or is there like a, because there was a lot, it unfolded over time. Yeah. I'm wondering if there's like a place where people can go and read about it

if they're interested. There's some, a bunch of stuff on our blog, signalvnoise.com. And then also The Verge did really good coverage. They have like three or four summary articles of all the drama there's one that's like hilarious it's like yes this drama is still happening and it's like 40 bullet points of things interesting well jonas thank you so much for sharing your time today man it's been great going through all the details of mapping out designing and building this thing and and uh a user, hopefully a long-term user,

certainly believe in a lot of the things that you all have set into motion. I do agree that it's time for a disruption to email and change some things because I'd like to have less obligation when I look at my inbox. And I want systems that work for me, not against me. And current systems work against me.

So I look forward to being a Hey user in the future, man. Awesome. Thanks so much for your time. It's been awesome. Thanks a lot. Yeah, thanks for having me on. All right, that's it for this episode of the Change Log. Thank you so much for tuning in. What are your thoughts on Hey? Do you have any opinions?

Hit us up in the comments at changelog.com slash 407 or open up your show notes and click Discuss onelog news. We'd love to hear from you. And I mentioned this last week that we're beta testing a membership program that lets you get closer to the metal. We call it changelog plus plus and we're in the process of soft launching it as we speak. Support our work, help us test this program and make the ads disappear at changelog.com. It's the best way to directly support this show and our other podcasts on changelog.com. And if you've never been to changelog.com, you should go there now. Again, join changelog++ to directly support our work and make the ads disappear at changelog.com. Of course, huge thanks to our partners who get it, Linode, Fastly, and Rollbar. Also, thanks to Brake Master Cylinder

for making all of our awesome beats. Thanks again for tuning in this week. We'll see you next week. Bye.