🗺 Public roadmap: how does Asana compare with its competitors?

[Bastien_Siebman]

Hi,

Being a forum leader, I see very often the same argument when it comes to features “Asana does not share a public roadmap? That is absolutely ludicrous, everyone else is doing it!”. I wanted to check, once and for all, if that was the case or not. I was helped by @Jerod_Hillard and @Phil_Seeman to put together this list.

Note: this post is not meant to discuss whether or not Asana should share a public roadmap.

Wrike
In September 2020, they said The public product roadmap isn’t available and the team doesn’t have plans to introduce it

Smartsheet
No public roadmap available.

Basecamp
In September 2020, they said “There is no official list of what we’re doing next anywhere in the company”.

Trello
We could not find any public roadmap, we did find an old Trello board that looks like a roadmap. They do explain how to treat the feature requests though.

Airtable
Online, they say Aside from occasionally putting upcoming features into a public/private beta, the Airtable devs have not yet published a feature roadmap.

Monday
They only provide their roadmap if you sign their NDA.

ClickUp
They have a public roadmap available.

[Cole_Atkinson]

Customers are always right about the problems they have. Customers are rarely right about the best way to solve those problems. A public roadmap or forum of feature requests is a sure fire way for a cloud company to become a dinosaur piece of software. Much better for customers to express their problems, not the features they want, in a public community like this. Long term, it is better for the customer and the vendor.

[Gerhard]

I tend to agree with you, Cole. I work in the automotive industry and your comment reminded me of Henry Ford’s quote “if I had asked my customers what they wanted, they would have said a faster horse”

[IvanStaykov]

Very nicely put, made me think, thank you for that.
A public timeline does not go against what you say.

I will give an example - G Suite has a public timeline which is just top-level, so no details, but major things they are doing. No time commitment, only major stages.
Recently we defined a need to organize our files in a specific way that G Suite did not have the feature for. Looking at the timeline we saw they are working on this feature, so we saved the workload to implement a workaround and waited for the feature. So for me a public feature timeline is not a problem solving solution, but a workload management solution helping us where we need to focus on and where we can rely on Asana or anyone else to help.

For example - currently we are making our product marketing plan. Each product is a task and is evaluated on many parameters, so it is homed in three projects each with 20 custom fields. If Asana plans to introduce a multiplechoice custom field I will home only the ones I really need to plan for and will wait for the custom field for the rest. If not I will need to home all products like this. Currenly this is hidden for me. So for all similar points I constantly need to decide - should I invest in the workaroung ($ for Zapier, time for my team, etc.) or should I wait

[Phil_Seeman]

@IvanStaykov,

The issue with a public roadmap is that sometimes technical reasons cause a necessary change in plans, and that can upset customers and their plans even more than not knowing.

In your example, let’s say Asana came out and said “we’re implementing multiple-choice custom fields”; as a result you implemented a whole system based on that info; then after you did, they came out and said, “oh sorry, due to technical reasons we have to change our plans and cancel that feature indefinitely”. You would NOT be a happy camper: “But you said and we planned based on that; you can’t go back on your word now, Asana!!”

[Bastien_Siebman]

Great discussion here, thanks everyone I tend to have the same position as @Cole_Atkinson but this is not a common stance!

[Cole_Atkinson]

Yes exactly. Public roadmaps are the bane of every product teams existence Even if you get a public roadmap, it’s not something that you can hold the company to account for; at best it is a guide to areas of investment but not a guarantee of features. We reserve the right to change our roadmap based on the best information we have at the time. This is in the best interest of our platform and our customers. The information you have in 6 months time may be different to the information you have today, meaning that what you decide to build today is not the best thing to build in 6 months. If you commit to building something based on wrong information, just because you said you were going to do it… you’re in trouble.

[Cameron_Stahl]

I don’t think a roadmap for individual features is particularly useful, frankly, for a software with as many applications and workflows as this. I think a better strategy would be to actually learn about the existing userbase and see if any unmet needs are shared among wide segments. It’s not at all uncommon to release a product aimed at one audience and find that a completely unforeseen audience has adopted it for a different purpose.

I’d love to see updates take a more thematic approach, for example, surveying users and finding that content managers make up “x” percentage of its userbase, and then finding out how they use Asana along with what features they would like to see added. For example, content managers have lamented the lack of adaptive scheduling and dependencies (which aren’t actually “dependent” in the same way they imply, and are still selectable for subtasks even though they have no effect), among other things. Instead of just adding yet another orphan feature, looking at the workflow of users and seeing how they can better connect the existing features seems like it would add more value with less effort.

The majority of my complaints about Asana do not stem from missing features, but from ones that either lack options other software has, or that don’t operate on their own logic beyond a very narrow scope of applications. The best analogy I can come up with for what I mean is this:

Imagine you need to lift a couch. You get a board and a paint can to act as a lever, and succeed in lifting the piece of furniture. That’s the feature working as intended. Now imagine you need to lift a bedframe, and try to use the board and paint can, but nothing happens because the developers haven’t configured “levers” for beds yet. That’s the kind of ‘orphan feature’ I’m referring to, which works in only one specific context/workflow despite being designed in a way suggesting broader usage.

Again, it seems like so much work to not apply a sort of ‘global logic’ to relevant features and workflows as compared to maintaining and updating all these more-or-less-standalone modules.