Work management platform for tasks, projects, and goals, with Asana Intelligence for status updates and workflow suggestions.
Last updated
Asana is bought for a reason its feature list does not advertise. Organisations rarely adopt it because their teams need somewhere to put tasks — they already have somewhere, usually three somewheres. They adopt it because somebody senior cannot get a trustworthy answer to the question "how are our priorities actually tracking", and Asana is structured around producing that answer.
That makes it a different kind of purchase from the tools it is usually listed beside, and it fails for a different reason too.
The parts of Asana that justify its price are the upper ones: goals, portfolios, workload and the roll-ups built on them. A goal is meant to be a durable statement of intent that individual projects roll into, so that progress on the goal is derived from work rather than typed in by whoever prepares the slide.
Compare that to an issue tracker, which is built bottom-up: the issue is the atom, and anything resembling a portfolio is assembled afterwards from queries. Asana is built top-down, and the task exists partly so that something above it has a number. This is not a criticism. It is the correct architecture for the problem it is solving, and it is the reason engineers who evaluate it on task-level ergonomics come away unimpressed — they are inspecting the foundation and reporting that it is not a nice room.
Here is the failure mode, and it is close to universal in unsuccessful rollouts. Leadership adopts Asana for visibility. Teams keep doing their real work where they were already doing it. Somebody is then asked to keep Asana updated for reporting purposes, which turns it into a second system maintained for an audience rather than a first system used by practitioners.
A derived number computed from data nobody maintains is worse than no number, because it is believed. Executives make calls on a dashboard that reflects how recently someone remembered to tick a box. If you cannot answer the question "where does a person actually doing this work spend their day", buying portfolio reporting will produce confident fiction, and the tool will get the blame for a rollout decision.
Asana is not difficult to set up, and that is misleading. The difficult work is social: getting the teams whose data feeds the roll-up to treat it as the place the work lives, which means giving them something in return. Usually that is the removal of a status meeting, a weekly report, or a recurring request for an update — and it has to be an actual removal, not a promise.
Rollouts that skip this step follow a recognisable arc. Adoption is high in the first month because it is new, drops in the second, and by the fourth the portfolio view is stale enough that leadership stops trusting it and reinstates the status meeting. The tool did nothing wrong at any point in that sequence.
Engineering teams reject Asana for reasons that are specific and worth naming rather than dismissing as preference. There is no equivalent of the tight branch, commit and review loop that a developer tracker provides. Filing is heavier than engineers will tolerate for the volume of small items they generate. The vocabulary is task-and-project rather than issue-and-cycle. And the cadence model does not match how a team that ships continuously actually plans.
The pragmatic arrangement in most mid-size companies is not to win that argument. Engineering keeps its tracker; Asana carries the initiative-level record that the rest of the company reads, with a link between them. Trying to collapse both into one system is how you end up with a portfolio nobody updates.
Asana and Monday can both do most of what the other does, so comparing capability lists will not separate them. The difference is what each optimises when forced to choose. Monday optimises the operator's daily surface: visual, immediate, shaped by whoever owns the board. Asana optimises the structure above the work: consistent objects, goals that roll up, portfolios that mean the same thing in two departments.
The practical test is who complains after three months. If it is the people doing the work, saying the tool is fussy, you probably wanted Monday. If it is the people reading the reports, saying they cannot compare two departments, you probably wanted Asana.
Pick Linear when the users are engineers and the reporting audience is the team itself. Pick Jira when a process has to be enforced and evidenced rather than merely tracked, which Asana does not attempt. Pick Monday when the buyer is a department head who wants a visual system running this week and nobody upstairs is asking for cross-department comparability. And pick ClickUp if you genuinely want one dense system for everything and will accept the interface that comes with that ambition.
Finally, do not buy Asana to solve a prioritisation problem. If leadership has not decided what matters, a portfolio view will render the indecision in a nicer typeface and change nothing else.
Goals and portfolios that compute progress from projects instead of from a manually-prepared slide. This is the purchase justification in most organisations, and it only holds if the underlying projects are genuinely maintained by the people doing the work.
Launches, campaigns and programmes where marketing, operations, legal and product each own a piece with dependencies between them. Consistent project structure across functions is what makes the handoffs legible, and it is the thing ad-hoc boards lose first.
The rollout tactic that determines whether adoption survives. Teams maintain the record because doing so removes an obligation they already resent; if nothing is removed in exchange, the data goes stale and the reporting above it becomes fiction.
Seeing who is committed to what across several projects before adding another one. The value is in the argument it enables with a stakeholder, not in the chart itself, and it depends on estimates being entered with some consistency.
Forms that turn requests from the rest of the company into tasks with owners and required fields, so a design, legal or IT group stops being managed through direct messages. Modest, unglamorous, and often the part of the deployment people actually thank you for.
Asana offers Personal (free, up to 10 users, with basic features but no timelines, goals, or automations), Starter ($10.99/user/mo annually — timeline and Gantt views, unlimited automations, dashboards and forms), Advanced ($24.99/user/mo annually — goals, portfolios, workload and advanced integrations), and Enterprise tiers (custom). The structural point that decides most purchases: the capabilities Asana is actually bought for — goals, portfolios and workload — sit in the Advanced tier and above, so the Starter price is rarely the price a company reporting to an executive audience ends up paying. AI capabilities are distributed across tiers with usage allowances that Asana has revised more than once, so check the current plan comparison before assuming a given AI feature is included at your level.
It depends entirely on whether those teams will maintain their work in Asana as the primary record. If they will, the roll-up above it is genuinely valuable and hard to get any other way. If they will not, you are buying a second system that someone updates for reporting purposes, and a derived number computed from stale data is more dangerous than no number at all.
Most organisations buying Asana for the reason they think they are buying it need goals, portfolios and workload, which sit above the entry tier. If the entry tier looks sufficient on paper, it is worth checking whether what you actually wanted was a lighter tool — a team that only needs projects and tasks is not yet the customer Asana is designed for.
It can be made to work and it rarely survives. Engineers reject it for concrete reasons: no tight loop with branches and reviews, heavier filing than the volume of small items justifies, and a cadence model that does not match continuous shipping. The arrangement that holds in practice is engineering keeping its own tracker while the initiative-level record the rest of the company reads lives in Asana.
Almost always the same way: it is introduced as a visibility requirement from above without removing any existing obligation below. Adoption spikes, decays over a couple of months, and the portfolio view becomes stale enough that leadership stops trusting it. Successful rollouts trade something away — a status meeting, a weekly report, a recurring update request — and make the trade visible to the people being asked to change.
Full review coming soon.