How do we differentiate between what we think our users need, and what they actually need?

Last night I was asked a question, that went along these lines:

How do we differentiate between what we think our users need, and what they actually need?

There was also a quote accompanying the question:

If I had asked people what they wanted, they would have said faster horses – Henry Ford.

I knew I wouldn’t be able to sleep that night if I didn’t answer it, because it’s one of those crucial questions, especially when you’re creating tech products, and at the same time, one of my favorite topics for discussion. You’ll find my answer below, or rather its expanded, stylistically smoothed and more business-oriented version.

This issue can be discussed on a number of levels. What we say they need, and what clients actually need are two different kettles of fish. The first one (we) should always be sufficiently bigger than the other (clients), in order for us to be able to test out as many solutions as possible. Thus, it’s always good to have rapid implementation and testing cycles (week-long developer sprints facilitate this), so that you can see whether what you want is the same thing the users need. Every successful test like that is a step closer to an optimal product. However, this process is dangerous, because the final result may be the “faster horse” mentioned by Ford.

Things like that happen, because every iterative amendment is based on reverse thinking – you’re trying to see in what way does the product work better now in comparison to how it was working a day, a week, a month ago. The same goes for evaluating data from analytics systems – it’s always rooted in the past. Instead, you should always try to foresee the future.

To me this is the iterative path – squeezing out the most from the present state. Just as when you’re supercharging a processor or an engine, you’ll always reach some kind of tech, physical or logistics limit. On the other hand, something that comes from a totally different market, is built from scratch, without legacy code or an existing structure, proves to be faster and has better traction. This helps to create an unbeatable advantage and leave the older, market-wise, competition who already carry baggage, in the rear view.

“The Innovator’s Dilemma” by Clayton Christensen does a good job of describing the perils of an iterative approach based on optimizing current solutions. The author calls the effect of such actions “sustaining innovation”.

Christensen indeed says that companies listen to their clients too much. People will always describe the future using present terms: “We want the same thing, but faster”. It’s a natural thought trap, because how are you supposed to want something that doesn’t yet exist? And while companies keep pleasing their current clients, there is a startup somewhere in a garage, that doesn’t yet have clients, starts creating a cheaper, less stable solution without a clear growth path, but with a huge potential to be a game changer. Airbnb would’ve never arose at Hilton, Uber would’ve never launched as a part of a taxi corp – Hilton guests and taxi passengers simply don’t know that they need such radically different ways of meeting their needs.

People will always describe the future using present terms: “We want the same thing, but faster”. It’s a natural thought trap, because how are you supposed to want something that doesn’t yet exist

With that being said and to provide an answer to the question, I see two ways of finding out: one – iterative, and another – leap-based. The former has been already discussed, the latter is a method for self-disruption, before someone from the outside does it.

The second path is a quality approach. It’s based on hypotheses that are far bolder than iterative changes. At the end of the day, disruptive innovation will never emerge from A/B testing. Again, I’m leaning on Christensen, the “Jobs To Be Done“ theory, to be exact.

JBTD assumes that you “employ’ every resource you have to perform work – fulfill a need. It’s not always clear though, how does one select the particular way of satisfying a need. You always have the same needs (sleep, food, belonging, interaction, etc.), you always want to find better ways to fulfill them, but you’re unable to rationally communicate it. In order to reach these insights, you have to stimulate emotions, nostalgia and senses – spheres where the rational mind doesn’t interfere.

In such cases, one uses, among others, generative techniques which help in reaching the so-called hidden knowledge, that is things that people feel and dream of.

The research results show extreme cases, which usually level out and disappear in quantitative research. However, they provide better answers to the question “why?”, and not only “how?” do people make decisions. This helps you to learn the actual drivers, which may have not much in common with your product. So, instead of trying to create a better product, look for ways to better fulfill a need through understanding it more precisely.

instead of trying to create a better product, you’re looking for ways to better fulfill a need through understanding it more precisely.

Apple 1-ups this approach by creating not only a better product, but also pushing its users toward places, where it thinks it has better chances of satisfying their needs. Take a look at the iPhone 6s, for example. This smartphone could’ve easily been a couple of millimeters thicker and so offer a battery life twice as long – every user would love it.

But Apple insists and pushes the users toward as thin devices as possible, while trying to break barriers, inciting the feeling among people that they’re holding a work of magic in their hands (and this is a real need that the customers are willing to pay premium for).

To sum things up, you never know exactly what your users want. Largely because they don’t know it themself.

To sum things up, you never know exactly what your users want. Largely because they don’t know it themself. What you can do is stay close to them and trust their opinions on one occasion, while intentionally ignoring them on another. Strive to do things differently, hoping that you’ll manage to open their heads to new ideas, they didn’t even realized existed.

Just make sure you don’t mix up too many things along the way.