Slack Threads: A Missed Opportunity

19 January,2017

Earlier today Slack announced their long-awaited support for threading. Apparently it has been in the making for 2 years. We at TMail21, (having built a thread-centric communication and collaboration app) were intrigued. We decide to take Slack threads for a spin and report our findings.

First the good part. Slack has done their usual bang-up job with polish. Everything just works and is fast to boot. And they introduced threads without disturbing their main user experience (UX) much. This is probably a good thing since users who don’t care about threads won’t be shocked by massive changes.

Slack Threading Image

This was done by making Threads a junior partner to Channels. Every Thread is in essence a child of some Channel message. In this perspective, a thread is a side conversation in a channel. Slack threads really do not make too much sense outside of their parent Channel context. This perspective works to de-clutter a Channel and is valuable in that regard.

However, from our perspective they missed the bigger opportunity with threads.

Instead of making Threads subordinate to a Channel message, another perspective is to make Threads the primary communication and collaboration entity. Making threads the primary entity shifts one’s conception of work from being a never-ending stream of messages to work being composed of bounded, topic-oriented discussions. In fact, with the addition of some interesting features (detailed below) we can start to think of Threads (and work) as composed of a series of micro-projects. This has some major implications for productivity.

Before we go into the productivity implications of this, let’s look at what the main elements of a thread-first approach would be.

  • Threads are first class entities.
  • Threads can be tracked via tracking numbers that can be easily sent around.
  • Threads have a topic/subject that define what they are about
  • Users can prioritize their Threads preferably with a state-of-the-art prioritization approach like Kanban (think Trello).
  • Since going back and forth on content is a major part of work, Threads can (and in our opinion should) support the notion of Updateable¬†content sections. as part of their repertoire.
  • Since work demands accountability, a task management capability embedded into threads vastly increases their capabilities and essentially turns them into lightweight micro-projects.
  • Threads should be taggable, searchable, forwardable and cloneable


TMail21 Threads

With capabilities like the above Threads are not just side-conversations but become the key building block of workplace productivity.

A rich thread-centric approach to workplace communication and collaboration can turbocharge workplace productivity by allowing users to conceptualize their work as a set of lightweight micro-projects. Micro-projects vastly enhance accountability via embedded tasks.

Since content embedded in threads is versioned and change-tracked it is easy to understand the latest state of the thread (rather than reading through hundreds of comments). It is also easy to see what has changed (via change-tracking). Compare this to the attachment-centric approach which provides neither of these critical capabilities.

Since all threads would be trackable via simple tracking numbers, this no longer isolates content into an application ghetto. Instead tracking numbers can be texted, emailed, sent via chat, put in applications, mentioned over a phone and yes, even typed into Slack etc.

If you are interested in what a Thread-first approach to communication and collaboration looks like, take a look at TMail21 ( )

Get Started Today

Show Buttons
Hide Buttons