The first rule of Product Management is: don’t trust what people say matters to them.
You might be thinking now: Maarten, are you doing alright? What happened for you to turn so salty and bitter?
To prevent any misunderstandings: trust people, but don’t necessarily trust what they say matters to them.
Hear me out. What people ask for is not necessarily what they want. What they want is not necessarily what they need. What they need isn’t necessarily what they want.
If I ask you: is exercise important? You'll probably answer yes.
If I were to monitor how much you exercise every week, I might get a completely different picture of how important exercise is to you.
This is the difference between declared and revealed preferences. What people say is much less reliable than what people do.
There’s zero skin in the game to saying something matters, while if we watch how you spend your time or money, then we’re introducing skin in the game and it often paints a completely different picture.
Almost everyone wants world peace, yet who does something to help our civilization to get there?
David Ogilvy nailed it:
"The trouble with market research is that people don't think what they feel, they don't say what they think and they don't do what they say."
There’s a good reason the Product Death Cycle by David Bland keeps on running because we ask customers what they want:
Don’t trust what people say they want. Treat everyone as an unreliable narrator, yourself included.
Great products require curiosity. Nothing kills curiosity quicker than obeying an unreliable narrator and blindly following instructions from someone with wishes they verbalize.
You must still listen to everyone and care about what they have to say, the hard part is making them feel good while you’re not caving in an immediately giving them what they want.
Be patient and keep people happy until you have something better than a fistful of nothing a.k.a. the spoken word of an unreliable narrator who believes they are extremely reliable and trustworthy with their demands and requests.
This is the way.
And boy can it be incredibly hard and ungrateful. But the alternative is to build mediocre products that fade into obscurity.
And nobody wants that.
The most reliable to me is to ask what people do, and then to describe how they do it (with an example), and why. What they would like to do, imagine themselves, be interested in is a lot of fantasy.
I once learned: The customer is NOT always right. They are often wrong, and frequently confused. I agree with you, it isn't wise to trust requests at face value. This is why the collaborative approach encoded in Scrum, i.e. customers working with developers working with business folk is an effective way to discover what is actually useful. It takes time, as you say. But it is time well spent.