Treat Community Problems Not User Symptoms
June 11th, 2008[ Software Development ]
Steve doesn’t have to listen to users. Mark Hurst and others say you must talk, and listen, to your customers. Do you listen to customers? Do you give them what they ask for?
Of course the answers yes and no. No you should never listen to what users are asking for, then go off and build it for them. Yes you should always listen to, and effectively solve your users problems. What’s the difference?
Almost universally, a user does not know, and therefore cannot express, their root problems and the most effective way to solve them for your community of users. They do, however, know the symptoms they’re dealing with and they may have even dreamed up a potential solution.
Think of it in terms of problems, or symptoms, and solutions. People will rarely talk to you in terms of root problems. They just don’t know their problems. People instead like to talk about symptoms and potential solutions they’ve dreamed up.
Look at doctors. You go to your doctor and say you can’t hear properly and you’re coughing a lot. He crams some hearing aids in your ears to amplify sounds and gives you some cough syrup. You die two weeks later from a nasty chest infection. No, good doctors don’t blindly treat symptoms. They instead use them as clues to find and understand their root causes. Doctors also have patients who diagnose themselves. “Doc, I’ve got the flu, I need some medX” Again, the good ones take that potential solution as a clue, ask more smart questions to learn the real problem and then treat it properly.
Technically the doctor metaphor doesn’t even apply here. In building software products, we’re practicing epidemiology more than plain old medicine. We have to look at the health of our community and solve the problems for that population not an individual. (Wow, apologies Andria for utterly trivializing what you do…)
Yes, listen to users but assume what they’re requesting is one potential solution to a real problem. Your job is to keep working, ask smart questions, practice the 5 whys, talk to more users and ultimately learn what the root problem is and solve that in the best way possible.