> Really this is the job of the product manager, and if the product manager isn't actively using your product, or talking with your customers and end users, then they are failing at their job.
Eh, I've been a product manager and have taken my engineers to do the job, and it really changes how you talk about issues. I used to be PO for a team which developed warehousing software (a WMS) and would take engineers from my team to go picking for the day (if they were willing).
Dev teams will push back on some tickets, and say for instance that latency is fine (and that it's not possible to fix and unavoidable!). Besides, they know it's not user-perceptible at the current rates, and they know the exact latency as we have telemetry built in. If they do try to reduce latency, it's a half-assed effort with eye-rolling.
Then when they actually go and experience the job for a day they come back and are motivated and engaged to reduce latency because they have experienced it themselves, talked to users, and have watched other people working and can see the slight pause before the next pick. Suddenly maybe we should be pre-loading information before the next pick so that we don't need to wait for a web-service response?
And as an added benefit - the engineers would come back actually understanding the job and problem fully in a non-academic and practical way (people don't really 'get' how something works in practice until they have done it themselves, regardless of how simple it sounds on paper). And my personal experience was that a team of engineers that actually understand the problem are more effective and motivated to solve it (even if they didn't enjoy doing manual labour for a day).
I don't really buy the "only the PO needs to understand what the users want" - personally I see it as the PO's role to deeply understand what the users want and translate that into features / user stories, however everyone on the team needs to understand the job.