The Law of Wishing Well
Once upon a time, there were wells. Those were long, straight holes dug into the ground, usually with a retaining wall and a pulley. You dug until you hit fresh water and used that for drinking, bathing, watering the plants, etc. Some people thought that wells could be magic (they certainly could be tragic, e.g. if you fell into one and drowned). So they’d throw something (usually a coin) and make a wish.
This is not about that kind of well. This is an article about people’s ability to wish well. My thesis is going to be that people wish poorly for a variety of reasons, and that it is incredibly important to analyze a wish and turn it well, instead of just implementing whatever it is the person wished.
I have had problems with this in my personal life in the past. You know the moments a wide-eyed and clearly not well-slept friend comes over and says you should be going on a wild adventure? And I look at him or her and say, “You really should go to sleep.” Infuriating, right?
Well, in my professional life the same problem has been much worse. Usually, that’s because I am several steps removed from the person making the wish, and by the time I hear about it, I cannot see the wide eyes. I just have a feature request and I scratch my head.
It’s not always the case, of course. The vast variety of feature requests are fairly simple and straightforward. The wording on this page is misspelled. If I click on this button, nothing happens. If I click on that button, I get an error message.
The big requests, though, especially the nebulous ones, are usually poor wishes. When you are puzzled by a requested feature, it’s usually because someone is trying to solve a problem by telling you how they are frustrated by their workaround. So you should not implement the workaround, but find out what the problem is in the first place.
In one company whose R&D I ran, we got multiple request from customers. They all complained in exactly these words: “The system is slow.” I set out to get metrics. It was fairly easy to get page load times from the system, and I was all set to implement performance instrumentation.
Then my head of quality came back with the numbers. Average page load time under 0.15 ms. Maximum load time recorded 25 secs. That was definitely nothing anyone would complain about, if even the outliers came in under 30 seconds.
On one hand, I had data telling me that the system was fast and responsive. On the other I had Account Managers complaining loudly that customers didn’t think so.
I got the AMs in and performed a demo in the office. Things were zippy and fast. We tried everything and there was no holdup. The AMs agreed to push back on the customers and go through processes with them, to show that things were not slow.
At the same time, one of the Account Managers, whose account was close to the office, said she was going to help a customer over the weekend. I asked why not in the evening, and she said because it took more than eight hours to complete the process.
And suddenly I had my revelation: the application was not slow. The process was slow. Something in the way we did things didn’t work with the things the customer needed to do.
Instead of giving us information that would have helped us identify the problem (in particular, in this case, “You have not the faintest idea what we do all day”), we only heard a remote grumbling about something that didn’t make any sense.
The experience taught me two very important things:
- When you receive an indirect complaint that doesn’t seem to make any sense to you, talk to the person that made the complaint directly. Make it clear that you do not intend to offend communication channels and include the channel owners – but you need to talk to the person with the problem directly.
- When you create something, people are invariably going to push it into directions you didn’t think of. It is much more useful to listen carefully to your users than to plan ahead, because these directions are random and unpredictable.