I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/actionable at turning customer needs into working solutions.”
The moment you have stubborn engineer who knows better than PM and user, it is really difficult to get anywhere. However if you will put such engineer into line of fire from a users that's suddenly not engineer's friendly PM trying to tell the engineer that this is wrong, these are frustrated people who would like to skin engineer alive as a punishment for using his "awesome" creations! That induces fear, but absolutely also crushes his ego, because somebody is berating product of engineer's genius like it would be a retarded hamster.
From my perspective, it is not about showing that PM is an idiot, it is about humbling your engineers. Their ego will grow again and this exercise will need to be repeated.
I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for. They might even clob several different tools together in an unholy abomination to get it to do what they actually want instead of having a tool built to do precisely what they want (and once that tool has been built - people will inevitably misuse it to do things other than what it was designed for and then complain about its poor UX for doing those things).
Playing along with this analogy, what I think we see a lot of in product development is the customer going to the PM and saying they need the cone to have a cover. The PM and the customer iterate over the specifics of the cover. PM goes to the engineer and tells them the cone needs a cover that meets x, y, and z requirements. Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.
That’s the kicker. They know what the customer _wants_ not what they _need_
The number of times a Jr engineer has asked me “how do I accomplish task X in technology Y, it’s really important!”
I always, always ask “what problem are you trying to solve. Not once in over 15 YoE has the solution been to use X.
A good PM doesn’t say “this is what the customer needs” because most of the time the fucking customer doesn’t actually understand what they need.
The engineer knows that holding the ice cream cone upside down means they’re trying to use the product in a way it was never intended, so they push back.
A good PM would ask “why do you want to hold the ice cream cone upside down, customer?”
“Oh well we don’t actually want to hold it upside down, we just get frustrated that sometimes when we put too much ice cream on/in the cone it falls out. So if you can make the cone hold the ice cream while upside down, the problem is solved!”
“Oh, so what you actually need is a bigger cone that can hold more ice cream?”
“Oh, yeah that would work too”
meme about Spider-Man facepalming, where Spider-Man is the engineer
Because I’ve done this enough times, they’ll listen to me and we won’t waste time on it.
You should try it, instead of designing soggy ice cream cone caps.