There’s a great article called Death by a Thousand Buttons by Tobias, touching on something that comes up a lot in the Asana forum: people asking for new features simply because the community wants them.
The usual suggestion is: just put a button, just add a toggle, let us choose. This often happens when Asana takes a clear decision between two paths, and part of the users disagree. Rather than change course and upset the other side, the request becomes: why not offer both options?
But if you’ve built products before, especially SaaS, you know adding options isn’t always the right move. Take Zoom for example: have you ever been inside their settings? It’s wild. There are so many customizations that it’s overwhelming. You end up confused about why something behaves a certain way, because a hidden setting is off somewhere.
Asana, on the other hand, is praised for its simplicity, ease of use, and flat learning curve. Over the years, some tools have become more powerful but also far harder to learn, while Asana has tried to maintain that balance.
A good example: no multiple assignees on tasks. More than 10 years ago, Asana explained that this was about accountability. When multiple people are responsible, things tend not to get done. Many don’t like that decision, but we’ve also seen teams move from Monday to Asana precisely because they don’t want multiple assignees and the accountability issues that come with them.
Every new option brings complexity: more code to maintain, more documentation to write, more training to update. It also makes the tool harder for new users to adopt.
Sure, it gives consultants like me more work, but I’m not here to become a Salesforce consultant, building labyrinths of complexity. I’d rather build simple solutions to complex problems, not the other way around.
Bastien, Asana Expert
i.DO (Asana Partner: Services & Licenses)