How do you talk across functions? When engineers talk to other engineers, even across disciplines, there's usually at some shared language/terminology. When you start talking cross-functional, that doesn't always hold true. In fact, many of the assumptions aren't shared, and that can lead to huge misunderstandings. For example, you would expect your customer to know what they want.
And they do. They want it to not suck. They want it to be easier. They want it to be faster. There you go. 3 simple requirements. Go build the thing they want. What's that you said? Those requirements don't mean anything? Maybe not to you, but they do to your customer.
So how do you delight your customer? By understanding them. It's not their job to understand you, it's your job to learn enough about them to understand what they want AND to understand how to communicate what you're doing to them. If you don't know their world find an SME who does, or make sure someone on your team becomes one. Understand how they do their work. Watch them do it. Ask them why they do it that way. Find the business value they're looking for and provide it.
That's how you understand your customer, but how do you make sure they understand you? First and foremost, talk about what they can see. The business value. The workflow. The interface. Don't worry about the features you're building, but talk about the benefits you're delivering.
And a side note. Don't over-rotate on this, but never confuse selling with installing. Whenever you build something for a customer you need to continue to convince them that what you are building is worth the time and money it's going to take. Provide clear deliverables/demos with functionality. Figure out what your MVP is, then add to it. And listen when they provide feedback. That doesn't mean scrap everything you've done, but understand the problem behind the complaint and work to make it better.