For features -

Do developers have ownership? Do they write tech specs, proposals, etc? If so, these should include a section on what problem is being solved. If they don't understand the product this is a good way to kick off more conversations about it.

If developers aren't doing this - e.g. if you're leaving it up to management to tell them what to do and how to do it - that's the problem. Companies like this lack incentives for devs to learn about the product if they're just going to be told exactly what to do and aren't given the freedom to think creatively. If this is you and you want to shift the culture, start encouraging developers to propose features and show that you value their contribution to the product. Invite lead devs to meetings and to comment on documents where features are being proposed, from the beginning, instead of handing them a thing to implement.

For issues -

Are PMs communicating issues well? Including why the issue is important? Perhaps something like a loom demonstrating the exact issue would help.

Have a rotation for addressing issues. e.g. if a dev is on call they should work on customer issues when they're not fighting fires.

I do have trouble finding good faith arguments in favor of this policy. It is cruel. But the people who decided to implement it aren't "other". They're humans who think they're good people (aside from a small minority of people who really don't care) and much as we'd like to think so we're not that different than them. If we can understand their justification, that's a step toward actually convincing them there is another way. And yes, I have changed many people's viewpoints with this level of patience, not everyone is too stupid/mean/insult of your choice to change their minds.