What to do instead of asking users what they want

I’ve talked to a lot of users, ranging from users of apps to professional services. And one thing I’ve learned when trying to understand their wants and needs is this:

Asking users what they want from a product (and believing them at face value) is a fool’s errand.

That’s not to say user interviews and other forms of market research are a waste of time. It is to say that expecting accurate answers to high-level questions is not realistic and should be scrapped in favor of better techniques.

Here’s more on the common traps of user research and the methods you can use to get the most useful data.

When Henry Ford made cards accessible to the world, he famously said “If I had asked people what they wanted, they would have said faster horses.” While we’re not sure he uttered those words specifically, the sentiment he embodied is clear: Users of products aren’t product developers; they don’t know what they want because they don’t have the skill to synthesize their needs into novel solutions that leverage the cutting-edge of what’s possible.

Put another way, users live their own lives. They come from a variety of backgrounds and professions, most of which do not involve rigorously evaluating their needs and creatively inventing tools that satisfy those needs. That’s where we come in. As product-development professionals, our entire purpose is to anticipate needs for them and provide concrete solutions that they would not otherwise have considered.

With that in mind, it makes no sense to ask users what they want at the product or feature level. If you ask, “What features would you like to see most in the next version of an app?” they’ll likely respond from a perspective that ignores the full breadth of what’s possible. For example:

In both cases, the user provides examples that their limited experience dictates rather than what would end up providing value. If you gave them the email button, then their sharing would exclude the many other superior channels of sharing socially. If you gave them nested tasks, they may become even more disorganized with “more rope with which to tie themselves up” and eventually abandon your app with feelings of overwhelm.

Giving users what they ask for at face value generally leads to poor results because they anchor only on what already exists in their limited awareness. Instead, you must anticipate what they really want with a host of other probing questions that allow you to model the breadth of their experience as best as possible. Then you make the call as to what gets built, not them.

By saying that questions to users at the imaginary product and feature level are a dead end, we’re implying that we need to collect data at a level of abstraction that’s more meaningful to the user and better fodder for interpretation by product professionals.

In other words, we need to meet the users where they are, not the other way around, and build a bridge to a better way of operating with our products.

Some of us interpret this to mean that we should instead ask users about their general wants and needs, rather than specific products or features. If we know what they want and need, then we can reverse-engineer features from that data, right?

Nope.

Turns out, users also have little awareness of what they want and need, even in a general sense. That’s because the specific skill required to identify and articulate real wants and needs in a way that’s useful for product development is not in their repertoire.

Returning to the example of a productivity app, a user may say they want to be more productive, or get more done more quickly. They may, indeed, believe that’s what they want, but upon probing further, what they really want is to meet their obligations and not feel overburdened by tasks. As such, providing tools to get more done more quickly does not serve them; it encourages them to add more to their plate when really they should be saying no. Providing them with a framework to prioritize what’s important and scrap what isn’t is the thing they really want, but it’s not something they’d ever think to articulate.

The solution here is, again, to relax your expectations of the user’s ability to process details of hypotheticals and arrive at accurate conclusions. Rather, get them to describe what they are doing. Get them to list the problems they are facing or describe what they think they are trying to accomplish. Ask them how they feel about each of the pain points, and get them to elaborate with rich, qualitative information. Then, most importantly: Read between the lines! Interpret that information. Consider what it implies about their experience and about their deeper motivations. Draw varying hypotheses and test those with more questions or experiments. Whatever you do, do not take what they say at face value. Be a partner in solving their problems by empathically feeling through and living them together.

There are also many instances when asking questions can only get you so far. Above and beyond, one of the riches sources of user data is a strong product analytics implementation with tools like Mixpanel. Once you hypothesize products and build them in real-life, analytics allow you to see what users actually do as opposed to merely what they say. In other words, it allows users to grapple with their problems in real time with a concrete solution, completely bypassing the need for them to interpret or articulate anything. You, as a user researcher or product developer, can then create a deeper and even more nuanced model of their experience when you synthesize both sources of data and release additional versions with key tweaks until you finally reach product-market fit.

Again, it is entirely possible to get meaningful insights from users and make incredibly fruitful product decisions as a result. The problem is not the impetus to collect data; it’s the application of techniques that seem viable at first but end up being unhelpful thanks to the simple realities of human nature.

When it comes to gathering information by asking questions to users, there are fortunately many resources for getting it right. There are countless, high-quality articles with best practices for conducting user interviews. There’s tons of literature on what makes a good survey by academics. And if you synthesize the wisdom from both camps, you can easily succeed at creating product surveys that yield real insights as opposed to phantom nonsense. Mix that with an analytics solution that can spit out insightful reports on real user activity, and you’re well on your way to developing a Model T of your own.

Joseph is the founder of App Boss, a knowledge source for idea people (with little or no tech background) to turn their apps into viable businesses. He’s been developing apps for almost as long as the App Store has existed—wearing every hat from full-time engineer to product manager, UX designer, founder, content creator, and technical co-founder. He’s also given technical interviews to 1,400 software engineers who have gone on to accept roles at Apple, Dropbox, Yelp, and other major Bay Area firms.