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 some examples I created, mocking up this sort of interconvertability. I mocked this up with Quip 5.0 and Todoist.
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:
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.
Note the numbered comment balloon, which can be expanded by clicking:
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:
Metadata, like task assignment is shown by @mentioning a user name in Quip. Here I assign the two phases of the project to myself:
In Todoist, this is managed in a different fashion, but it is nearly equivalent:
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. This will lead the vendors to either incrementally or all at once implement presentation capabilities for task-related metadata that will look unsurprisingly just like work management dashboards. Similarly, other users might ask for table/spreadsheet presentations and capabilities, as well³.
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.
Work Processing: Coming soon to a ‘Doc’ near you
Coordinating work in ‘docs’, not in task management tools
- 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’.
- 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.
- 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: