Seven reasons why Asana never made a cut with us

 Last Updated: August 19, 2016

 August 19, 2016


You must have heard about the task management tool called Asana, making waves recently.

Let me take this chance to congratulate makers of Asana. They did built a great tool - basically creating a comment thread out of rows of an excel. No wonder they have raised around $100 MM so far from last 8 years

I was a power user of Asana too, till recently. I also implemented Asana in a 100 user team where I used to work.

Initially, the results were awesome. We drastically reduced the number of daily emails exchanged, phonecalls made and meetings needed. We were able to smoothen execution in our team spread across different locations and were also able to keep everyone on the same page all the time.

But only for the first 1-2 months.

After the second month, usage started diminishing unbelievably. At the end of fourth month, everyone got back to email and all we had to do was take a call between using Email and Asana. Most guys voted in favor of the former - a worthy tradeoff in exchange for one lesser tool to manage. 

Let me take you through the exhaustive list of reasons why exactly this happened:

1. Leadership support

I was in middle management and was the driving force behind Asana implementation. I believe that had it been driven from top management instead, the implementation would had been far more successful. 

Top management totally continued on emails. Once they started a discussion on email, everybody got on emails and anything out of emails got sidelined. 

As for Asana (or any other collaboration tool), it runs on network effects. A bulk of people start communicating on it, while others start getting FOMO (fear of missing out) and they hop on to it too. 

So the same network effect which drove people to Asana initially, was sadly driving people back to email later, due to the resistance of top management to change. 

2. Champion a must

I drove Asana implementation, trained different teams to use it. Within first 15 days of initial implementation, I got all these teams onboarded  - Database, Backend, Front-end, CMS, Quality, Product, Design, Adtech, AdOps, IT Support, Server Admin, Marketing, MIS. So I was the so-called 'Champion' behind it. 

The dependency of Asana on champion is a strong starter for it, but it also eventually got to be a deal-breaker in our case.

So once I went on a bi-weekly vacation, only to come back and find everyone back to emails. 

3. Integration with Email

Asana has done a lot on this front.

An email gets fired as notification for each activity. A reply to that email gets posted as a comment. You also have email IDs which create a task whenever an email is sent to them - one for each project - and there is a lot more to it. 

But frankly, all this does not work while communicating with a client or a vendor who does not use the tool (which happens, alas, most of the time). This was the case with all teams communicating externally especially the sales, alliances and product teams. 

Secondly, everybody has a natural tendency to say, by birth, "Mail me" or "Will you send me an email". In this scenario, emails never cease to exist - even internally. So even if one guy sends a single email, a thread gets created around it. Sometimes, two parallel threads got created - one on Asana and the other on Email.

Further, here's a fact:

all people care is that the message reaches the other person, whatever means may be

All the above always meant managing two different heaps - Emails and Asana.

4. Demerit of Existing Email Integration

So when a user gets an email notification from Asana, the user might reply to that email as well. This reply will get posted as a comment in Asana. But a user might do this repeatedly as for all issues, corresponding email threads get created for this user.

Some would call this a feature that you are collaborating on Asana by not opening Asana's web app. But in our case, this proved to be a setback.

This gradually kept people from getting inside the tool and people just became too comfortable in replying to emails from Asana (!). 

Integration of your product with other / existing apps might also sometimes drive users out of your own app.

Slowly all conversation inside an Asana task had comments which turned out to be posted from email replies rather than users actually commenting from Asana's interface - a proof of diminishing actual product's usage. 

5. Everything has to be a task

In Asana, by default, everything has to be a task.

Yes, it does have this 'conversations' feature but that did not help, especially in our team. As most conversations (discussions) got created by top management and on emails, only the execution part went into Asana to become a task. 

6. Steep Learning Curve

Asana has lots of use cases. In fact, everything that can be done on an excel, can be transferred to Asana.  In my team, I being the champion, kept on striving to drive home the point of Asana being an excel sheet. This got everyone instantly comprehend what it exactly is. But the problem is this USP is missing in all their tutorials, guides and manuals. Relating Asana with an Excel can go a long way in proving the product's worth.

In our team, we created a project called 'Backlog' and all items lined up for execution were placed into Backlog, in the order of priority. So we set up the process wherein a task got created and the assignee of that task kept changing as the task moved forward - akin to an assembly line process of car manufacturing. So product team initiated the task, which is then assigned in this order: Product -> Design -> Product -> Engineering -> Quality -> Product. In the whole process, if userA needed something from userB, she had to assign the task to userB (mostly) or mention userB into the thread (if assignee could not be changed due to some reason).

The above process actually worked. But it was like effecting a complete change in existing user behaviour.

Some users frequently forgot adding users to followers (when they needed them in cc). Some forgot to attach projects. Some forgot that assignee is to be changed. Training users on all these points was a lot of work not just for me, but also for other middle managers.

7. Due Dates

Due dates is a great feature, if used correctly. In an agile environment, due dates expire frequently and it requires a conscious and collective effort to maintain them.

In our case, most due dates used to be in red, which made everything look stale and unmaintained. 


a cool lining


What do you think about Asana? Do let us know about your experience in comments below. 

←  Back to All Blogs   |   OR   |  Share this post:    Twitter Share  Facebook Share  LinkedIn Share
←  Back to All Blogs


Share this post:    Twitter Share  Facebook Share  LinkedIn Share

Ready to transform your life?


©2016. Comtify
Go to Top
Go to Top
Built with in India