People outside an industry often lack its vocabulary, but they may recognise a problem that their own field has already approached differently. A conversation becomes useful when both sides can understand the task without first learning all of the same terminology.
The quality of that exchange depends on how the problem is framed.
Describe the outcome, not a predetermined solution
Explain who experiences the problem, what happens today and what a better outcome would look like. Include the constraints that matter: time, cost, materials, operating conditions or regulation. Avoid asking for a specific technology before understanding whether it solves the actual need.
Make comparisons carefully
When someone suggests a parallel from another field, ask which parts transfer and which do not. A process that works in a controlled setting may fail under different conditions. Useful analogies generate questions; they do not prove that a solution will work.
Write down the assumption you would need to test. This turns an interesting conversation into a concrete experiment instead of another idea that remains in a notebook.
Give a small experiment a clear boundary
Agree on who will do the work, what each person contributes and how the result will be evaluated. Address confidentiality and ownership before sharing proprietary material. Keep the first experiment limited enough that everyone can learn from it.
A well-written business requirement can invite this kind of contribution. Specific context helps someone recognise where their experience might be useful, even when their business looks very different from yours.
Make the problem clear enough to contribute.
An Intent post in GENEZEZ lets you describe a business requirement and receive responses from other members.