Asana’s first decade
Asana stood apart for a decade because of a clear design idea: teams and organisations could be accelerated by digital interfaces built on one-size-fits-all fundamentals plus adaptable models. The base layer stayed simple and predictable. Each organisation adapted the parts that needed to fit their reality. That balance is what made Asana scale.
Much of that discipline came from Justin Rosenstein and the founding team. Less is more. Clean, simple, useful. It’s one of the core reasons many of us moved entire organisations onto it.
Asana has lost that balance now. Mentally overwhelming architecture and decisions are forced onto every user, regardless of whether the change fits their reality.
The departure: January 2020
The first significant departure from that approach that I recognised was January 2020, when subtasks started inheriting parent custom fields. @Jonas_O opened a thread — Make Custom Fields on subtasks optional. I supported it. We had multiple organisations on Asana and the change was forced on all of them without warning.
In that same thread, @Phil_Seeman pointed out that the inheritance wasn’t really the feature. It was a consequence of shipping subtasks in list view. Once subtasks appeared as rows in a project list, the project’s columns had to accept input, so the project’s fields ended up on the subtask.
The user need was real: surfacing fields from related work. Users had been asking for custom fields on subtasks. Multi-homing already solved it — add the task to the projects whose fields you want, use sections to categorise. The honest problem with multi-homing was custom field ordering, raised by @Jon_Jessen back in March 2019, still not resolved.
A parallel request, to surface more subtask levels in the main views, has been there since April 2020.
The right answer in line with the philosophy would have been to fix multi-homing’s ordering and make composable structures stronger — keeping inheritance decisions in the adaptable layer where each organisation could opt in.
A simple fix, even now
Add a per-project setting controlling whether subtasks inherit that project’s custom fields, with an organisation-wide default.
- Opt-in at org level
- Override per project
This puts inheritance back into the adaptable layer where it belongs. Brings back the original balance, doesn’t break what’s already built. Same pattern — users control what shows up where — solves the wider field-display issues from the threads above.
The pattern repeated instead
- January 2020: subtasks forced to inherit parent custom fields
- November 2020: dependency field surfaced on every task by default
- December 2022: subtasks added to Timeline, breaking horizontal stacking for Gantt-style plans
- October 2025: a new navigation experience that surfaced paid-tier features in the sidebar regardless of plan
- January 2026: task pane reorganised to group fields by project to “reduce cognitive overload”. Addresses one symptom, leaves the underlying model untouched
- May 2026 (this thread): parent project and inherited fields now surfaced inside the subtask pane, up to 5 levels deep. Asana cited a 2017 community thread as justification — same pattern repeating: real demand, wrong layer
Each of these is a decision that belongs in the adaptable layer, forced into the base layer for everyone.
@Peyton_Lee’s rationale on the January 2026 thread was honest about what triggered the change: tasks increasingly live in multiple projects and the pane became overwhelming. Right observation, partial fix. The pane is overwhelming for several reasons at once:
- Inheritance forces parent fields onto subtasks where they weren’t asked for
- Multi-homing surfaces every related project’s fields by default
- Users have no way to control what shows up where or for whom
@Leigh_Flynn’s reply earlier on this thread describes the same gap from another angle: table-based display, hiding null values, primary-project tagging. All of it only makes sense if users control presentation. Group-by-project on its own is a coping mechanism for a model that doesn’t allow that.
This isn’t a critique of effort. The teams shipping these updates clearly care, and individual updates make sense on their own. It’s a critique of accumulated drift away from a design philosophy that used to be Asana’s defining quality.
Our decision
For us this is the decision point. After 10+ years running multiple client organisations on Asana, we are forced to turn to alternatives. The drift is at the level of design leadership now, beyond what the retrofit above can fix. I hope my read is wrong.
AI changes what’s possible here. Each organisation can now have software built to its actual workflow, instead of fitting itself to a generic platform. A wave of these alternatives is coming, solving the same fundamental needs without the inherited complexity.
Transition takes time on our side. But in the new era of team collaboration, where digital capacity becomes omnipresent, Asana needs to pivot right now — or risk losing it all.
Thanks to the people who built the foundation. The first 10 years taught many of us what good work-software could feel like. 