Maybe, but direct feedback is incredibly insightful and worth it's weight in gold when time to market and product market fit are critical to the operation's survival: startup v Corp World.

> But the number of product managers that take this part of the job seriously is abysmally...

It really is, stepping into the Corp World starting from a bootstrapping co-founder position) was a total culture shock!

Moreover, the lack of clarity and vision is toxic to a Team's overall productivity, coupled with the fact that the they are likely the one with the most TC it's hard to rationalize the drudgery that it becomes--it's less optimization of stand out core functionality, and more adding needless features and bug testing busy work to suit a PM's 'roadmap to success' they think will lead to the next rung on the corporate ladder.

I can't think of a worst way top operate, actually.

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.

Could always save the mental energy to program whatever I want in my free time.

Also, who doesn’t want to make milkshakes for a day or two? That sounds way more fun that staring at a computer for hours on end. You can say that would sweeten up the contract for me.