🩄 If Wishes Were Unicorns: Why Asana Might Not Have Implemented that Feature Request (and other thoughts about Asana feature development and product strategy)

English Forum Tips and Tricks Forum Leaders tips
1

Co-authors: @Phil_Seeman @lpb @Bastien_Siebman

We all love Asana but at times we feel frustrated about some limitations or features not being released, or we wish there was more information forthcoming.

We are three seasoned Asana consultants and software developers; together, we have over 90 (that’s not a typo!) years of software development experience and over 30 combined years working with Asana.

Here are a few things we hear repeatedly on the forum and we thought it might be useful to share some of our knowledge and experience on these topics.

Disclaimer: We do not work for Asana; these are our personal opinions.

“We have been asking for this feature for years; why isn’t it available?” or
‘How many votes does it take for a feature to be implemented?”

The forum is just one place where the Asana Product team looks for feedback. They also talk to customers, do focus groups, talk to their Account Executives (AEs) and Customer Success Managers (CSMs), gather tickets from support, consult with Partners, and more. They mix all of those signals with their core beliefs, the existing roadmap, and their analysis of the market and the competition. Once they have a clear list of where they want to go, they look at budget, deadlines, and resources. What makes the cut is a small subset of all of the potential enhancements. Rinse and repeat, every quarter. Alex Hood, Chief Product Officer at Asana, explains it in a forum post.

“Why isn’t Asana answering on the forum regarding this request?”

Asana follows a policy of updating topics only when there’s new information to impart (it would be very time-consuming to do otherwise). Often, though, if you look back in a topic thread you will find an earlier answer from a member of the Asana Forum team.

Also, Asana, like many competitors, does not share their roadmap publicly. They do share their long term vision through inspirational videos, and the short term roadmap through announcements of upcoming features that have been developed. But nothing in between. The reason is simple: as soon as you announce something, it becomes a commitment that people then expect. Users often don’t understand that priorities may need to be shifted, resources could be suddenly limited, a new opportunity might present itself, etc., and the initial roadmap has to evolve. So Asana chooses not to risk setting possibly false expectations. We know for a fact they do check the forum frequently, and they do re-visit topics often.

“This is easy; you can literally release this feature in an hour”

Asana is an app used by literally millions of users, at virtually every kind of for profit and nonprofit organization, in virtually any department, in almost any industry, across different languages and timezones, working on different browsers as well as mobile and desktop platforms and versions, and with engagements on SLAs. In this environment nothing is easy.

Here is a simplified list of the typical steps required to go from an idea (a very simple new action in the rule editor, for example) to a feature deployed in production:

  1. describe the feature
  2. evaluate the cost
  3. place in the roadmap
  4. describe the behavior, anticipate edge cases
  5. consult/coordinate with other teams that might be affected by the feature
  6. design the user interface (UI)
  7. code
  8. write and run unit tests
  9. review code and unit tests; fix issues and repeat steps 10 and 11 as needed
  10. localize
  11. deploy
  12. update help and training documentation in all languages
  13. inform the CSM and support

A rough estimate? This feature alone easily costs $50k and takes at least 50 hours of work. We are not kidding you.

Also, in many cases steps 4 to 14 will also need to be done for the mobile apps and desktop apps as well, which each have their own deployment processes. Additionally, the API is also often impacted and must be updated, and external developers given ample advance notice of changes.

“Simply add an option to choose if we want this feature or not, and let users decide”

Software companies adopt differing philosophies regarding adding lots of user-customizable options. It seems clear that Asana has chosen a philosophy of “less rather than more” when it comes to adding options.

We think the reasons are pretty clear. Any new option added to a feature typically means:

  1. added complexity to the codebase
  2. tests running longer
  3. heavier documentation
  4. more questions to Support
  5. added complexity to add other features around it
  6. more confusing usage, steeper adoption curve

We recently read a post about Evernote. Apparently that’s what happened to them: they kept adding what people wanted, to a point where they had to reship an entire new user interface that was simpler because the users were struggling with the old one.

