My son recently started high school, and as it happens, the school has a new principal who was hired in from another district. In order to get to know families, he held some “coffee with the principal” evenings. The one I attended was informal, really just a few of us sitting around and chatting. We talked about teenagers (he has one too) and his experiences and observations so far. He acknowledged that while he has a lot to learn about the school and community, one advantage he has as an outsider is his ability to see things that other people don’t notice. For example, he looked at the carpet in the auditorium and wondered why it was so worn. As soon as he brought it up, other people noticed its relative shabbiness, and discussion were started to get it replaced. It was, after all, 15 years old. But why had none of people thought to replace the carpet prior to this? The answer is fairly simple--they were used to it, and hadn’t fully noticed the problem. They had seen the wear and tear occur gradually, and were inured to the change, until it was pointed out to them. They didn’t see the carpet in the same way an outsider did, until a new perspective helped them look at it anew.
The need for fresh eyes is important for the products and tools we create as well. While the full time people who work on products are undoubtedly experts on them, that very expertise can get in the way of seeing what outsiders will notice first. Outsiders may be new hires or outside consultants who are willing to ask “Why does this work the way it does?” or they may be users and customers who (quietly) struggle with the end results. It is important to seek out and be open to open to this feedback, and to resist the urge to dismiss complaints as outsiders simply not understanding. There may be good reasons why certain decisions were made, but understanding the problems and challenges can lead to new solutions that address issues, or new ways of explaining, as these examples illustrate..
“But the analytics say that feature is rarely used”
The product manager was very data driven, and noticed that a certain feature that was highly prioritized was rarely used. Given his focus on data, he questioned its priority--a reasonable step. At the same time, in surveys, discussion groups, and individual feedback sessions, users said this feature was important to them, so the manager was also aware of the seemingly contradictory information. While he thought it might be due to people saying what they want not being the same as what they actually do (as is often the case), he was open to a deeper exploration. A first indication of a problem was that actual users of the site complained about their inability to do what this feature offered. A closer look, with the fresh eyes of a consultant new to working on the site, revealed that the feature was arguably hidden. It was difficult to see that it was available, and unclear how to make use of it. New designs are being tested to see if greater visibility and clarifying text increase usage.
“They just don’t understand”
On the flip side, often products do have too many features, because the people building the product want to be sure that anything anyone could possibly want to do is available. They are afraid that taking a capability away will affect the ability to sell the product, and the lack of usage is because people just don’t know how to use the product properly. Several years ago I did research with users of a lower end hardware device, because product management wanted to know which new features would be most valuable for customers. They were particularly interested in learning how they could increase usage of a particular feature that would also increase revenues for the company, and how to make it easier to use. As we visited with customers, we learned that they were aware of that feature, as well as many others, simply didn’t want them. In fact, many of the extra features got in the way of what they actually wanted to do, and the most common feedback we received was to simplify the product.
Why “eating your own dog food” is good, but not enough
Many companies practice the “eat your own dog food” (or, more positively, “drink your own champagne”) philosophy, which encourages employees to use the products they build. This encourages empathy with end users, and can make many problems immediately apparent. However, because of their intimate familiarity with the product, and often their technical knowledge to troubleshoot, does not replace the outsider perspective. Teams need to actively seek detailed feedback throughout the development process and throughout the lifecycle of their products in order to truly understand how people see and use their tools.