Well, certainly both. Without more data it’s hard to say what the “network value” of those customers would be vs. others. What I can say, though, is that there are a lot of e.g. dev tracking or project management tools that do not have form view, and yet are extremely successful. So clearly it is not “table stakes” in the sense that I am referring to here. It’s also obviously not a “foundational” or “basic” (core) feature/function in the same way that notifications are, much as some segment of the customer base might “require” it.
And all that may not really be the most important basis on which to choose priority between these (more on that in a moment).
That’s quite fair, it would be a long game there. It takes time for Fibery’s reputation and word of mouth to change in the community. Right now it has a reputation for being powerful but complicated. If tomorrow Fibery became “DALL-E 2 but for work management”, it’d still take a while to change that perception. 
And while more people will probably take a look at Fibery as they become aware that it now has a form view (once that’s released), they may still be stopped by the poor notifications, which are likely to be an important feature for more people than form view.
No, but perhaps they will be the reason some set of people stop using it (or never properly adopt it), and more importantly the reason that those people do not recommend it to their 10 friends (network effects), etc. It may be the missing “table stakes” that makes some meta-reviewer who is deciding what 5 products to compare in a “no code” round-up decide to leave Fibery out and put something else instead. In other words it may be a notable reason that Fibery fails to gain traction, which almost inevitably starts with impressing and passing the “basic tests” of some smaller set of potential users. If nothing else it gives a visceral impression of lack of polish and attention to “the basics” (even if that’s not a fair assessment).
For me it is not (happy to elaborate/have that discussion), and while I do consider chat massively important, it’s also a huge feature to implement (as we have recently discussed here in the forums). To me notifications are comparatively a “small” dev task, which I think is the other major reason that for me they should be prioritized over e.g. form view.
HereBeBeasties articulated this as well:
I.e. effort vs. benefit. Current Fibery notifications are not good, we can all agree. How much work would it be to improve notifications vs. implementing form view? I suspect the latter is a lot more work. I could be wrong. But I base that on the fact that, at least for me, notifications are bad in some major but seemingly easily correctable ways. Just implementing this short list would help massively (HereBeBeasties seems to have a different idea of what needs to be done):
- Make optional/configurable all the “boilerplate”/extra context parts of email and in-app notifications (e.g. “automations” [what triggered the notification] prefix, database name, etc)
- Make notifications more noticeable in the app, maybe even some kind of easily dismissable pop-up when they trigger or the user first visits when there are new notifications
- Make notifications deletable/dismissable in the app
Those few, simple things would for me be a huge improvement in usability, as simple as they are (or seem to me). They turn notifications from a mish-mosh graveyard dumping ground of “stuff” that I don’t want to look at (and thus is largely useless) into at least a reasonably useful place to understand what’s happening, what I maybe have to work on, etc.
There are probably a number of other relatively small tweaks I could suggest, like “bundling” of notifications into a single email/notification, e.g. “Good morning, these are the tasks due today!” (yes, you could do this with some automation work, but looping over a reference Collection is non-trivial, and this gets back to the “this is too much work for a basic, useful thing” issue). But you could start with a, what, 2 week sprint to take care of that list of 3? I could be way off in my time estimate, but hopefully not. Give it another 2-3 weeks to implement “watcher” and you’re in a pretty good place. And I can almost guarantee you a longer bug fixing and tweaking cycle on Form View vs. notification work.
But look, I don’t want to sound like a backseat-dev-managing a-hole here. I don’t know everything going on inside Fibery, and you have a great team. You guys do know what you’re doing. These are not easy choices to make, whether you’re “right” with a choice can take a long time to become clear, if it ever even does (often there are no “right” choices, just different outcomes that may not be clearly better than others). This is the choice I would make, and with everything I can see from the outside, and as a user, this appears to be an obvious focus for a ~30 day chunk of work soon. But there are 10s of reasons I could be wrong. 