Lots of good points here.

I’m lucky to work in an org with a product team that does a fantastic job of detailing the problems they want to solve and an idea of the workflow a user should take. They discuss that w/ our design team and architect, who basically come to a conclusion about how the problems get solved in a way that works well for both users and developers.

If you ask our customers, they’ll say they want A and B (in many cases charts and graphs), when neither would solve the actual problems they have (e.g. optimizing cost), and what they need instead is to provide a little more data (i.e. their upstream and downstream costs) so we can produce better recommendations (i.e. reduce X and increase Y to get similar results for less cost). We’re really good at simulating things, our customers are really bad at it, yet customers ask for features that let them try to simulate things instead of us providing that value.

That goes double for games, since people are a lot more emotionally invested in games that workplace software. If the player is complaining about “bad controls,” the solution may be some kind of indicator of off-screen enemies (i.e. improve time to react), which has nothing to do with the controls themselves.