When Worlds Collide: Collaborative Docs and Work Management

A trend is gathering momentum: Work Processing

We’re witnessing a major collision in two formerly independent sorts of activities, and the tools that support them. On one hand, the use cases and capabilities of what I call cooperative¹ docs — like Google Docs, Dropbox Paper, Quip, Dossier, and others — are overlapping to a greater and greater extent with the use cases and capabilities of work management tools (also called task management tools²).

We are approaching a red line, where the work processing models of doc tools are rich enough to cause the defection of users from work/task management tools.

The recent release of what is being called Quip 5.0 represents a new level of ‘project management’ capability, and so I thought it would be a good time to talk about this collision, and what we are likely to see in the very near term as cooperative doc tools (hereafter called ‘doc tools’) move farther into work management territory.

We are approaching a red line, where the work processing models of doc tools are rich enough to cause the defection of users from work/task management tools. A team investing time and energy in using Quip as the team’s shared work processing system would be unlikely to manage the same information in Trello, for example. This means that doc tools and work management tools are rapidly becoming competitors, or at least substitutes.

However, I believe there are complementary benefits in supporting both models, and being able to switch between them at will. At some times, visualizing the work on a given project as a list of tasks — ordered by priorities or filtered to show tasks assigned to a specific user, for example — is extremely helpful. However, work management tools conceal certain sorts of information that is helpful in getting a broader understanding of what’s going on in the project. As one example, most work management tools hide comments unless you explicitly open a task to see them. In a cooperative doc, comments can be viewed in context, without zooming into tasks one by one.

Therefore, I imagine we will see interconvertability between these two representations. That capability will come either by partnership — such as a Quip/Todoist cross integration — or else vendors will take on the challenge of building the other side of the equation for themselves. So, in the latter case, we would see Quip building the capability to present a view of the task-related information in a doc in a way that looks a great deal like a work management tool does. [Note: I have not explored the notifications capability of the new Quip, and will look into that at a later time.]

An Example Project

Here’s an example project — AdjectiveNoun is an imaginary company, and this represents a two phase research project I might undertake with them as a client— with tasks in Todoist:

Image for post
Image for post
Simple Todoist project

The equivalent in Quip might be this, although you already can start to see the stylistic differences of a doc: the comment that describes the project is displayed following the project name, whereas in the Todoist alternative, that is concealed in the project’s comments field.

Image for post
Image for post
simple Quip project

Note the numbered comment balloon, which can be expanded by clicking:

Image for post
Image for post

On the Todoist side, that comment might be seen like this, which is displayed in a panel that covers the project task list to a greater extent:

Image for post
Image for post
Todoist task comment

Metadata, like task assignment is shown by @mentioning a user name in Quip. Here I assign the two phases of the project to myself:

Image for post
Image for post
Quip task assignment

In Todoist, this is managed in a different fashion, but it is nearly equivalent:

Image for post
Image for post
Todoist task assignment

Currently, Quip lack the work management capability to respond to queries about task metadata, which a tool like Todoist — and its direct competitors — handles easily. This is balanced with Todoist’s lack of support for writing in a document style about what the AdjectionNoun project is all about.

Following the Trend Line

Today, Quip and its nearest competitors are far enough along the work processing trend line that users will begin defecting from conventional work management tools, although those same users will request exactly the features that they are leaving behind when they make that migration.

I am certain that at least the most forward-looking work management vendors are already thinking about — or implementing — cooperative doc style capabilities of their own, and in an entirely-predictable response to the ascent of work processing, they will find themselves building something that looks like a subset of a Quip work processing document.

And the existential bottom line: Those vendors that don’t rapidly move to implement the full spectrum of work management capabilities — docs and task management and social communications and tables — will have an increasingly difficult time, as users will migrate to offerings that do.

Footnotes

  1. These tools are often referred to as ‘collaborative’ docs, but the term ‘collaborative’ has been used in so many ways by so many groups that it lacks any real specificity. At core collaborative just means ‘working together’, which is vague. I prefer to be more exact, so for example, shared calendars are coordination tools, not collaboration tools. And I would say that Google Docs is a cooperative document management tool, since it enables people to share documents if they want, but often in unequal, asymmetric ways. For example, I create a document without anyone else’s help, but then share it with a small group, granting them only viewing and commenting rights. That’s a tightly orchestrated, asymmetric sharing and participation, which reflects the reservations and nuances of cooperation, as opposed to the symmetric and unreserved feel of ‘collaboration’.
  2. I reserve the term ‘task management’ for soloist tools — a single user, no assignment of tasks, no sharing of tasks — and ‘team task management’ for shared task tools that however lack more modern social communication capabilities, like comments, activity streams, or chat, all of which are found to a greater or lesser extent in ‘work management’ tools.
  3. I will mention as an aside that many people find it most natural to manage task and project information in a table, as in a spreadsheet, or a work processing table. Some of that comes from the way that tables organize information neatly — rows and columns — and some is due to additional functionality, like calculated fields, or sorting based on cells values. Logically, there can be an interconversion between a list of tasks as in the examples of lists in Quip or Todoist, as shown above. Here I show such a table, for reference:
Image for post
Image for post
A table presentation of the project

Written by

Founder, Work Futures. Editor, GigaOm. My obsession is the ecology of work, and the anthropology of the future.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store