@BruceGosk and @Lucas1 - thank you for the thoughtful dialogue! Whether or not we share the same perspectives, I really appreciate a substantive discussion.
@BruceGosk, you’ve made some good points—several of which I respectfully disagree with. Into the weeds we go!
(Everyone else, feel free to scroll right past this mini novel! 
)
re: increased costs on top of base subscription
This applies to essentially every platform, and there is a shortage of developers globally.
The first part is just not the case. Of all SaaS platforms I’ve sourced/deployed/administrated—Monday is one of the worst in terms of this charge-for-everything piecewise approach. It feels like the first question Monday asks internally when a new feature is under development is “how much extra can we get people to pay for this?” Meanwhile, plenty of other platforms take a higher-level approach to dividing new features between their subscription offerings—assessing their value proposition more holistically and with more consideration of the big-picture implications of those decisions.
The second part of your assertion isn’t categorically false, but it is an oversimplification of a complex situation. The talent pool is vast—the crux of the issue is that so many companies fail to look for it in the right places and/or fail to offer sufficient compensation and a good enough employee experience (+company culture) to attract and retain the talent. The overwhelming majority of dev roles are given to white men (one recent study found that 62% of all IT workers are white and 75% are male.) That is NOT because all the talent is concentrated in those communities! Here’s a Forbes article that makes a good start at exploring some of the root causes of the mismatch between open roles and available talent. There’s much more to say on this topic (including w/r/t burgeoning AI capabilities), but I’ll leave it there for now.
re: security / data compliance
This is part of ITs role, and applies to every platform. monday are excellent at stipulating the security terms and permissions related to apps.
Yes, it is part of IT’s role, which is precisely why IT has to disallow so many platforms/apps that aren’t up to snuff. IT can’t FIX the security vulnerabilities for the devs; they can only assess them, provide feedback, and [often] ultimately disappoint their end users by being forced to take otherwise-appealing solutions off of the table.
And Monday is decent when it comes to identifying what kinds of data are shared with the app publishers—but the publishers themselves often fail to provide adequate public-facing information about how THEY process and store that data once they’ve received it from Monday.
re: misleading sales tactics
This is bad practice! I would give feedback if you hear of it happening directly to the monday Sales Team Member when they do this as I don’t think their Managers would be impressed at all.
It is definitely bad practice, and we have provided feedback about it more than once. In my experience since, there have been no noticeable improvements. As I said previously, Monday’s sales tactics feel shady at best—I have more specifics, but rather than getting into the mudslinging weeds, I’ll just say I hope you’re right that their managers generally care about that sort of feedback enough to do something about it.
re: implementing platform improvements offered by third party devs natively
They often are doing this, which puts massive risk on app developers as it can cost tens of thousands of dollars to build an app, which can be replicated by the monday Team with zero notice.
You’re right, but:
A) There IS an honorable way to do it: Monday could offer to buy the tech they want to bake in from those third-party devs
B) That’s how the world of technology works—and in the end, that’s in the best interest of the end users.
re: my warning to prospective customers
It is still one of the most economical platforms you will find on the market, and users love it which by far is the most important metric for any software as it means that they use it religiously (look at its G2 ranking, and other awards).
I disagree with this too, but it’s not easy to illustrate quantitatively either way. It very much depends on an organization’s specific functionality needs and how many of them can met natively by Monday vs. another platform.
And for organizations implementing their first work management platform (coming from having no purpose-built solution), yes, it’s a huge improvement, and I can understand being happy with it! But when you have other points of comparison and a solid understanding of what should be possible in such a tool, the Monday experience tends to result in a long series of disappointments. (It’s all relative, as they say.)
re: inability to have multiple layers of subitems
monday would need to develop automations for subitems of subitems as users would expect this immediately, which may be very difficult and costly at this time given that it has taken years to get subitem automations to the current stage. Defending the pricing of the Unlimited Subitems app - it costs less than $2 a month per user, and has an unlimited plan for 400+ users.
Yes, they would. If subitem objects were built comparably to item objects on the backend, this wouldn’t be an issue, and it would be no harder to apply automation functionality to sub-subitems than to sub-items or to regular items. Again, see Asana; there is no meaningful difference between the automation capabilities available for subtasks and those available for parent tasks.
And I’m glad you brought up the license costs of that third-party app, because this is a problem I’ve seen with countless apps in the marketplace: there is no way to pay for the number of licenses your org actually NEEDS (e.g., the 8 power users in the org with a legitimate use case)—instead, you’re forced to pay for licenses for all users in the Monday account. Even if 90% of them have no interest in or need for that app. At this very moment, I’m supporting an org with 250 Monday licenses and a much smaller subset of power users looking for more. If we could pay for, say, 5 app licenses that we could distribute among end users as needed, it’d be a much more viable option.
re: multi-homed items
The issue with this is you are duplicating data across the system. Duplicates cause costly issues especially at Enterprise Scale […]
That’s only because of the way Monday set things up on the backend. They didn’t have to build it that way! In a standard relational database, a single object can be displayed and interacted with in multiple contexts without that object’s data ever needing to be duplicated.
re: unsupported field types in automations
Similar problem here with automations and how long it would take. I imagine that these are quite difficult (if not impossible) to code.
With a couple of specific exceptions (like mirror columns) I disagree with that claim too. Most of the columns I listed store the same fundamental type of data. But without more direct access to the code, I can’t prove it.
That being said, I’d like to point out that a couple of column types that are NOT supported according to the current documentation DO actually appear and work in automation recipes. So the mechanisms for automating those columns are already there and working—they’re just restricting it for some reason (and, thankfully, doing a poor job of applying that restriction.)
re: task assignment requiring board access
Viewing permissions + Editing Permissions + locking a view requires Enterprise edition, which means they will only be able to see their items assigned to them in the people column, and won’t be able to edit that view. You can restrict column permissions to view only and edit only as needed.
A) Yes, as you said, those features are exclusive to Enterprise plans, which are prohibitively expensive for many orgs. Should they really just be SOL?
B) You can’t restrict the item name column (or prevent visibility of updates on the item). That right there would foil plenty of HR-related use cases. Think of an HR specialist’s to do list containing things like “Discuss performance issues” / “Establish performance improvement plan” / “Set up meeting with manager to discuss attendance issues” / etc. It’d still be helpful for the HR person to be able to relate those items to actual employees in a People column, but for obvious reasons, those employees should not have any visibility into the item or board. Or what about IT requests? It is extremely common for IT employees to need to have INTERNAL conversations about an employee’s ticket, separate from any public replies to the requester. You can’t have a private Updates conversation if the requester is in a People field.
(Also, locking a View prevents others from messing with the configuration of that View, but it does nothing to prevent visibility into all of the other Views, including the Main Table.)
re: inability to assign a subitem without assignee seeing its parent
Interested to hear more about why the user shouldn’t know the Parent Task? I personally would always want to know for its relationship, or to give Context.
There are some business processes that involve multiple stakeholders who should not all be privy to all of the context. As one example, a hiring/recruiting process where some employees collaborate on a job description for a role, then legal and finance review it for compliance and to establish a salary. Finance often doesn’t consider it appropriate for all of the employees involved in the process to have visibility into that.
re: all People fields being treated as item Assignees
Each User can customise the My Work section to remove a certain board. How do you think it should be improved further?
I concur with Lucas’s response. Also, while you can remove an entire board’s items from My Work, you cannot distinguish between People fields within a board. E.g., if Board X has one Assignee column and one Requester column, Employee Y DOES need to see items where they’re the Assignee in My Work (because they need to DO something) but NOT items where they’re just in the Requester column (because no action is required of them.)
re: templatizing items/subitems with preconfigured dependencies
I believe this is already possible when you save a board template.
I think we are interpreting the ask differently, because I don’t believe what I’m thinking of is possible in board template either. But even assuming I’m wrong about that, there are lots of contexts where users don’t want to create a whole new board for each instance of a standard process—they want an item for each instance, all on the same board, with standardized subitems that are interdependent.
re: inability to edit templates once they’re added to the library
You can add it to your workspace, then save your own customised version of the template as long as you promote yourself to board owner?
First, a clarification: I’m not talking about wanting to customize someone else’s template—I’m talking about the fact that if I publish a template, and then later I want to make an update to that template, I cannot do so. I have to delete it and save a new one with the changes implemented. I know the mid-rollout parent template feature addresses this, but we’re stuck as it is with standard templates.
But regardless, the method you’re describing is untenable for organizations that want to keep their template library tidy, easy to navigate, content-audited and up to date.
re: updating parent item’s status when specific subitems completed
What happens when you add more subitems, or change their order for example.
The same thing that needs to happen pretty much any time a standard process needs to be updated: automation maintenance and communication.
And the subitems don’t have to be specified by their index number—for instance, they could be specified with [“subitem name contains {keyword}”] conditions, which would make it agnostic to the order of the subitems.
re: inconsistent filter conditions in automation/integration recipes
monday Workflows is adding integrations. Slack, Gmail, and Outlook are already available
I agree that the Monday Workflows feature is a big step forward, and it’ll only continue to improve over time! The first issue is that, again, this feature is only available to the most expensive subscription tier, leaving smaller orgs out to dry.
Another is that, as I said above, automation recipes do still actually allow you to work with a couple of unsupported column types, while Workflows align with the documentation, and give no option to interact with those unsupported fields. At least one org I’ve supported is forced to use automations rather than workflows because they have an unavoidable need to map dropdown columns into automation-created items. And they can for some reason, despite what the documentation says, actually do that in automations. (Incidentally, the number of discrepancies I’ve found between the way the product actually works and the way its published documentation claims it works is another gripe I have with Monday.)
Conclusion
I am very aware of how irritating it is when customers with no concept of how a feature actually works express with great confidence that making whatever change they’re requesting must be “easy”. With most of these limitations, I’m NOT claiming that fixing them would be easy—but I AM claiming that it’s doable (as evidenced by the fact that several competing platforms already offer these features) and that it’s worth doing.
The numerous popular feature request threads that have been sitting there gathering upvotes and dust for several years aren’t a good look. And while there are undoubtedly countless factors at play for why they’ve been left unaddressed, the end result creates the perception that Monday just doesn’t care about improving the experience for existing customers; they care about attracting new ones, knowing that the overhead associated with switching platforms post-adoption will prevent many of them from leaving even if they’re dissatisfied.
