What Engineers Get Wrong About Talking to Users

I came to product work from engineering, which means I brought engineering habits into user interviews, and most of them were wrong in instructive ways.

The big one: engineers treat user statements as requirements. A user says "I need an export to Excel button" and the engineer writes down export to Excel, estimable, shippable, done. But users report solutions, not problems, and the solution they report is just the first workaround their imagination produced. Ask why enough times and the Excel export turns out to be "I re-total these numbers by hand every Monday because I don't trust the dashboard." That is the actual problem, and it might be solved by fixing dashboard trust, which is smaller than an export feature and worth more.

Second habit, asking hypothetical questions. Would you use a feature that did X? People say yes. They are being nice, and imagining their best self, and it costs them nothing. The only questions that produce reliable answers are about the past. When did this last happen. Walk me through it. What did you do next. Past behavior is evidence, predicted behavior is a compliment.

Third, demoing instead of listening. The moment you show your prototype, the interview is over and a sales call has begun, because now the user is reacting to your idea instead of revealing their world. Do the listening interviews and the demo interviews on different days, with different goals, and know which one you are in.

The habit worth keeping from engineering is the debugging mindset. Treat each interview like reproducing a bug: get the exact sequence, the actual inputs, the real error message, not the summary the reporter thinks you want. Users, like bug reports, are honest about symptoms and unreliable about causes. The causes are your job.