Jonathan_Graehl comments on Hold Off On Proposing Solutions - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (48)
No transcript. But I do this professionally all the time. Clients frequently come to me with a design in mind for a solution, and it's often important to back them up and get them to tell me what the problem actually is.
Usually, I start with the question "How would you be able to tell that this problem had been solved?" and repeat it two or twenty times in different words until someone actually tries to answer it.
On one occasion I handed a client my pen and asked whether it was a solution to their problem. They looked at me funny and said it wasn't. I asked them how they knew that, and after a while one of them said "well, for one thing, it doesn't do X" and I said "great!", took the pen back, and wrote "has to do X". Then I handed them the pen back and said "OK, suppose I add the ability to do X somehow to this pen. Is it a solution to your problem now?" and after a couple of iterations they got it and started actually telling me what their problem was.
The thing that used to astonish me is how often the proposed solution utterly fails to even address the problem articulated by the same person who proposed the solution. I've come to expect it.
Bleakly funny. Thanks for that. I usually retreat (probably with an angry or pained look on my face) when I notice I'm not really being heard. But sometimes it's better to play and explore.
(nods) It's kind of critical in a systems engineering role.
Only vaguely relatedly, one of my favorite lines ever came from my first professional mentor, about a design he was proposing: "It does what you expect, but you have to expect the right things."