Basecamp’s new email client is a tour de force of the “jobs to be done” approach in all aspects but one
I rarely cover specific products in this publication, but decided to make an exception this time for the following reasons:
- It’s a collaboration product, and collaboration is a core organizational need.
- It’s quite transformative in the way it approaches some big challenges with the existing solution (email).
- Many of the issues it’s addressing and the approaches that it’s taking to solving them apply to broader collaboration mediums that extend beyond email.
Screen and triage
Emails from new senders arrive at a “screen queue” where they can either be rejected or accepted and triaged to one of a few “work queues”:
- Imbox (default)
- Reply later — non-urgent emails that require a response.
- The feed —newsletter and other non-urgent recurring communications.
- Set aside — short-term reference: information about an upcoming event/meeting, document that needs to be reviewed, etc.
- Paper trail — long-term reference: receipts, reservation confirmations, etc.
Read and respond
Each work queue supports a slightly different workflow for handling the emails in it:
- Imbox — split between “new for you” (unread) and “already seen”. A “read together” feature opens all unread emails in a single screen enabling the batch review of all unread emails together.
- Reply later — offers a “focus and reply” feature, with similar UX to “read together” but adding a reply box to the side of each email.
- The feed — a news feed view with the most recent email at the top offering a preview of each email and an ability to expand (“show more”) the whole email.
- Set aside and Paper trail — a Pinterest board view with a visual digest of each email
In addition, email threads have the following additional features, impacting only the particular user (not all thread recipients):
- Rename the subject line.
- Merge threads of the same topic.
- Notify when new responses are added to the thread or when an email is received from a specific sender. (notifications are off by default).
- Clip (save for later) a portion of the email.
- Add a “note to self” to the thread — “response” that only the user can see.
- Add a “sticky note” to the thread that shows up under the subject line in the various work queues.
- Send large files.
- Unfollow (mute) — feature parity with existing solutions.
- Labels (tags) — feature parity with existing solutions.
Finally, recognizing that email is also used as an archiving system, HEY added the following features:
- “Paper trail” queue (discussed above).
- List of all the content clipped from emails.
- Contact view showing all correspondence that involved that contact, surfacing files separately.
- Files-only view
There’s also a neat privacy feature proxing all images and therefore preventing unauthorized data collection using a tracking pixel.
There is, however, one area where HEY misses the mark and fails to extend the “jobs to be done” approach into a critical element of the user experience: migrating work into the service. It is unlikely that users will rush to leave their native email address and immediately start using they @hey.com address. For many of us, our email addresses serves as a better unique identifier than our physical address. We change apartments more frequently that we change our email address and therefore this change is associated with non-trivial switching costs. While HEY does support auto-forwarding of email from your native email address, it does not (as of the writing of these lines) support defining a different “reply from” email address. Therefore, email responses from HEY will go out from the @hey.com email address, creating a confusing and discontinuous experience to the email recipient.
In sum, HEY creates a transformational email experience by acknowledging three deep truths and building them into the user experience:
- Different emails, different use cases — users engage with different types of emails in a different ways. We engage with an email from a good friend, a newsletter and last month’s internet subscription receipt differently. Therefore, the email client should support different workflows.
- Different users, different preferences — traditional email forces complete symmetry in the way two people view the same email thread. HEY breaks that symmetry and allows users to modify and annotate the threads in a way that makes sense to them.
- Communicate AND document — building on the framework I covered here, while email is primarily used to communicate, it’s a sufficiently good system of record for documenting/archiving some critical content. Supporting that secondary functionality needs to go beyond good indexing and a search box.
If we zoom out, these truths apply to other non-email collaboration tools such as chat and discussion boards as well. Therefore, considering similar approaches to addressing them in those other mediums opens some thought-provoking opportunities.
One of the beautiful things about HEY is that it’s a “dumb” email client from a technical standpoint. There’s no AI/Machine Learning involved in any of the features I listed above. It screens the emails you tell it to screen, it triages emails to where you tell it to put them, it notifies you about emails you tell it you want to be notified about.
On the one hand, it’s an incredible testament to how far just deeply understanding what your customers are trying to do with your product can take you.
One the other hand, it may also be HEY’s biggest business risk. A HEY subscription currently costs $100/yr. But if HEY starts getting serious traction, how hard would it be for Gmail to catch up?