blog, crypto, futurism, newsletters, philosophy, politics, reflections, review, science, startup, venture capital

Superhuman is not enough for productivity. Here’s why

I don’t want to constantly switch between Figma, Slack, Notion, Jira, Asana etc.. and I don’t want to get bombarded by email notifications…

Superhuman is not enough for productivity. Here’s why

I don’t want to constantly switch between Figma, Slack, Notion, Jira, Asana etc.. and I don’t want to get bombarded by email notifications!

This article is written in response to Julian Lehr’s article titled “Superhuman & the Productivity Meta-Layer“

Superhuman vs Slack: A Battle for Productivity Apps communication channel

Julian started his article referring to Kevin Kwok’s excellent article on The Arc of Collaboration. Contrary to what Julian suggested, reading the whole thing, I think you shouldn’t. Because I’ve made a summary for you lazy souls out there.

Summary of Kevin Kwok’s article

Kevin Kwok’s Problem Statement:

Productivity and Collaboration have been handled as two separate workflows.

Evidence:

This is what the painful status quo looks like 👇🏼 (ref: Kevin Kwok’s original essay)

  1. Before Dropbox and GSuite, we started with individual files that we sent back and forth via emails
  2. After Dropbox and GSuite enabled live collaboration, we still switch out of these platforms/apps and communicate with each other via e-mails.
  3. Slack shows up. It wants to replace emails for inter-productivity apps communication.
  4. But it is PAINFUL to have to switch out of GDocs in order to Slack your colleagues about recent changes!!!

Well, Kevin's right, and as we can see, Figma, Notion, Airtable, etc all have messaging natively built into their apps. Yet, you still have to switch back and forth between silos.

I agree with Kevin. This is definitely a pain-point. I’ve been bombarded by notification emails from Slack, Asana, Figma, Notion, Airtable, GDrive etc. almost multiple times per week, if not daily.

Kevin’s (proposed) solution:

The solution might be a meta-layer on top of the productivity stack that works horizontally across all function workflows.

It’s not clear yet what exactly this meta-layer would look like but it might be something similar to what Discord is to gaming.

And this is the part where Julian comes in.


Slack is insufficient (Julian)

Julian in his essay argued that Superhuman (but not Slack) will become “the center of gravity for productivity”.

And I completely agree with his analysis of our status quo. Now we’ve got multiple inboxes as we need to check notifications from Github, Trello, Asana, Jira, GSuite etc.

What Slack is trying to do is to add a meta-layer to all of our notifications and all of our communication channels.

Julian’s “Slack” notification model (Taken from his article)

What Slack does really well is the “notification”. However, if you want to act on your notification (e.g. from Asana), you have to switch to Asana.

Productivity and collaboration remain separate.

I hold a bit of a contrary opinion on this. For my use case, I actually like Slack’s integration with other platforms. Yes if I receive a notification on Slack from Asana, and I will need to switch to Asana if I want to act on it. But isn’t that just inevitable? It is annoying but not painful. I’m fine with it because I know that there is 0 possibility of a SUPER-app like WeChat where all I do can be squeezed into just one app.

Julian also complained that “Slack isn’t the perfect tool to manage notifications.”

Incoming alerts aren’t really bundled in one place but appear across different channels and between different messages. This makes it really hard to keep track of which notifications you have seen and which you have taken action on.

Again, this might be particular for my use case. I get hundreds of messages on Slack every day since I am in multiple workspaces and communities. But I actually LOVE the fact that alerts are NOT bundled. I want them to remain separate across different channels and workspaces.

Can email treat notifications like tasks?

We’ve spent a considerable amount of time above outlining what the problem is. Here is a potential solution and it is really really interesting.

Courtesy to Julian who pointed out that back in 2013, the Mailbox team built an email client that looked more like a to-do list than an inbox. This is something that I have never heard of. Credits to Julian.

On Mailbox, swipe left, you can snooze your email. Swipe right, you can mark it as done. Tinder for emails.

Oops 🙊 wrong “X for Y” metaphor.

Julian’s graphic showing how Mailbox works

Mailbox got acquired by Dropbox and by then, the emails-as-tasks concept becomes prevalent. Now on Gmail and Outlook, swiping left and right on emails is commonplace.

I agree with Julian that we should definitely take this step further. And push the emails-as-tasks concept. And here’s the part where Julian introduces Superhuman

Is Superhuman the Solution?

Superhuman, for those who don’t follow the Valley’s hype, is an email client that is exclusive (invite-only with a waiting list), expensive ($30/month), and feels like Apple (with its sense of community/belonging/polarized UX feedback)

Julian seems to love the keyboard shortcuts available on Superhuman.

Ref: from Julian’s article

And Julian also loves the command-line interface and completing actions without pressing buttons or pressing the right hotkeys. At the moment, Superhuman commands are limited to typical email actions (snooze, send later, etc). So to me, this seems like an accelerated email function-set. Perhaps it saves you 30 seconds each day pressing buttons.

Will Superhuman add a calendar and a Kanban-like/Miro-like feature?

Julian thinks so. But I don’t believe so.

Microsoft Outlook and Google GMail already nicely integrate with Outlook calendar and Google Calendar.

While Superhuman can definitely add these features to its product roadmap, they don’t contribute to its core differentiation from competitors — premium, exclusive, and fast. And remember: the speed is restricted to Inbox Zero and the overall email-reading UX.

Of course, Superhuman can open its platform for API integration. From there, you can build smooth email-to-task and task-to-action UXs.

But the more you add, and the more “platform” your email client becomes, I think it is extremely difficult to build a smooth UX.

I see a lot of parallels here with Alfred 4 and Akiflow. Both are built on top of Mac OS and attempt to solve the tasks-to-action with a command-line interface.

Alfred 4
Akiflow

For the first few days using these two apps, I was amazed.

But as I spend more time with it, I tend to realize that for my use case, it’s not delivering as much value as I thought.

These apps only make the “opening” of an app, or the “redirecting” of an app, easier.

Still, I have to complete my tasks (or as Julian called it, “action”) on a separate app.

And now I start to ask myself: have I just downloaded an extra app that can’t 10x my productivity?

Meta-layer Communication: Future of Slack

In my opinion, email and productivity are per se different and will remain separate, as annoying as it is. This is because email is for communication and productivity is largely about task/project management. The caveat here is that obviously productivity is also about collaboration. And collaboration entails communications. Interestingly, the line here is to prevent having too much “communication”. Too much leads to the user overwhelmed by too much information.

Nonetheless, I am really excited to see what an actual meta-layer might look like. Email bombardment is indeed a problem. Constant app-switching from email to productivity software is also a problem. But what does the solution look like?

Just food for thought here, as I have absolutely ZERO ideas on how this can be done: a metaverse for the future of work, where productivity and communication blend into the digital workspace.

Has a16z written anything on this? I’ve seen several of their articles on the Metaverse of Gaming, but not on Productivity or the Future of Work.

Perhaps Slack will take the first-mover advantage and the embedded-network moat to attempt to solve this problem.

Better move fast than slow 💨 🏃‍♂️