“Why is Asana adding emojis when there are missing triggers in rules?”

Asana has a Product Manager (PM) for Rules, a PM for Onboarding, a PM for Tasks and Subtasks, etc., and developers themselves have specialties like frontend, backend, performance, infrastructure
 You can’t have anyone work on anything - people and teams have a defined scope. That’s the reason why sometimes you see surprising new features while a large update has been delayed. There are many other potential reasons, too, like years of small features leading up to a major change that we don’t know about until the end.

“Monday has it!”

Asana’s goal is not to beat the competition by copying what they are doing, but instead by having a clear vision and philosophy, and making sure the tool is easy to use, while being powerful and scalable. Some of the features requested on the forum will never make their way into the product. Asana won’t do everything you need. It shouldn’t, or else it will become this very complex tool, getting slower every day and that no one wants to use anymore. Microsoft Project, for example, is amazing for hard-core project managers - but few others want to use it. Asana can be a pain for hard-core project managers, but 98% of the company is getting benefit from it.

“Why did they release a half-baked broken feature?”

If you are familiar with the lean startup movement, this is about implementing a feedback loop. You release something simple, you get feedback, you improve it, ship again, get feedback, improve
 The other alternative is usually to spend a long time studying what people want, then spend a long time coding it, then shipping it - only to realize this is not really what people said, or not really what they want anymore. We believe Asana picked the lean approach. When they release a feature, it covers a small part of a bigger use case. Then they often do a fast-follow to fix or improve a few things. Then they wait and gather feedback. Sadly, they don’t always come back to the feature, but often they do, perhaps a few months later. You don’t have to use the new feature right away. For some features and specific plans, you can even hide those new features from everyone.

One thing we want to note: we might be hard-core Asana fans, but we don’t agree with everything. For example, we wish they would communicate more about the roadmap (which they are slowly doing). We wish they would polish some of the older features instead of releasing shiny new features. But we are thrilled with our choice of Asana as a platform and as our work focus. We have the pleasure of talking with Asana PMs quite often, and we can tell you they are very dedicated, very thorough and good at their job! Many consider the Asana designers world class. And Asana engineers have delivered updates and new features at unprecedented velocity in a complex environment and with a minimum of performance issues or bugs.

We hope some of you find this information helpful. We encourage anyone with similar relevant experience share their point of view below!

29 Likes
2

I think this article should be read by anyone creating a new Product Feedback :unicorn:

Well done @Phil_Seeman @lpb @Bastien_Siebman :wink:

4 Likes
3

We can also reference it in our answers :slight_smile:

2 Likes
4

I appreciate the insights shared in this post, but I find myself both agreeing and disagreeing with certain points. The tone feels slightly defensive on Asana’s side, as if to say, “Stop asking for things; we know what we’re doing.” While I understand the complexities involved in software development, the way this is communicated can come off as a bit dismissive.

Asana, being a platform that encourages and facilitates communication, should also be open and transparent in its own communication. It raises questions as to why three dedicated non-Asana employees feel the need to fill in these communication gaps. It seems like Asana could benefit from being more responsive and engaging with its user base, especially on its own forums.

I agree that Asana is a tool used by many, and not every feature request can or should be implemented. However, my perception is that Asana is somewhat out of touch with cultures outside the United States. The principles and work styles can vary significantly around the world, and it sometimes feels like Asana isn’t fully attuned to these differences (Date formats :rofl:)

Despite these criticisms, I want to stress that I love Asana. I use it daily for both work and personal tasks. Like the authors of this post, I don’t always agree with the choices Asana makes, such as prioritizing AI features when more basic improvements might be needed. But this doesn’t diminish my appreciation for the platform overall.

Asana should be thrilled to have such an active community and dedicated ambassadors who engage so deeply with the tool. My deepest respect goes to the authors of this post—they are the true heroes of the forum, offering valuable insights and bridging the gap between Asana and its users.

13 Likes
5

