Hey is an email service developed by Basecamp and launched in June 2020. Within 10 days of launching into public beta, they reportedly made their first $1M in revenue by selling over 10,000 subscriptions at $99/yr.
Hey has an opinionated view on what are the most common workflows that people use email for, and builds those workflows as first-class product features.
They do a good job showcasing these features on their How It Works page:
- The Screener: When anyone emails you for the first time, you have to opt-in to seeing their emails
- The Feed: You designate which email addresses send you content that’s more like an article in a newsfeed than a 2-way email communication, and then you get a separate UI tab for those emails that’s more like an RSS feed reader
- The Paper Trail: You designate which email addresses send you receipts, and then there’s a tab for those
- The Imbox: A portmanteau of “important” and “inbox” (itself a closed compound of “in” and “box”). Everything that isn’t screened out by the Screener or routed to the Feed or Paper Trail is considered important.
- Reply Later: A separate queue for emails you plan to return to later
- Focus & Reply Mode: A streamlined UX for your “reply later” workflow
- Files View: A grid view of all the attachments you’ve received
- Editable Thread Subject Line: Helps you organize your Imbox
- Thread Merging: You can manually merge two message threads into one
- Customizable notification rules
- Blocks Trackers: Hey gives you privacy by not loading the pixels that tell senders’ servers that you viewed an email
What’s the Value Prop Story?
Does this large set of features add up to a compelling Value Prop Story?
Hey’s value prop is that it lets you process your emails faster and with less mental effort than Gmail (or whatever other email service). The answer to “when in your life you’d actually use it”, normally a big part of the challenge of telling a value prop story, is obvious in this case: You use it whenever you’re using Gmail now.
But when you’re trying to displace a mature product like Gmail, the problem is that you have to pour a lot of effort into your MVP before you can launch it, which leads to launching with a bunch of features, as listed above.
Why it *doesn’t* have too many features
A common failure mode for MVPs is trying to combine a bunch of features into an unfocused product, in hopes of making the whole more than the sum of its parts.
Item #4 in my Bloated MVP Test explains why it’s normally a red flag to bundle multiple use cases into one MVP: It’s because you don’t know if anyone gives a crap about any feature, so you should just focus on the smallest subset of features necessary to get your first signal of market validation.
But in Hey’s case, they get a pass for a couple reasons.
First, they get a pass because an email service must consist of multiple sub-workflows. Hey must be able to do all the most common tasks that most people do with email, or else the good parts could easily be outweighed by the bad parts.
Consider speed as a value prop. Hey feels faster than Gmail. But in order to achieve this, they have to build multiple speed optimizations: make the page’s initial load go faster, make clicking on an email thread go faster, make marking an email as unread go, make pulling up your Feed faster, etc. If any part doesn’t go faster, it undermines the appeal of Hey being faster than Gmail.
Second, they get a pass because the public beta we’re seeing isn’t the real MVP. The definition of an MVP is something that gives someone value. According to Basecamp cofounder DHH, a more bare-bones version of Hey was giving value to him well before their public beta. That was the real MVP.
In the earliest days, when Hey was still a half-baked kernel and they were playing with the idea of splitting an email inbox into the Imbox, Feed, and Paper Trail, they probably just prototyped the idea by setting up Gmail labels and filters for those three buckets, and testing if that made their personal email incrementally better.
They also conducted a bit of market testing for their other feature ideas. In 2019, early in Hey’s development, DHH was tweeting about how email tracking pixels are an unacceptable violation of privacy, and he got a strong polarized reaction which surely egged him on, I mean provided validation for the idea.
So, in a pretty short amount of time (less than a year) they had lean MVPs good enough to dogfood internally, while collecting evidence of market validation. Not too shabby.
Is it bloated?
While Hey does have a few surface signs of bloatedness:
- It’s a Whole Product complete with all the features listed above. This breaks rule #3 on the Bloated MVP test.
- The team spent about 18 months on it, and probably had something like 8 full-time staff working on it, which is about 12 person-years or $4M. This breaks rule #5 on the Bloated MVP test.
- They wrote code, lots of it. This breaks rule #6 on the Bloated MVP test.
They only score 3/10 on the Bloated MVP Test overall. That’s very much a Lean MVP. (I would never expect anyone to score 0/10. Startups don’t perfectly follow every rule of thumb!)
I have to say, it’s rare and impressive to see a product launch with tons of publicity, make $1M in ten days (and $3–10M/yr recurring revenue by end of 2020 if I had to guess), and still manage to be a Lean MVP. The Basecamp team is a talented bunch.
I’ve been using the product myself. I like it a bit better than Gmail for my personal email because:
- It’s faster. That’s an unfair comparison because my Gmail has to deal with a 16-year backlog of my emails, but still, being faster is really nice.
- It’s calmer. For example, I can forget to check my Feed for a few days, and only pay attention to my Imbox. This way, I save time and attention because I’m not distracted by random feed content in the middle of my day.
Designer Jonas Downey explains on Basecamp’s blog how they intentionally made Hey more calm/respectful/peaceful compared to other email software, and compared to for-profit software more generally:
At a high level it boils down to a handful of foundational principles that affect the decisions we make:
3. Prioritizing respectful interfaces that don’t overwhelm or try to nag the user into certain behaviors. We intentionally don’t include things like notification counts/badges, 3-column designs, and such unless we absolutely can’t avoid them. We don’t like the idea of having “sticky” interfaces — we want our customers to use our products to get the job done, and then go do something else. That makes the whole design approach more peaceful in general.
It’s a good principle with good execution.
Lastly, I’ll leave you with this proof that Hey isn’t bloated:
Ok, looks like there’s no way to pull up a list of recent emails I’ve sent 😂
It’s incredibly daring that they decided “Sent folder” wasn’t a must-have for their MVP release, while at the same time pouring lots of love on less traditional features like giving “spy trackers” the finger.
We can learn a few lessons from Hey: Dare to be opinionated. Dare to be principled. And most of all, dare to be lean.