Imperative mood all the things

Okay, so a task is something that requires action, therefore it would make sense if all actions are sentences written in the imperative mood. So, why not require (or at least make it a convention) that tasks are simply a sentence written in the imperative mood? All other details of the task should be references (more on that later). With this, each task that is created is a command to do something and the person “completing” the task is the one confirming that the action was done (it’s a claim by that user). I argue this is all you need as a framework to be productive.

How do you handle more complex actions? The solution is to make each task “blocked” by their dependencies; all sub-tasks must be complete before a parent task can be completed. We only have one relationship between tasks and that is a one-way relationship: task A requires task B to be complete. We can call this a sub-task, dependency, or whatever. But this creates a hierarchy of tasks which describe workloads that require multiple steps and perhaps even parallelize the work between multiple people.

All work can be described using a task (and the tree/graph of tasks beneath it). This means a “project” is just a task: “Complete Project/Initiative”. A project “view” is merely all sub-tasks for the project task. The person who marks the project complete vets that it has been done in real life.

Where things get really interesting is when you have workflow designed around tasks. Currently workflow is thought of as moving tasks around some buckets which introduces another idea into the system and makes tasks have more than two states (instead of just incomplete/complete). Instead of adding more state to tasks, we could perhaps model our workflow as tasks. For example, in order to fix a bug you’d have sub-tasks such as “Figure out solution”, “Implement solution”, “Submit pull-request”, “Review pull-request”, “Verify solution fixes bug”, etc. Each sub-task here may not be created with the parent task right away, but rather the sub-tasks may be created as their needed because not all actions are known upfront in the real-world (sometimes no pull-request is needed for example). Now, the UI that we’re used to (kanban boards etc) can be templates or designs that create sub-tasks for our tasks as we drag tasks around in the UI; the underlying model isn’t change though. A list in a kanban board is a filter of all tasks with certain subtasks, and same with “sections”. All UI becomes “filters” or “queries” on the underlying data model (tasks which can have sub-tasks; trees).

Now, what about all the other things like fields, and what not? One idea I have is to remove description in favor for linking parts of the title out to some other object: “Implement feature A according to spec”. The link could be to a spec document for the feature. This replaces the need for the ambiguous field “description” with a directly correlated reference to some information that ties into the imperative mood of the task.

But what about fields which are merely there for organization; assignee, tags, categories, etc. Well, I think these could be modeled as tasks as well. An assignee is just a task like “Complete 's tasks for sprint ”. All of the tasks that would have been assigned to this person are sub-tasks for this task. The reference/link to this person in that task is something the UI could query for and even present all the sub-tasks in a nice “Your Tasks” view showing the top level tasks as sections and their sub-tasks as the actual work required. The same could be done for tags/categories: “Complete all <tag/category> tasks”. However, this means our tasks can have multiple parents, doesn’t it; our model isn’t really just a tree, it’s a graph!

Why am I proposing this model? I think keeping the mental model behind the tool as simple as possible is important for people to learn how to use the tool. If they know every task is just a sentence written in the imperative mood, then it’s clear what the contract between the user and the tool is: describe tasks as succinct sentences to convey the requirement to complete it. Then all the other things built on top of this fundamental idea is discoverable and flexible. Users can understand that a “project” is just a collection of tasks that are all related to each other in a uni-directional relationship. The tool can provide convenient automations that “build” the tasks they need according to the workflows they define. The tool queries what is just a graph dataset in many different ways without requiring the model to be extended or modified in order to get features that are useful to the user. Organization is just a matter of describing the work that needs to be done using this simple primitive idea, a task. Now the user can actually get the work done in real life, and spend less time learning new concepts and ideas to communicate the work that needs to be done. I imagine the tool will mold to the workflow of the team/organization as certain filters/automations are set in place all for the purpose of making it quick and convenient to make note and communicate of what is needed to be done to the entire team (This aligns with GTD methodology).

Furthermore, power users could develop integrations through an API to create automations that even Asana’s official app may not even be able to accomplish. These queries and automations could be rolled into 3rd-party apps and even in-house organization integrations that make sense to each unique organization.

Can we make Asana more like this?

I cannot edit the post after submitting it. There are some formatting issues…bare in mind.

Should have read:

An assignee is just a task like “Complete person’s tasks for sprint ”. All of the tasks that would have been assigned to this person are sub-tasks for this task.


Very interesting writeup, thanks.

One thing I’d be interested in is to hear what things you feel should be changed in Asana to make it more like you describe. I need to read your post again but it seems like what you’re describing is very much like Asana works now, so interested to hear how you see it’s not and what would bring it closer.


Hi and welcome!

Thank you for your input and your ideas. I really like hearing about other approaches or ways Asana should or is used by others.

So my understanding of your post is more like how you would like to use Asana and how you would have your team trained to accomplish this philosophy/usecase.

Let me know if I got you wrong. :slight_smile:

Overall, it is definitely something that we could try to do in Asana today, but the more important aspect to what I suggest isn’t about the ability to do this but the constraints in other areas. For example, the fact that Asana gives the user the ability to throw in as many fields as they’d like to a task gives the user misguided freedom. The fact that there is an entire description area to write as much information as they’d like is expensive because they can feel a need to fill in the void rather than focus on making the task title succinct and meaningful (they’ll end up being lazy in the title, and putting too much in the description); this is expensive because it’s time wasting both in writing and in digesting the task information. My argument that if there were the right constraints in place, the user will be able to focus attention on data entry that matters and is useful.

If more information is needed to describe a piece of work, this must mean the work can be broken down into pieces of the work. For example, “Build feature called XYZ” could have a checklist of sub-tasks like “Include abc thing”, “Ensure some other requirement”, “Check that this is the case”, etc. Each sub-task is still written in the imperative mood and builds the requirement to the parent task. After all, a “requirement” could be defined as: the set of dependency tasks that must be completed before the dependent task can be completed.

In the end of the day, that task is actually in doing the work, and the Asana Task is really just record entry for the work. The best task management tool is one you hardly use (because it is so seamless in both entry, organization, and access which is ideal for saving time so you can actually get things done).

1 Like

I believe the goal of Asana is to stay generic, and not constraint anyone into “one way” of doing things.

My experience is that people usually don’t write anything in the description, rather than the other way around :thinking:

We all use Asana very differently. For example we use it as a wiki in some areas of the business, as a database in others… So Asana’s capabilities are useful to us.