Article
Project Management Tools as a Special Case of State-Based Collaboration
Most modern project management tools – Trello, Asana, Jira, ClickUp, Monday.com, Linear, and many others – are often described as task managers or productivity platforms. But underneath their UI, almost all of them share the same fundamental structure: they implement a simplified form of state-based collaboration.
Most modern project management tools – Trello, Asana, Jira, ClickUp, Monday.com, Linear, and many others – are often described as task managers or productivity platforms.
But underneath their UI, almost all of them share the same fundamental structure:
They implement a simplified form of state-based collaboration.
The states are usually extremely simple:
- Todo
- In Progress
- Done
These three states form the core lifecycle of a task. If you strip away advanced features, dashboards, and integrations, what remains is a state machine with three states and a handful of transitions.
This article explains how project management tools fit neatly into the broader idea of state-based collaboration, why they work well for simple task flows, and where they fall short when workflows become more complex.
Asana
ClickUp
Jira
The Core Insight: A Task Always Has One State
Even the simplest task management apps enforce the most fundamental rule of state-based systems:
A task can only be in one state at a time.
For example:
- A task can't be simultaneously "Todo" and "In Progress."
- A card can't be in two Kanban columns at once.
- A ticket can't be both "Open" and "Closed."
This single-state constraint is exactly what defines state-based collaboration: mutually exclusive states with visible transitions.
The Standard Workflow: Todo → In Progress → Done
Nearly every tool ships with this workflow (or a small variant):
1. Todo
The task is acknowledged but no work has started.
2. In Progress
Someone is currently working on it.
3. Done
Work is complete and the task is closed.
This is a minimal but fully functional state machine.
Even tools that don't show it explicitly are enforcing this logic behind the scenes. Users collaborate by moving items from one state to the next — the exact essence of state-based collaboration.
Why This Model Works So Well for Task Management
1. Users instantly understand the states
The meaning of Todo, In Progress, and Done is universal. This makes onboarding trivial.
2. Ownership becomes clear
When a task enters In Progress, someone becomes responsible for completing it.
3. A Kanban board visualizes the state machine
Each column corresponds to a state. Cards are simply items occupying a state.
4. It supports flow-based planning
Teams can measure throughput, WIP limits, and cycle time.
5. It prevents ambiguity
Tasks won't disappear into ambiguous half-states.
All of these emerge naturally from the fact that the system is built around explicit states and transitions.
The Hidden State Machine Behind Every Project Management Tool
Even though most tools don't describe themselves as "state-based," they all implement the same core features:
- A single active state per task — Exactly as in a finite state machine.
- Transitions that move the task through the lifecycle — Dragging a card from Todo → In Progress is a transition. Marking a task as Done is another.
- State-driven collaboration — Team members coordinate depending on the current state of the task.
- Work assignment follows state — Often, tasks are assigned when entering In Progress.
- Notifications follow state changes — "Task moved to Done." "Task assigned to you."
- History is recorded as state transitions — Most tools maintain a change log of status updates.
This is precisely the behavior defined by a state-based system.
Why Project Management Tools Are a Special Case
Project management tools are state-based but also simplified:
1. Very few states
Most workflows are limited to 3–5 states, rarely more.
2. Minimal transition rules
Typically, any user can move any card to any column.
3. No explicit lifecycle model
The state machine is implied through the UI, not formally defined.
4. No validation or constraints
There's usually no enforcement of allowed transitions or required fields.
5. No branching or complex connectors
You can't model review loops, approval states, multi-step checks, etc.
In contrast, full state-based collaboration systems allow:
- explicit graphs
- validation rules
- custom transitions
- complex lifecycles
- state-owned roles
- governed handoff
- multi-entity dependencies
Project management tools implement the simplest possible form of that structure.
The Limits of the Todo → In Progress → Done Model
While the simplicity is a strength, it also introduces limitations:
1. Every workflow looks the same
Tasks with fundamentally different lifecycles are forced into identical states.
2. No support for roles or gated transitions
"Review," "Approval," or "QA" stages require awkward workarounds.
3. Conflicts arise when multiple teams use the same board
Engineering, design, product, QA, all using the same 3 states leads to ambiguity.
4. Lack of lifecycle clarity for complex items
E.g. bugs, features, requests, documents, and releases all need richer state models.
5. Parallel or dependent work becomes difficult
Project management tools assume linear, simple flows.
These tools work well because the underlying state machine is simple — but the simplicity also restricts how much structure they can express.
A New Perspective: PM Tools Are State-Based Collaboration Systems
Understanding project management tools this way reframes them:
- They use states to represent the lifecycle of work.
- They use transitions to move tasks forward.
- They rely on state visibility for coordination.
- They base ownership on the current state.
- They use notifications triggered by state change.
- They visualize states as Kanban columns.
In other words:
Project management tools are state-based systems built around a tiny, universal workflow.
This perspective helps explain both their strengths (simplicity) and their weaknesses (lack of extensibility).
Conclusion
Project management tools did not set out to implement state-based collaboration — but almost all of them ended up converging on the same model:
- A task has one state
- Users move tasks between states
- Collaboration happens through those state changes
This makes them a special case of state-based collaboration, optimized for managing simple task lifecycles like:
Todo → In Progress → Done
As workflows grow more complex, the limitations of this model become visible. But for the vast majority of day-to-day task management needs, this simplified state-based system is exactly why these tools are intuitive, lightweight, and effective.
Related content
This article connects to:
- What is State-Based Collaboration? - Learn the fundamentals of state-based collaboration
- State Machine Design Pattern - Understand how state machines work in collaborative systems
- State Systems vs. Process Systems - Learn about the difference between state-based and process-based systems
- Framework overview - Explore the full State-Based Collaboration Framework
Explore more articles
This article is part of a series exploring collaboration patterns and practices. Check out other articles or dive into the framework components.