fluency also places limitations on speed, being aware of a wider set of use cases requires wider examination of context to discover interpertive options, and that takes time
And even worse: after spending the time to infer what the user wants -- the software might guess wrong.
Therefore it probably makes sense to constrain the software's use cases -- either i/ to specific functions (e.g. product, eng)
or ii/ to specific roles across functions (e.g. management, support desk triage)
An added benefit of constraining use cases like this is that it's easier to market to a specific use case.