Work technology vendors very commonly — for decades — have suggested that their shiny brand-new tools will deliver us from the tyranny of email. Today, we hear it from all sorts of tool vendors:
- work management tools, like Asana, Wrike, and Trello, built on the bones of task manager with a layer of social communications grafted on top
- work media tools, like Yammer, Jive, and the as-yet-unreleased Facebook for Work, build on social networking model, to move communications out of email, they say
- and most prominently, the newest wave of upstarts, the work chat cadre have arrived, led by Atlassian’s Hipchat, but most prominently by the mega-unicorn Slack, a company which has such a strong gravitational field that it seems to have sucked the entire work technology ecosystem into the black hole around its disarmingly simple model of chat rooms and flexible integration.
Has the millennium finally come? Will this newest paradigm for workgroup communications unseat email, the apparently undisruptable but deeply unlovable technology at the foundation of much enterprise and consumer communication?
Well, a new announcement hit my radar screen today, and I think that we may be at a turning point. In the words of Winston Churchill, in November 1942 after the Second Battle of El Alamein, when it seemed clear that the WWII allies would push Germany from North Africa,
Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.
And what is this news that suggests to me we may be on the downslope in the century-long reign of email?
Microsoft is apparently working on a response to Slack, six months after the widely reported termination of discussions of acquisition. There has been a great deal of speculation about Microsoft’s efforts in this area, especially considering the now-almost-forgotten acquisition of Yammer (see Why Yammer Deal Makes Sense, and it did make sense in 2012). However, after that acquisition, Microsoft — and especially Bill Gates, apparently — believed they would be better off building Slackish capabilities into an existing Microsoft brand. But, since Yammer is an unloved product inside of the company, now, the plan was to build these capabilities into something that the company has doubled down on. So now we see Slack Teams, coming soon.
Microsoft may be criticized for maybe attempting to squish too much into the Skype wrapper with Skype Teams, but we’ll have to see how it all works together. It is clear that integrated video conferencing is a key element of where work chat is headed, so Microsoft would have had to come up with that anyway. And Skype certainly has the rest of what is needed for an enterprise work chat platform, and hundreds of millions of email users currently on Exchange and Office 365.
The rest of the details will have to wait for actual hands on inspection (so far, I have had only a few confidential discussions with Microsofties), but an orderly plan for migration away from email-centric work technologies to a work chat-centric model coming from Microsoft means it’s now mainstream, not a bunch of bi-coastal technoids. This will be rolled out everywhere.
So, we are moving into a new territory, a time where work chat tools will become the super dominant workgroup communications platform of the next few decades. This means that the barriers to widespread adoption will have to be resolved, most notably, work chat interoperability.
Most folks don’t know the history of email well enough to recall that at one time email products did not interconnect: my company email could not send an email to your company email. However, the rise of the internet and creation of international email protocols led to a rapid transition, so that we could stop using Compuserve and AOL to communicate outside the company.
It was that interoperability that led to email’s dominance in work communications, and similarly, it will take interoperability of work chat to displace it.
In this way, in the not-too-distant future, my company could be using Slack while yours might be using Skype Teams. I could invite you and your team to coordinate work in a chat channel I’ve set up, and you would be able to interact with me and mine.
If the world of work technology is to avoid a collapse into a all-encompassing monopoly with Slack at the center of it, we have to imagine interoperability will emerge relatively quickly. Today’s crude integrations — where Zapier or IFTTT copy new posts in Hipchat to a corresponding channel in Slack — will quickly be replaced by protocols that all competitive solutions will offer. And Skype is that irritant that will motivate all these giants to make a small peace around interoperability, in order to be able to play nice with Slack.
We’ll have to see the specifics of Skype Teams, and where Facebook at Work is headed. Likewise, all internet giants — including Apple, Google, and Amazon — seem to be quietly consolidating their market advantages in file sync-and-share, cloud computing, social networks, and mobile devices. Will we see a Twitter for Work, for example, after a Google acquisition? Surely Google Inbox and Google+ aren’t the last work technologies that Alphabet intends for us? How might Slack fit into Amazon’s designs? That might surprise a lot of people.
But no matter the specifics, we are certainly on the downslopes of the supremacy of email. We may have to wait an additional 50 years for its last gasping breath, but we’re now clearly in the chat (and work chat) era of human communications, and there’s no turning back.
About Work Management
Work management is a term that has become widely used (one that I’ve advocated for some time) which represents the current state-of-the-practice in task management. Task management tools formerly were limited to a list of tasks: tasks with core attributes like due dates, descriptions, notes, attachments, and perhaps subtasks. These were amplified in more recent years with social sharing and communication, so that tasks could be assigned to other people, and comments could used to support basic communicate with team members (’team task management’). Nowadays, the most competitive tools incorporate social communications, like chat, @mentions, and messaging: these I consider work management tools, like Asana, Trello, and many others. I recently published a Gigaom report on this subject, 2016 Work Management Baseline Narrative.
About Work Processing
Using something like Dropbox Paper as a way to share work-related information is quite different than using a work management tool. Instead of putting lists of tasks at the center of the stage, relatively unstructured content — written text, images, tables, videos, audio, and other forms of content — takes the central role in information sharing, while tasks are indicated by checklists.
Metaphorically, work management is based on the human tendency toward making lists, while work processing relies on our natural urge to tell stories.
Metaphorically, work management is based on the human tendency toward making lists, while work processing relies on our natural urge to tell stories. Or, less romantically, work processing is more like writing in a journal, where occasionally you might add a list of things to do, but where the prose is where the most important information is found.
Using Dropbox Paper as a Work Processing Journal
For several weeks, I have used Dropbox Paper as a work processing journal. This experiment has not involved others, so the social dimension has been limited, but I’ve used Paper with teams in a few projects before, so I can talk to how that might work.
At the start, let me say that Dropbox Paper would be way more effective as a work processing solution if checklists were more task-like, and not just one of various sorts of lists, like bulleted or numbered lists. While checklist items can be used to indicate a task, and the checkbox can be checked to indicate being completed, if checklist items only had a bit more of a task model — with due dates, assignment, and so on — I would be more likely to promote Paper as a foundation for work processing.
Adopting the journaling model is straightforward. For each week, I create a new Paper document titled ‘week <Monday’s date>’, like ‘week 2016–08–29′. I define a Paper section to each day of the week, like 2016–08–29, or 2016–08–31. Then, for each day, I write notes and create tasks in one of the three timeframes:
- looking ahead, or prospectively;
- in real time, when I working on something alone or with others, as during meetings or on calls; or
- looking back, or retrospectively.
Here’s a screen capture (edited) of such a week journal:
Note the section markers in the left margin, where a click takes the viewer to the appropriate section, in this case, the five days of the workweek.
I haven’t displayed Paper comments: any piece of the doc can be selected and a right margin comment can be attached.
Collaborators can be @mentioned anywhere, which leads to them being notified. This requires them to be sharing the doc.
I started to used #tags in the document, although they aren’t supported yet, but it works for searching already, externally or internally.
I also create individual docs for calls and meetings, since they are better shared in that granularity, but I will often retrospectively copy some lines and/or tasks from such a call/meeting document back into the week journal, since it serves more as the system of record than individual call/meeting docs.
Where Dropbox Paper Falls Short in Work Processing
I’ve mentioned the problems with using checklist items as tasks, already, as the major issue with using Dropbox Paper in this way.
Other aspects of the experiment worked surprisingly well for me. I thought I’d miss a rich task model — due dates, notifications, etc. — more than I did. What I learned is that I relied on propinquity: the week journal doc was basically open all day, and as I was adding more information to the various sections I would reacquaint myself with things I need to be working on for Friday, or next week, as I entered new content. And I felt like I had a better big picture sense of what I was working on each day and for the week, than when I just relied on a work management list of tasks.
It would also be great — since Paper supports the idea of doc sections — if sharing could be linked to the section level of a doc, and not just the doc as a whole. Then I could create a section in a journal doc for a single meeting, for example, and invite those attending to share just that section.
However, the core problem I’ve encountered is the dimension of time. Journaling and task management aren’t organized around semantic nesting of docs in folders or the semantic structuring of content within docs, which is the organizing principal of Dropbox Paper (and other tools like it). Journaling and task management should naturally be based on time — hours, days, weeks, and months — not semantic nesting. Yes, I created a form of doc based on a weekly journal, but it’s not native to Paper, just a poor approximation.
In my next post in this series, I will be writing about an alternative to content-centric work processing, one that starts with the calendar as its foundation. Coming next in the Work Processing series: Beyond the Calendar, to Work Journaling.
Originally published at www.stoweboyd.com.
Doist has released version 800 of the team task management solution, Todoist, effectively moving the tool into the work management category. In particular, Todoist now supports activity ‘logs’ (or ‘streams’), project notes, improved microsyntax for quickly creating tasks, and a reworked notification system user experience.
Work management is a term that has emerged in recent years as team task management tools were enhanced with various social communication capabilities, principally derived from design motifs that originated in work media (or enterprise social network) tools (like Yammer, IBM Connections, and Jive).
The new activity stream includes recent comments and project notes (although they are named ‘comments’ in the activity stream.
The new project notes is basically a reuse of the existing model for task comments. This has the benefit of being familiar, but falls short of what I’d like to see since task comments and, now, project notes, are not visible until the icon is clicked, and then they appear in a hover box, covering the task list in the project.
It would be much better if display of project and task comments was more like the new activity stream. Imagine that I click the comment icon in either case, and instead of the hover window instead the comments would be displayed below the title in a scrollable list. Here’s a mock-up:
And I would like to see explicit replies, too. A flat series of notes or comments creates all sorts of headaches.
The most important takeaway is that Todoist has now moved from team task management to being a true work management tool. While there’s a lot still to do with the new features, Todoist’s traditional strengths — ease of use, flexibility in ordering and nesting of tasks and projects, and smart integration with Gmail — are still in place. But now Todoist is gaining important features for workgroup cooperation and coordination.
I have been using a new app for the past week or so, called Missive (missiveapp.com). When I first looked at the tool it was just a social email client, by which I mean a client for email that also support social communications extrinsic to email, but possibly about email. However, at that time I found that I could use a Google exention to integrate it with Todoist (see Missive looks like a MVP ‘Social Email’ tool). But now, they’ve released their own task implementation.
Here’s a screenshot to reprise the basics of Missive:
Above, on the left you see an email being edited — a reply to an email from Carlos Kelly — but on the right is a chat among Rafael and others working at a company called Conference Badge. They can share docs — like the PDF quote — and talk about the email thread. The email becomes shared, as are the chat comments and attachments.
Missive also supports group chats not explicitly linked to specific emails, as shown above.
But what is most exciting — and what I have been waiting for — is the addition of tasks to Missive. These have been implemented as a special version of the basic comment feature in chats, except the user selects the task option:
Above you see a comment being created, and as you see they can be assigned to one of various users.
And above, you can see that tasks have a status box so that someone can check off the task as done. (Personally, I favor a three state model — created, in process, completed — but I will wait to convince them of that.)
All open tasks are visible in the ‘tasks’ section of the client, which shows all chats with tasks and provides a count — like 1 of three — to indicate how many tasks are contained and completed.
Missive builds on Gmail, and allows users to file emails in gmail labels. These will be for personal, private use.
I’ve been told that this simple organization technique — I’ve been bumping my head on it for just a week or so, painfully — will be extended in the very near term with tags. As a result, I will be able to pull into a single list all the tasks that are tagged ‘#projectXYZ’ or ‘#finance’ no matter what chat they were originally created in.
Tags, unlike labels, will be shared and available to those in your Missive ‘organizations’ or teams. I am eagerly awaiting the release of tags in Missive, to make it a richer experience and one that is much more manageable. I am also awaiting due dates, and other metadata for tasks, but tags are the most important, I think.
The Bottom Line
Missive is an example of content-based work management — where the tasks are embedded in chats associated with specific email threads or chat contexts — based on a social email foundation. I believe this is one of the few models of work management that will attract a large user base following the decline of web 2.0 era work media tools (like Yammer, Jive, IBM Connections, and so on). Yes, Slack and its work chat direct competitors are getting a great deal of the buzz at present, but email is here to stay, and the emergence of social email — like Missive and its competitors — will be giving email another decade or more of life.
I’ve been exploring a growing list of web-based tools for the creation and management of what most would call ‘documents’ — assemblages of text, images, lists, embedded video, audio and other media — but which, are in fact, something quite different than the precursors, like Microsoft Word and Apple Pages documents.
The big shift underlying these new tools is that they are not oriented around printing onto paper, or digital analogues of paper, like PDF. Instead, they take as a given that the creation, management, and sharing of these assemblages of information will take place nearly all the time online, and will be social at the core: coediting, commenting, and sharing are not afterthoughts grafted onto a ‘work processing’ architecture. As a result, I am referring to these tools — like the pioneering Google Docs, and newer entrants Dropbox Paper, Quip, Draft, and Notion — as ‘work processing’ tools. This gets across the idea that we aren’t just pushing words onto paper through agency of word processing apps, we’re capturing and sharing information that’s critical to our increasingly digital businesses, to be accessed and leveraged in digital-first use cases.
In a recent piece on Medium, Documents are the new Email, I made the case that old style ‘documents’ are declining as a percentage of overall work communications, with larger percentages shifting to chat, texting, and work media (enterprise social networks). And, like email, documents are increasingly disliked as a means to communicate. And I suggested that, over time, these older word processing documents — and the use cases that have built up around them — will decline.
At the same time, I believe there is a great deal of promise in ‘work processing‘ tools, which are based around web publishing, web notions of sharing and co-creation, and the allure of content-centric work management.
Chat-centric work management, as typified by Slack-style work chat, is getting a tremendous surge in attention recently, and is the now dominant form of message-centric work technology, edging out follow-centric work media solutions (like Yammer, Jive, and IBM Connections).
Workforce communications — relying on a more top-down messaging approach for the mobile workforce — is enjoying a great surge in adoption, but is principally oriented toward the ‘hardwork’ done by workers in retail, manufacturing, transport, security, and construction, and away from the ‘softwork’ done by office workers. This class of tool is all about mobile messaging. (Note: we are planning a market narrative about this hot area.)
Today, I saw that David Byttow’s Bold — a new work processing app — has entered a private beta, with features that line it up in direct competition with Google Docs and the others mentioned above. Bold raised a round of $1 million from Index Ventures in January 2016.
The competition is hotting up.
Work Processing Will Be The New Normal
What I anticipate is the convergence on a work processing paradigm, with at least these features:
- Work processing ‘docs’ will exist as online assemblages, and not as ‘files’. As a result they will be principally shared through links, access rights, or web publishing, and not as attachments, files, or PDFs, except when exported by necessity.
- Work processing apps will incorporate some metaphors from word processing like styling text, manipulating various sorts of lists, sections, headings, and so on.
- Work processing will continue the notions of sharing and co-editing from early pioneers (Google Docs in particular), like edit-oriented comments, sharing through access-control links, and so on.
- Work processing will lift ideas from work chat tools, such as bots, commands, and @mentions.
- Work processing will adopt some principles from task management, namely tasks and related metadata, which can be embedded within work processing content, added in comments or other annotations, or appended to ‘docs’ or doc elements by participants through work chat-style bot or chat communications.
I am pressed for time today, and can’t expand on these ideas with examples, but I plan to do so quite soon in a companion post to this, called Work Processing: Coming soon to a ‘Doc’ near you.
Microsoft Planner — the work management complement to Office 365 — was made available as a preview in December 2015, but has entered ‘general availability’, meaning it will become immediately accessible to users of eligible subscription plans. In Office 365, it will appear as another tile in the Office 365 tools (see the leftmost tile in the second row, below).
Microsoft Planner is a task-centric work management solution, despite the ‘project management’ terminology other reviewers are using. The orientation of the tools is to support teams and team members tracking tasks and coordinating task work through social communications.
Planner is one of several task-oriented solutions that Microsoft is working to integrate, including Wunderlist and Microsoft Project. Conceptually, this means that users will be able to manage personal tasks (in Wunderlist), team work (in Planner), and to manage project planning (in Microsoft Project), and for these to be integrated in sensible ways. So for example, it might be helpful if I could see my work-related tasks, perhaps created and annotated in Planner, in a mobile Wunderlist app. Or to analyze the cost implications for a shift in personnel in a Planner project within the portfolio of company projects managed in Microsoft Project. That’s one part of the company’s long-range vision for Planner and the other tools manipulating task information. But it is going to be a long time before all the kinks and use cases are worked out for that grand vision. And at any rate, ultimately Planner will have to stand on its own, based on how good of a work management tool it is.
And that assessment poses another issue. If Planner requires Office 365 in order to use it — or even experiment with it — many prospective users will simply never jump through the hoops to try it out. I have raised that very issue with Microsoft representatives this year, as I was being briefed on the product. My suggestion is that Microsoft should create a standalone version of planner — at least a web app, if not mobile apps — so that an individual, team, or company could do an apples-to-apples comparison with Asana, Trello, or Wrike, and not the apples-to-oranges comparison with the umpty-ump boxes in that Office image, above. Also, that is the best way for Planner’s functionality to improve — in head-to-head competition — and not as a captive work management ‘capability’ locked into Office 365, relying on its integration with Office email, Outlook, Groups, and other tools.
The following is a condensation of the review of Planner from the in-process 2016 Work Management Narrative (much delayed), that I am authoring.
Planner is based on the well-known kanban-style, ‘board’ architectural model, and three modes of boards are supported at present: user-defined ‘buckets’, task assignment to members, and progress. As shown in the screenshot below, there is a left hand column where I have selected a plan, in this case Work Management Narrative, and I chose to display that plan as Buckets, not by Progress or Assigned to. In the ‘research tools’ bucket there is a single task, ‘research Microsoft Planner’, which shows icons indicating 0 of 2 subtasks have been completed, that there are comments, and the task has been assigned to Stowe Boyd. The half moon icon indicates that the task is in progress, a third state for tasks: unstarted, in progress, and completed.
Clicking on ‘write method section’ expands that task (or, in the usual terminology, turns over the ‘card’), as we see in the screenshot below. At the foot we see a stream of comments — the one with a white background was entered in an associated discussion, about which more later. There are a variety of other attributes, showing a rich task model, however, lacking support for some common social communications like ‘@mentions’.
What’s not clear from this zoom into Planner is that the ‘work management narrative’ plan corresponds to a Office 365 group of the same name. Groups support group-oriented communications, but those are not accessed in the Planner section of Office 365.
I believe that Planner users will find the need to return to Outlook to conduct conversations about their projects annoying, as opposed to the more normal model of an in-context — or best, in-project — activity stream. I bet that Microsoft will hear this as a frequent suggestion for additional Planner functionality. However, I often operate in multiple windows on the same project workspace, and so, having a conversation window and a Planner board view open at the same time is really not very different, and may be workable for many. Note also that if Microsoft builds a standalone version of Planner there will be no Outlook to lean upon, so an in-context activity stream or chat model would be best.
Office 365 users are likely using the spectrum of features — Outlook, OneDrive, Office apps, Groups, OneNote, and Planner — and therefore will rapidly habituate to transiting the many loosely integrated components, and will likely adapt to a model of use involving a lot of moving around.
By itself, Planner would only be considered a team task management tool, not a true work management tool, since it lacks activity streams, @mentions, and other baseline social communications. However, that’s a red herring, since Planner — at present — is never without Groups and Outlook, and can’t be separated from them.
At present, I think the initial implementation of charts is a better indicator of where Planner is headed. In the screenshot below I’ve pulled an example from the Microsoft website (since my examples aren’t rich enough), and this shows the ease of quickly grasping the status of a Planner ‘document’ through a dashboard view.
I also want to give a nod to the designers of Planner for including the three state model for task status: not started, in progress, and completed. The in-progress state is incredibly powerful, and after using it in some tools, I now chafe whenever confronted with a solution that lacks it.
Planner is an obvious choice for those already committed to Office 365 as a baseline for work productivity. However its current level of integration with Office 365 services — like Outlook, OneDrive, and OneNote — falls short of work management nirvana. Still, it’s early days, and when I reviewed it the product was only in a ‘First Use’ release phase.
I can imagine that within a very short time frame the myriad hooks that could make Planner a first-class member of the Office 365 suite will begin to emerge. I wager that creating tasks from email, or in the comments of a Groups or OneDrive comments — as just some of the most obvious examples — will be implemented within the next few releases, or sooner.
Because Busybot and Slack look so much alike and are so tightly connected, I avoid the cognitive costs of switching.
I’ve tried using work management tools like Asana in connection with Slack, and the results have been mixed, principally because — I think — there is a mismatch in the basic orientation of the tools: Slack is messaging centered, while Asana is task centered.
In the case of a tool like Asana, when the Slack connection is used notifications are sent to a Slack channel whenever changes occur in the Asana workspace. For example, whenever a task is created, completed, or commented upon. A slash command (‘/asana’) lists tasks, and arguments to the command can lead to creating tasks, assigning tasks, and commenting on them.
But I confess that I have found this style of integration difficult. The two models of use — chat-based conversation in Slack and task-based coordination in Asana — don’t align for me, and the mapping from an Asana workspace to a Slack channel doesn’t always line up right. And I don’t necessarily want to have every tweak to a task dumped into the channel in Slack, per se. I don’t want that endless stream of noise, because Slack is noisy enough.
I recently encountered a tool that takes a different tack. Busybot avoids the mismatch problem by operating in a parasitic way. By that I mean it relies totally on Slack’s architecture to the greatest extent possible. For example, there is no independent login: you use Slack’s login. And once logged in, the channels of the team that you sign into are duplicated as contexts for tasks in Busybot.
Here’s the login:
Here’s the #general channel for workfutures.io in Slack. You can see that I /invited busybot to the channel (I had already created the integration).
I typed a message to busybot, ‘ask Esko for a contribution’. If I had added ‘@stoweboyd’ that would have assigned the task to me, as well.
Over in Busybot, everything looks extremely similar:
On the left, the design of Slack is emulated, so that for each Slack channel there is an equivalent Busybot channel, where all tasks can be found. I’ve selected the ‘ask Esko’ task, and then the task pane opens. I’ve selected the ‘add checklist’ feature.
I’ve added a single checklist item, but you can have as many as needed. Also descriptions, comments, deadline, and assignment of the task are available as metadata.
The task list can be sorted, which is moot in this case, since there is only one task:
Also note that the ‘@stoweboyd’ option at the top opens all the tasks assigned to me, and ‘all tasks’ opens all tasks in the team, sorted by channel.
Tasks can be added, edited, and deleted in Busybot, but can only be created and displayed in the Slack side of the integration, at present. I’ve been told by Busybot’s CEO and founder, Damian Bramanis, that various new features are coming, like multi-team functionality, new ways to groups tasks in views, and tags.
Conclusions and Takeaway
Busybot works for me despite the minimal degree of metadata, and I think the reason is the equivalence between the Slack and Busybot information models: I don’t have to switch gears mentally when I move from Slack to Busybot, or vice versa. It feels like I am in the same place, just looking at different attributes of the same system of information. Moving from Slack to Busybot feels like I am just zooming in on task details that are suppressed on the Slack side. Because the two ‘sides’ look so much alike and are so tightly connected, I avoid the cognitive switching costs of moving from Slack to non-parasitic tools, like Asana.
Yes, I’d like to be able to do more with Busybot, though. For example, I’d like to be able to change task attributes on the Slack side, like adding a comment to a task, so that the text of the task comment would appear both in the Slack chat history and in the task comment thread. Damian tells me they are working on ways of accomplishing more sophisticated sorts of integration like that, perhaps with a /busybot command, or clever use of the channel topic (setting the topic to the name of a task, for example, so that commands could refer to that task).
At any rate, I will be watching the developments at Busybot with close attention.
I’ve been evaluating a long list of work management tools as part of the research for the Work Management Narrative report (see recent post, Work Management in Theory: Context). One issue that comes up a great deal is the integration with email, which is a common trigger for a user to create a task, as well as a means to communicate with other team members who may not be using the same — or any — work management tools.
This post doesn’t look into how work management tools use email as a way to communicate with team member not using the work management tool: that’s a separate use case. I’m focusing on email as a parallel sort of communication, and one from which a great deal of tasks arise.
There are a number of approaches to email integration, which I will categorize like this:
- Low or no integration: despite the ubiquity of email, and the obvious need to communicate to the wide, wide world through it (and email’s insatiable hunger to communicate with us, too) some vendors offer little or no support for the realities of email. Not good.
- Loose integration: some vendors have opted for a loose integration, often through bookmarklets or third-party connection services like Zapier and IFTTT. For example, Azendoo supports a Zapier ‘zap’ where gmails that I star become tasks in a specific project. Subsequently, the user can open Azendoo, and perhaps move the task to another project, add notes, fool with metadata (due dates, assignment, etc.). A bookmarklet — like Wrike‘s — accomplishes more or less the same thing. In either case, the connection is one-way, and the work management tool does not try to ‘handle’ email in a general way: the precipitating email is just a starting point for a task. At present, I think loose integration is the best approach.
- In-inbox integration: Some solutions — like Todoist (a team task management tool) and Sortd (ditto) — provide a Google Chrome extension so that when you are ‘in’ Gmail you can easily convert an email to a task (and add metadata, etc.) in a window while never leaving the Gmail context. This is a lot smoother than loose integration, especially for people who communicate through email a great deal. Also, clicking on a link back to an email makes it more of a two way solution.
- In-app email: Some tools aspire to replace the email client’s functionality altogether, basically pulling in all emails and implementing the services that emulate — at least in part — capabilities of email services. It is this last case that I want to zoom into in this post.
I’ve tried at least two solutions in recent weeks that seek to bring email integration in-app: Fleep and ScribblePost. I had an exchange with the CEO of ScribblePost, Alon Novy, about his company’s model of email integration. One outcome was the following post, shared with him through the company’s support system. In that post I suggested a more sophisticated version of in-app email integration:
I tried and rejected your competitor Fleep’s attempt to act as a email client.
The hybrid failed for some of the same issues I have with your approach:
1. I might have a number of other plugins or features that operate in the Gmail client that I can’t walk away from, like Google Tabs.
2. If I have to undertake email hygiene in both Gmail and in the work management tool, that is an impossible cost.
3. The design of an email client is distinct from that of a work management tool, and intended to meet a wide range of use cases, not just those related to work management.
My bet is that the best approach will be to have a close coupling, but not a full integration of email in the work management tool, like your SP [ScribblePost]. On the work management side, some emails — those that are starred, or labeled in a specific way — would have a handle created, so that the email can be indirectly referenced and annotated: for example, comments can be added to the handle, or a task can be created as a follow-up to the email that would be attached to link to the email handle.
I think that the email handle is a distinct type or object in the work management space, different from tasks, internal messages, and posts. An email handle is a specific example of a general notion: a handle to reference some info object principally or partially managed outside the work management solution. That could also hold for Twitter or Facebook messages, for example, or Salesforce contacts.
At any rate, SP could implement a set of actions for email handles that fall into two groups:
1. those that represent actions on the handle — like creating or deleting the handle, linking it to a task (as a special sort of attachment), sharing it, adding comments, moving a handle from one project to another, etc. — as opposed to
2. actions on the email linked to the handle — like reply, forward, archive, and so on.
I think such a two-faced approach covers the greatest number of use cases, including unforeseen ones.
You might also benefit from a chrome plugin for Gmail, so that some (or perhaps even all) actions that users might want to perform vis-à-vis the intersection of email and SP could happen ‘in’ Gmail. For example, I might read an email and decide to
1. start tracking this thread in SP,
2. associate one or more tags with the handle, and
3.assign a follow-up task to myself referencing the email along with some notes.
I could then get back to other email, some of which never crosses over into SP.
Note that the info handle concept lines up fairly directly with a platform play, obviously.
I applaud Alon and his team for the innovative ideas they are developing in ScribblePost, and likewise the brilliant design of Fleep, both products which I will be reviewing in the upcoming Narrative. I’m sharing this to stimulate discussion around these ideas, and also (shameless plug) to demonstrate the sort of thinking that animates the report.
This is an excerpt of the upcoming report, Work Management Narrative, in which I will be reviewing around a dozen products, including Asana, Azendoo, Basecamp, Clarizen, Fleep, Flow, Liquid Planner, Mavenlink, Smartsheet, Trello, Work Front, Wrike, Zoho Projects and others.
Work Management in Theory: Context
Work management is a term that has emerged in recent years as task management tools were enhanced with various social communication capabilities, principally derived from design motifs from work media tools. This increase of capabilities — and the resulting overlap of work management capabilities with those of work media tools — means that trying to assess the trends that are prevalent in work management really require stepping back. Today, there are a wide range of approaches to supporting cooperative work in the workplace, and they have many features in common. So, in many instances, groups or companies evaluating tools for team cooperation may consider offerings that are very different in their underlying design, and require correspondingly different approaches to their use.
The Lay of the Landscape
Here’s a table that attempts to make sense of a variety of technologies that are used in business to support cooperative work. It is not exhaustive, but I hope it will clarify some of the distinctions between these classes of tools. At the same time, there is a great deal of overlap so some degree of confusion is inevitable.
Today, there are a wide range of approaches to support cooperative work in the workplace, and they have many features in common. So, in many instances, groups or companies evaluating tools for team cooperation may consider offerings that are very different in their underlying design, and require correspondingly different approaches to their use.The primary distinction here is the degree of emphasis for task-centric versus message-centric tools. Those that we will focus on in this report are task-centric, even though there have to include some fundamental level of social communication to be considered work management tools. So for example, Todoist is a leading team task management tool, widely used in business. However, the tool lacks social communication aside from comments (‘notes’) associated with tasks: Todoist does not support messaging, discussions, activity streams, or ‘call outs’ (also called ‘@mentions’). While tasks can be assigned to others by the task creator, there is no other way that users can reference each other, or ‘talk’. And at the least social level of task management, personal task management tools don’t allow even the most basic level of business-oriented task assignment. As a result, team task management tools are not covered in this report, although Gigaom may develop a report like this one for that market, at some time in the future.
Work management tools share a lot of similarities with various message-centric work technologies. Note that I have divided the message-centric tools into two sorts:
- Follow centric — like Yammer, where the primary orientation of messaging is around following of message sources, and messages are primarily displayed in activity streams based on the user choosing who and what to follow.
- Chat centric — such as Slack, where the primary orientation of message is around chat rooms, or channels, and messages are principally displayed in those contexts when the user chooses to’ join’ or ‘enter’ them.
Some work media tools provide a degree of task management, although it may not be the primary focus of the tool. And, as a general case, products like Jive, Yammer, and IBM Connections have little or no native task management, relying instead on integration with third party solutions. Likewise, many leading work chat offerings, like Slack and Hipchat, don’t have native task management, also relying instead on integration with task management tools, like Asana and Jira.
Lastly, the class of tools I refer to as workforce communications (like Lua, Avaamo, Fieldwire, and Sitrion One) have characteristics that are like those of work media and work chat tools, but are principally oriented toward communications management with an increasingly mobile contingent of the out-of-office ‘hard’ workforce, such as construction, retail and restaurant workers, field sales, security, and others.
At the bottom tier of the table in figure 1 are tools that are not principally oriented toward business use, like personal task management (Todoist, and Google Tasks), social media (Facebook, and Twitter), and consumer chat apps (Facebook M, and WhatsApp). This are widely used in business contexts, although they aren’t geared for it. Note however that this doesn’t mean that they couldn’t be recast as team or work oriented tools, like the trajectory of Facebook for Work.
There are other less-closely related work technologies that are also not investigated here, like curation tools, conferencing tools, and so called ‘productivity’ tools (like Microsoft Office 365, Dropbox Paper, and Google Docs/Sheets/Slides). These, again, are candidates for inclusion in another report.
Next week, I will be posting another excerpt from the report.