What Users Need
Interviewing Challenge #1: Not letting users’ courtesy fool you during product interviews
In the 2000 movie “What Women Want” Mel Gibson plays a cocky, chauvinistic advertising executive who magically acquires the ability to hear what women are thinking. In this fantasy comedy, the character goes on a success streak in his career and personal life, now that he can hear what women want.
But would we find such a plot convincing today? Would a window into people’s internal dialog help us understand their needs and desires? To be fair, the movie isn’t called “What Women Need”, but the success of Mel’s character is very much based on wants and needs being the same thing.
One of the biggest reasons that new products fail is they don’t solve a real problem. Considering the countless hours invested by the teams involved, such product failures are a tragedy. Even though, surely, no one wants to build a useless product, many such products are still built every day (trust me, I’ve built several useless products).
Gaining insight into users’ problems requires us to go beyond what users are saying, and often even beyond what they are thinking.
"If I had asked people what they wanted, they would have said faster horses"
This was the sentence Henry Ford famously said when asked about customer input in the development of the Ford Model T. People often interpret this quote by stating users lack vision, yet there’s a subtlety in the quote which I expect experienced product managers to notice immediately. It is that asking people what they want almost always leads to wrong answers.
Luckily, Mr. Ford was able to produce a product that we all wanted. But too many takeaways from this quote are that users don’t know what they want, so there’s no point in asking them. But in reality, that approach is what leads to the wrong products being built. To mitigate this risk we ought to talk to our users as much as possible. But we can never ask them the two questions that are constantly on our minds:
What’s your problem?
How much would you pay me to solve it?
Instead, we need to work around these questions. We need to help our users reach down to their treasure trove of experiences, fears, and doubts, so they’re able to share with us information that we can distill into a product they’ll love.
In all my years of interviewing users, the number one bias I’ve always struggled to bypass was the Courtesy Bias. In an attempt to act courteous users will often provide answers they believe the interviewer wants to hear. In doing so, users simply conform to the way most of us regularly talk to one another. We try to be courteous, supportive, and friendly. What makes this behavior especially frustrating is that users usually have a false concept of what it is we really want to hear. Some interviewers opt to build more rapport and empathy with users to get them to reply with honest feedback. But unfortunately, when employing such strategies we’re still left with answers we can’t necessarily trust.
The most effective way I’ve found to uncover honest feedback is to question the answers I’m given. Simply rephrasing and repeating users’ answers back at them to prompt them to dive one level deeper in their logic has proven useful time and time again.
Recently, while interviewing users for a new product feature I’m designing, I experienced exactly that. As this new feature will affect some other existing features, I was specifically interested in learning whether those existing features we had already developed were valuable to the user. Unsurprisingly, I asked, and the user said “Of course they are valuable!” But I wouldn’t relent, I needed to learn why.
The user, the GM of the customer division using our product, shared how a specific feature was wonderful because it would help them enjoy from additional inbound leads (generally, inbound leads refer to people who find your marketing assets, interact with them, and submit their contact details - simply put, it’s a channel through which a business can get more potential customers). My follow-up question was: “what percentage of your business is currently driven by inbound leads?” The user paused for several good seconds (such seconds are often ‘good’ because they usually mean the user is actually thinking of the answer instead of quickly reacting with a courteous one). Then, the user shared that 0% of their business is based on inbound leads, and that they’re entire sales team is structured to favor outbound leads (meaning they themselves do the outreach to potential customers and not the other way around).
At that point I understood that even though the user said they wanted more inbound leads, they didn’t need them, and most likely that even if they had them they wouldn’t know what to do with them.
Faster horses all over again.
There are plenty of other biases standing in the way of building products and features that solve real problems, but covering them all here would be unproductive and tiring. However, I do plan on sharing experiences I’ve had involving additional biases and what I found to be most useful in dealing with them. Like why is it that users often like to share their colleagues' pain points but find it hard to talk about their own? Or why is it that when you ask at the end of the interview “what haven’t we talked about?” you often get the user to share what is by far their most valuable insight till that point?
The way to deal with all of these challenges lies in understanding the distinction between wants and needs. It’s our job as product managers to continuously confront users’ answers in an effort to get to the truth, which is often hidden, even from the users themselves. And this is why even if we could secretly hear users’ thoughts it probably wouldn’t get us far.
P.S. I have no complaints about Mel's character in “What Women Want”, at least the character was trying, as is often the case with many product managers (who at least try). Already this is significantly better than Roger Sterling in Mad Men.
As I'm contemplating the build out of a membership community this is very useful insight on product development. When you said you weren't going to go into more detail I muttered "darn" under my breath. I would definitely be interested in your further knowledge about this subject. Loved the add-on question, "Is there anything we haven't covered?" I'm going to use that one.