* management distrust of developers, if your developers need a lot of help to do their jobs management won’t let them near the customers for good reason

* separation of concerns, specialization

* emphasis of productivity, developers should be developing

* assumptions and biases that developers are not people people, which is sometimes completely unfounded and other times strongly reinforced

If you want developers to understand your customers they have to be directly embedded in customer engagement meetings where they can directly see customer wants and reactions the same way your product management learns these things. This can prove very risky due to the personalities involved.

In my line of work developers are completely on the front lines directly communicating with customers. My line of work, enterprise API management, is highly technical demanding a wide technology background but it’s not that challenging. The customers know what their end state is but not how to express their business requirements or diagnose their challenges. The developers, myself included, often have no idea behind the business goals for interconnecting various business system but have little challenge solving for the communications in the middle. Most areas of software are not like this, by a lot.

> The software we make isn't software for software developers

Like most software companies on the planet.

> we need to improve developer understanding of how our customers use the product

I'm pretty sure no dev said that, ever. It's the job of the CEO, managers, project managers, sales people, etc. Anyone but the devs who would do anything not to get fired nowadays.

> encouraging devs to reach out to customers

It's NOT their job. I would be very reluctant to contact customers directly. Most clients don't know what they want, and devs want to please anyone as long as it involves coding. You need direction. Also, when customers have impossible demands, managers will lie that it's possible and try to sell something different. No dev will tell you that something impossible is possible. We are not salesmen.

> We've also pointed to existing bug trackers

That doesn't mean anything at all. Which bug tracker?

You seem very confused about what a dev is supposed to do. You need a PO (project owner) or PM (project manager) or anyone that can understand the customer's needs. Right now you have none and you think your devs should find the issues themselves, or magically find what the customers want.

Feel free to ask if you have more questions.

Edit: the last time I spoke to a customer, I gave a few technical details and no one cared. I don't know what is his IT department, what is his budget, who I have to contact, I know nothing. That's the job of a whole team (CFO, sales, etc). It feels like one of those niche projects where anyone can do anything and the client is supposed to accept that with some kind of unlimited budget, am I wrong? (Edit: "Payroll, HR, and Workforce Management" no wonder your devs are not understanding what you do, you need serious training, simulations, or anything to entice them, but speaking to customer would be a bad idea).

If we find ourselves saying "we don't know what the user does today" or "we don't know what the user needs in this scenario" we typically reach out to customers and politely ask for a meeting and try to ask questions that only pry at their needs and problems, rather than hinting at our solution.

We also have metrics and opt-in analytics of our services so we can monitor what the customer do with our product as well.

We have UX designers on our team that really really emphasise this type of way of working/thinking and I think it helps us devs understand our customers better, although it can feel slow and annoying at times to keep asking these questions and doing prolonged workshops.

At the risk of overgeneralizing, I think we do understand, but we just don't sympathize. Either because the product is trying to trik the customers into buying/subscribing (so naturally we don't like that kind of behaviour, even less when we know exactly how's that implemented), or because the product is designed "for babies": nice graphic colors here and there, videos, sweet transitions, whatever. We think that's all unncessary, and a simple HTML+CSS page would suffice for most products out there.

At least, that's what I have seen around. My team is currently building a fitness app. We are discussing tirelessly things like what engaging content we can use, the transitions between fitness exercises, how to keep them motivated to use the app... and the engineers I'm working with (I'm included) we all think that a simple bullet list of exercises and links to videos would suffice.

More often than not, the product just sucks and nothing can be done to fix that (e.g., Linkedin, Facebook, Quora) ... but obviously we won't say anything because we are here for the paycheck.

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.

The devs are the ones doing this?

> encouraging devs to reach out to customers

> encouraging devs to pair with customer-facing staff

Are the devs actually doing these things or are you just encouraging it?

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.

Why? What impact is it having? Or is it just non technical people complaining similar to how a dev may complain that PMs should understand the code more.