Fair points and well articulated! As with many things of this type my approach would generally be to not bother trying to answer all those questions for everyone, but simply to answer them internally for whatever has the most consensus then do an MVP (Minimum Viable “Product”, not Most Valuable Player, of course 
). Similar to what was done with the AI stuff in last December’s “slow time”, which of course turned into much more because it proved its value. (in fact perhaps this could be someone’s “slow December” project, if they feel so inclined…)
The truth is that with many things we can (and often do!) speculate a lot about what people might want or what differences of opinion there might be, but the best way to find out is to release it to users and see how much of an uproar you get. 
This is not a good approach for all companies, but for Fibery IMHO it really, really is for the following surely compelling reasons :
- Fibery dev and release already works this way. That’s really all I should need to say, but I’ll say more.
- Fibery has many things that are implemented only “partially” (depending on use case/user perspective/needs), or work only partly well, or are far less sophisticated than many users would like them to be (e.g. very limited bi-directional integration support, the until-recently very limited Tables View, Whiteboard, etc, etc.)
- Many of these things are “good enough” to continue existing despite their limitations and still contribute significant value to the platform
- There is already an existing mechanism for experiments, some of which do not become permanent
- Using this mechanism (most of the time), Fibery has already released things, some of them significant (e.g. nav experiments), that it later removed/changed
- Furthermore the existing user base is comparatively small, so even if some experiment has negative results it affects a small number of people
- Fibery has not found true market fit, adoption is still slow and unclear (according to latest monthly progress update), and this has been the case for years now, so more changes probably need to be added/tested
Google Sheets embed is complimentary to a Fibery sync IMO, especially if the sync is bi-directional. I would love to be able to sync some Fibery data out to a GSheet and run some quick, ad-hoc calculations on it! I don’t expect per-entity calculation fields or Ad hoc formulas in views to be added soon, or even this request that Michael said would be considered:
So short of those, this would add most of the benefits of that in some sense, and complement existing functions like embed, reports, etc. that already work with GSheets…
If you need suggestions for specific answers to any of the above questions and more I’m happy to think through the practicals of an MVP!