This condition is perhaps necessary, but of course not sufficient…
Or you may find such rough edges in your own private/individual testing and immediately move on to the 10+ other tools on your list that can meet such use cases. Unless your tool clearly meets some particular use case the best, you will be easily dismissed in this crowded market. You know this, I’m just saying the outcome where they send you feedback instead of just moving on to other tools is the best case, and the least likely IMO.
I’m obviously biased here (at least I do have a small paying team using Fibery for some years though 
), but I think it’s worth pointing out that this simple binary is in my experience not actually how things always - or even often? - work. Fibery is trying to enter/compete in multiple extremely crowded markets. There are few-if-any markets/use-cases that Fibery aims toward where it meets needs obviously better than any existing tool. Generally Fibery rises above the other tools when it comes to its interconnected data model, flexibility, and thus ability to meet multiple use cases in one place.
Anyway, my point is that a straightforward approach of “let us check of all the boxes for what this use case needs” is unlikely to succeed on its own. The market is too crowded. So how else do you try to gain some traction here? Well, one potentially very viable avenue is actually to appeal to individuals first (or at least not dismiss their needs as a use case you don’t care about). Why can this work? There are several big reasons, in fact.
First, the requirements for adoption of individual tools are generally far lower, i.e. if a user tries something and likes it, they don’t have to convince their boss, or their boss’s boss, or the IT dept, etc., they just start using it. Especially if it’s free (Fibery, Notion). Second, if a user adopts a flexible tool like Fibery for one thing, they are likely to discover more things it can be used for. When a need for one of those things comes up at their job, they will probably recommend this tool they now like and are familiar with. This was a big part of Notion’s success, people using it personally, then suggesting it for use in business. Third, since they are already experienced with this tool, they can help their company with adoption, workarounds of issues, configuration, etc. They become an internal ambassador for the tool. Obviously this is not the only or necessarily best way, but it should not be dismissed so readily as I think you seem to do here.
It’s also important to point out that I totally understand the individual use case would be of no direct/immediate value to Fibery ($0/MRR), and is not an intentional part of the long-term strategy. This is what makes it a classic “wedge” though. It’s not what your product is intended for or wants to focus on, but it’s easy to support it (you have already taken a step toward that with $0 for individuals), and can drive adoption. For me personally, I am hoping that the experience I gain in implementing an in-depth Fibery workspace for my personal needs (task + projects, lots of info/databases, and “quantified self” type of stuff) will better prepare me to be a Fibery Partner one day.
I don’t want to just be argumentative, but I do want Fibery to succeed, and I do want your thinking to be clear around how to make that happen. So I have to ask: how have you accounted for selection bias with literally all of your evidence/data here? What I mean by that is you are mostly only drawing this data from people who already use, or already seriously considered Fibery as it is. And as I said already further up the thread: talking to the people already adopting or who already use your tool is not as important (IMHO) as understanding the (many, many more) people who did not choose your product.
Obviously getting meaningful feedback/data from non-adopters is harder, but that does not mean you should then believe strongly in the extremely limited data set you do have to go on. When work or dev management apps like Monday and Asana and Jira have millions of users between them, your couple-thousand-user sample size (at best; realistically I think more like couple hundred who actually give feedback via Intercom + forum + email) is simply not statistically significant to derive market needs. Do you disagree? If so, can you describe why, or how you account for these issues?
I will try to do so!
This is interesting because it aligns with my initial reaction/instinct when I read about the hiring use case Michael outlined. My basic thought was: the unsolved needs there are more or less just relatively minor conveniences of integration, and arguably do not save that much time/energy, especially vs. the power and familiarity of existing tools like email apps. I can just imagine what it might be like to try to email through Fibery vs. using Gmail: it’s probably not a good sign that I viscerally expect it to feel clunky. 
Especially vs. my high degree of familiarity and comfort with Gmail (for others, replace “Gmail” with Superhuman or whatever email program they love and have been using for years). In other words if you add email, just ticking the “now we can email” box is not necessarily going to be good enough to make most people care. Automated email, e.g. “You have not been selected for this job” would be nice, to be sure, but anything beyond that and I’m skeptical…
To me email integration could be nice, Calendly would be too, but the basic root of the hiring problem is a simple data management issue, which Fibery is already good at. Not only that but many companies do hiring with existing companies/systems for matching candidates with offers, which often do not allow using some custom form view. So the initial outline of needs for hiring looks like a fairly narrow view of the problem space IMO. If this is a real focus of Fibery team, I’m a bit concerned. Fortunately form view has lots of other uses (network prioritization FTW!), and email does as well to some reasonable degree…
Interestingly this is a huge example of an arguably important feature for hiring management that went entirely unspoken-to in Michael’s initial list of needed features. And I think it just further reinforces that it was a narrow view of the problem/feature set for that use case. But I agree the discussion/decision-making functions are quite important: discussing, rating, and deciding which candidates to hire is the real “meat” of the thing, and the thing not well solved by Email (or form view, etc.), or necessarily any other tool. I.e. that seems like the more significant opportunity here for Fibery to differentiate and stand out: a superior way of discussing a thing and coming to a consensus around it, using comments, reactions, voting, etc. Interestingly this is A: what Fibery has already talked about for feedback management and work planning in other contexts (i.e. it is in the Fibery long game), and B: like some of the other big features (forms, email) it too has many important use cases that it serves.