Forum Leaders like us do feel valued by Asana and they show us often. Everybody help helping on the forum deserves a praise.

Asana being a publicly traded company, and us being independent consultants, we felt like we could say things Asana would never say even if they wanted to.

We spend a considerable amount of time on the forum helping any way we can. When a feature is not available, we spend a ton of energy trying to find workarounds for the community. More and more, we get “attacked” or “criticized” for doing so, and forum members are often confused with Asana employees. I thought it was important to clarify that complaining on the forum has little to no impact, especially when the people helping can’t do anything. Upvoting and calmly explaining your use case is what makes a difference.

We also thought that it was a good opportunity to share some of our knowledge of how a product is being built, as most people don’t really understand what’s going on behind the scenes.

6 Likes
6

Understood. Just to be clear, that wasn’t our intention in writing this. It was more (speaking for myself) wanting a way to resolve some of the frustration I feel when reading in the forum “We’ve been asking for years, why isn’t this done??” and “This would only take an afternoon to implement!”.

3 Likes
7

Thanks for such a thoughtful post!! We love Asana and love getting to see it grow. There is no perfect software out there :heart_hands:

3 Likes
8

Thank you. This post makes really good sense. Also for other products I use. Simplicity is especially very important. Another important thing to consider, is consistency. I worked for a company that makes an ERP system. I found 15 different ways of filtering dates. That was too much, and they did listen and changed it to less.

2 Likes
9

Amen!! :100:

1 Like
10

@lpb @Phil_Seeman should we include the “this is a basic feature” remark as well? see How to set task Public by default - #10 by Morgan_Marshall

11

Overall, this post seems to be in pretty poor taste. The full saying that the title alludes to is “If wishes were horses, beggars would ride”, but the people complaining about the lack of updates aren’t beggars: they are paying customers.

Those comments themselves come from user frustration. My team has been using Asana for about five years now, and the only somewhat significant update I can think of was the addition of “Markdown shortcuts”, but even that was extremely lackluster. It was hyped up as being markdown support, and turned out to be far less than that. People immediately asked for real markdown support, and were told it’ll be improved, and then the post was locked. Here we are 4 years later and the “markdown” support is the same broken mess it was on launch day in September 2020.

Also, as someone who also has about 30 years of professional software development experience, the explanation of prioritization in the software development process seems very patronizing. Telling me they can’t work on some things because there are higher priorities doesn’t really follow when there have been virtually no improvements for years. I can only assume that whatever they’re working on over there only impacts the highest-priced tiers.

I’d suggest that if you are frustrated by comments asking about features people have been asking about for years, then instead of directing your frustration back at the customers, who are themselves frustrated by Asana, you should direct it back at Asana. If their product managers were doing a good job of prioritization, then there wouldn’t be so much frustration evident in the forums. Merely wishing customers weren’t so frustrated won’t do anything: Asana needs to make some progress on the things their customers have been asking for.

7 Likes
12

I agree. Even though the post lays out plenty of excuses, it seems to miss the point that the complaints are very real experiences that Asana creates for its customers.

The reason a customer might say something like

“We have been asking for this feature for years; why isn’t it available?”
“How many votes does it take for a feature to be implemented?”
“Why is Asana adding emojis when there are missing triggers in rules?”
“Monday has it!”
“Why did they release a half-baked broken feature?”


is because these are very valid questions to ask when the assumption is that the company has the customers’ needs in mind.
It shouldn’t need to be said that these are completely reasonable requests, so much so that they shouldn’t even need to be stated, let alone exclaimed in helpless frustration.
Half-broken features, ignoring highly voted feature requests, prioritizing frivolous features so they can appear productive? Come on.

Ultimately there’s a poor customer experience happening at the root of these “wishes”, and these are just excuses because someone doesn’t want to admit the true values driving the outcomes.

I’ll clarify that I appreciate the tool itself, but I’m way too sympathetic to the spirit of these “wishes” to accept these defensive excuses.

8 Likes