Sometimes I find myself joining a team and introducing the idea of user research, a part of product discovery. I urge my teams to speak to users in carefully-planned interviews, and collect and analyse their needs.
And some of those times these ideas are embraced, but occasionally there is pushback. “We know our users,” people say, “We talk to them all the time in our help forums and support calls. We know who they are and what they want—we don’t need to do this so-called user research.” This pushback is understandable, and usually comes from both a desire to get on with the main work of developing the product, and a feeling that I’ve suggested they’ve been negligent in their job.
But when responding to these objection I say this is a different kind of conversation. Typically users speak to us about features and annoyances in the product they use. They are conversations very much focused on features, and very much focused on the present (“I want to do this; I can’t do that; I want that thing to work like this.”) It’s very unusual for them to spend time thinking about repositioning (or adjusting the role of) our product, and how it might be different. And it’s unlikely these users are really representative of our present and future userbase; often the users we speak to are the unusually vocal ones, or those we might call “power users”.
Listening to those people is important, but—as I said—we also need to seek a different kind of conversation. To make significant strategic decisions about our product we should take a step back. We must look at users’ context, and their wider problems—how does our product fit into their daily workflow? What are the concerns surrounding them at this time? Never mind their choice of our technology, what are they actually trying to achieve?
The teams I’ve worked with on these questions have found valuable insights from understanding users’ physical environments—the dual monitor set-up of one user who still found it necessary to work from printouts, or the group of users who too often worked from hotel rooms with poor wifi. We learned about their work pressures, such as the users who only got a few hours’ notice of a multi-day assignment. And in all these areas, and more, we learned much better how our products might, or might not, help them do their jobs.
All this is to help us make more informed decisions not just about forthcoming features, but the general presentation and direction of our product. This may include signficant restructuring to better align it with user needs. And of course, to get a more rounded sample we have to choose our interviewees deliberately, not just speak to those who we come across in the natural course of working lives.
Interviewing users for product research is always greatly enlightening, even if we speak to, and hear from, many of our users otherwise.