Find the area (other than the technical things) in which your engineers need assistance, and provide it. Where do they need assistance? - Ask them. Limit your promises. And when you need it for your project, ask them for technical assistance.
Ideas, blueprints, and plans can all be mercilessly torn apart in engineering. Therefore, in order to get respect, you must ensure that your assistance-related deliverables can withstand a sceptic audience’s rigorous scrutiny. Here’s how I go about doing it:
Make your helpful deliverables as logical and data-driven as you can. Make sure your recommendations are not “soft” or “fluffy,” but rather practical and specific. It’s acceptable to be strategic and abstract, but you must avoid using obnoxious or nonsensical business jargon, such as the derided term “synergy.” Recognize the constraints of your results/data, be ready for conflicting interpretations, and make an effort to quantify “soft” things: I’m feeling 70% certain that decision A is better for the bulk of the market because these two customer discussions fully contradict what analyst X claims in report Y, and my A/B advertising test supported the customers rather than the analyst by 80-20.
Ask for an engineer to be available to join the call if you have a customer interview that you believe may require more technical knowledge than you have (or just invite from the beginning).
Are more customer insights necessary? Get in front of the customers, collect the missing data, and deliver both the unprocessed interview transcripts and the distilled conclusions.
Do they require aid setting priorities? Get market sizing information that can withstand close examination and is supported by facts.