I've always tried to include the "why" in the documentation/task/ticket that hits the developers eyes.

When I was an engineer, most PMs/POs would just dictate "what" needed to be built, and give us the standard Agile mantra of telling us to choose "how". But if you also include the "why" of it, not only are you constantly communicating additional information about the customer, but you give more opportunities to get different ideas from different people. In my processes, I always have the engineers look over incoming tasks before they get assigned to be done, and it was common to have some iteration on implementation based on the engineer's reactions and ideas. Of course, not all their ideas were good, but in general the additional collaboration was appreciated, and resulted in additional customer understanding, so it was worth the extra time and effort to bake the customer info into the tasking process.