Engineers love solutions. Sometimes they solve problems. Sometimes they make more problems - which need more solutions. To avoid building the wrong thing, understand a problem deeply before offering a solution.
I've noticed this bias to understanding before solution-ing when working with designers - in particular my time working with Molly Chao. Designers seem much more interested in understanding the "problem" and the solution comes later. This may cause conflict when a designer and a developer work together. The developer keeps giving solutions while the designer goes on about what's the problem we're trying to solve. Ships in the night.
Both perspectives are valuable, but I think generally the place designers begin is the correct one. However like all things, a product sense (the ability to understand the problem so to build a better solution) can be learned given sufficient time and practice.
The single best way is to be an active user yourself of the product your building. However this may not be possible in all cases (healthcare, banking, military).
One exercise I've found for improving product sense is to ask 3-5 clarifying questions when given a task - and fighting the urge to blurt out the solution you have. If you're not sure what to ask - try out the simple questions: who, what, when, where, why, how. Then the inversions: who won't, what won't, when won't, where won't, why won't. Then the extensions: who else, how many, why not, how often, where does it hurt, etc. Some other useful questions:
- If this problem were solved, what would that allow you to do?
- Did you have solutions already in mind? What were they?
This draws out insight that was overlooked as trivial for the asker but is pivotal for the developer to find a solution. Over time you stop asking formulaic questions, but you begin to improve your own active listening and the ability to know what truly needs to be asked and when - at that point it may feel a lot more like mirroring (wherein you try to confirm that your mental model matches their own mental model). For example the dialog becomes: "So what you're saying is you are unable to do X because of Y which causes Z, but if we did A, B, C instead, you would be able to do D, E, F, so that G, H, I could happen?" This can eventually be communicated back in formal documentation with a model like leanstack.com/lean-canvas as you please.
The second crucial part of this is to not interrupt. And like all advice, the person giving it is usually the worst at following it. I always seem to interrupt, but I have seen others be quite good at letting the speaker continue. It can also be difficult when the asker tends to ramble and meeting time is limited. Resist the urge. There will be a natural pause that arises - count to five in the infinity of silence and then you may begin.