I think if you had both those videos and a convincing explanation of how they can both be truthful, the combination would great training material for everyone on a product team.
A healthy team would have that conversation. I'm not sure the PM needs to understand so much as defer to the engineering side if they decide a change is needed.
I don't think deference to engineers is useful in this sort of thing. There is a class of people (PMs) who have the hard job of aligning user expectations with the engineered reality. They do this by guiding both the customers and engineers, and to do that, they must understand the real landscape they are guiding people through.
[1] I don't want to imply here that everything was the fault of the PM, it wasn't. But there was definately a class bad things that happened due to this particular kind of non-technical thinking.
I wrote a design program for [thingys] that were basically rectangles, but could have circular arcs instead of straight line edges. A user could fake a circle using two semicircles joined by zero length edges.
The PM saw this and wanted a circular [thingy] feature. He could not understand that it was only a fake circle, such that when the user started changing things, (literal!) corner cases would crop up. Over time, he kept demanding new features that implicitly relied on non-fake circles. And of course this just kept throwing up more confusing corner cases that he kept trying to paper over with new features.
This is one example of a HUGE class of problems that come down to managers just wishing away a mismatch between the way data and code actually work, and the features that they would like to have.