The telephone game is the analogy I use too when explaining the value of having engineers in the custom calls.

Other than mistakes in communication, engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. They can ask the questions to find out if a customer is on one side of a trade off or the other. Or if a feature is 10x as expensive to implement because the customer needs/wants the benefits on both sides. Finding that out at the start can save a full development cycle of time/effort at times.

> engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not.

I frequently run into the issue of PMs spending more time discussing and trying to slot a feature into the roadmap than it would take to just implement it. Most recently it was with trying to scope out how long it would take to ingest encrypted files. I wrote the feature and had a pull request up before the end of the meeting where they were trying to figure out if we could implement it this quarter or next.

The inverse is when a feature is assumed to be technically easy to implement (just change that setting), and you have to gently explain why that will take a week.

Having people who are technically competent in the meeting often allows a short circuit to getting tot the solution along a pathway that a PM didn't know esited ro was possible through no fault of their own.