Why You Shouldn’t Ask Customers What They Want

The customer is always right. 

If you involve customers –  you’ll make better decisions. 

The only problem with statements like these is that they don’t seem to account for all those occasions when the customer wasn’t right. They don’t explain the fact that, despite high degrees of customer involvement and extensive market research, between 70-90% of all new product launches still fail.

Perhaps then, customers can’t actually tell us what they want, because they don’t know themselves.

{Note: for the following article I’m using customer as shorthand for any user of your organisation or service, including employees}

Last week, Nick Chater, Professor of Behavioural Science at Warwick Business School, delivered a talk to our Board. It made me think that we tend to take rational ‘commonsense’ for granted, so much so that we design new products and services without taking into account irrational or illogical behaviours.

We have irrational customers but we design rational customer experiences.

Indeed – we are fighting the idea that customers are often irrational. 

There is little evidence that we can even predict our own behaviour. We don’t necessarily know why we make decisions. When anyone proposes a change – even humdrum day to day changes (think self-serve check outs in supermarkets , or charging people for plastic bags) – we don’t react rationally.

That’s why , for example, so few people switch fuel suppliers despite the fact they’d be better off by doing so.

Our status quo bias, the tendency for us to lean towards doing nothing or maintaining our current or previous decision – is a strong reason for never asking customers what they want.  Every pound we put into asking customers what they want is basically wasted.

Have you really got the time to be distracted by what customers think they want?

Lessons from New Coke

In 1985 one of the biggest brands in the world nearly destroyed itself – by listening to what customers said.

Coca-Cola developed a product dubbed “New Coke” that was slightly sweeter than the original. Almost 200,000 blind taste tests were conducted and most participants said that they favoured New Coke over both the original formula and the companies bitter rival, Pepsi.

Hundreds of thousands of people can’t be wrong, right?

New Coke tanked – costing the company millions, with the CEO later commenting that they had “drawn a moustache on the Mona Lisa.”

There were two main lessons learned:

1: The research was flawed as it was based almost entirely on sip tests—a comparison of sips, not someone enjoying an entire drink. A blind test in a lab type environment was out of context compared to the experience of , say, drinking a Coke in the garden on a summer’s day

2: No-one realised the symbolic value and emotional involvement people had with the original Coke.  What customers said was “yes, this tastes a lot nicer” but when the product hit the market they behaved entirely differently. Influenced by their emotions and a status quo bias to keep things the same, they demanded the old Coke back.

Many of our organisations are still making these same mistakes – assembling focus groups and panels and involving users in ways that are wholly artificial compared to an actual customers lived experience.

The ‘customer knows best’ argument needs some challenge.

Whilst I agree that users are almost always closer to the problem than the average senior manager or executive, proximity to the problem doesn’t automatically make you the best person to solve it.

Solutions require subject matter experts who have a deep knowledge of the root cause of the problem and can look through multiple lenses to craft a response.

The idea that a customer can provide that based on fairly limited knowledge (or interest) is naive.

Designing the right solution means testing for irrational behaviours.

And that can only come by observing what people actually do rather than basing decisions on what you think , or what they say, they’d do.

The research of Clayton Christensen found that companies that fail often listen to their customers too much.

As users we struggle to envisage the future. Indeed, asking someone to consider the future is a bit like saying, “Tell me how you will behave in five years time when I’ve rolled out the service I’ve just asked you about.”

Arguably the best time to engage customers is the feed into the problem definition – and then at every stage through iterative testing, pilot and subsequent release.

If I had asked people what they wanted, they would have said faster horses – (not said by) Henry Ford

It’s a great line but there’s no evidence that Ford ever said this. It never appeared anywhere until about 1970. A longer quote , and one he did say in his 1922 book, is this:

“I will build a car for the great multitude. It will be large enough for the family, but small enough for the individual to run and care for. It will be constructed of the best materials, by the best men to be hired, after the simplest designs that modern engineering can devise. But it will be so low in price that no man making a good salary will be unable to own one.”

Ford understood his customers aspirations long before they did.

We’ll only ever solve problems through having a deep understanding of our users and customers. That means accepting their flaws, their biases, and the fact they often make bad decisions.

Only by testing real products and real services with real customers in real-world situations can we hope to understand how people truly behave.

Why We Are So Bad At Defining Problems

If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions. – Albert Einstein

I don’t know whether Einstein ever used those words. It may be just like the Henry Ford “Faster Horses” quote – something perfectly phrased and also perfectly true that no-one actually ever said.

Whether he said it or not, Einstein believed the quality of the solution you generate is in direct proportion to your ability to identify the problem you hope to solve.

And of course he was right, you can’t really solve a problem you don’t fully understand. “If you can’t explain it simply, you don’t understand it well enough”. Another quote he (probably) didn’t say.

Either way, 60 years after his death, many of our organisations have still failed to learn his most valuable lesson. So what is so difficult about problem definition?

Many of our organisations have set the climate for solution focused rather than problem defining behaviours.

A solution focused culture is exacerbated by the following conditions:

  • Leadership putting pressure on finding quick fixes and the realisation of short term goals – rather than long term impact
  • Discussing problems, or considering that organisation itself may be part of the problem, is seen as taboo or a sign of weakness
  • Management falls in love with a solution too easily even if it’s not solving the problem at hand
  • An implicit assumption that leaders have all the answers. “Let managers manage and get on with it”
  • A lack of evidence based enquiry – which allows bullshit organisational ‘facts’ to circulate and obfuscate true problem definition

In my work over the past five years, since I’ve given up having any operational responsibilities, I’ve seen how easily we can all lapse into solution focused work.

Unlike Einstein, when given an hour we often spend – at best – 5 minutes on the problem and the remaining 55 minutes solutionizing.

Our+Approach+To+Design++-+Simon+Penny+(7)

As Simon Penny writes in a great piece for Bromford Lab “when we talk about design we are using it as shorthand for 4 key elements of problem solving activity – discovery, definition, development and delivery. That means that at least half of what we do is based on truly understanding and defining the problem we are trying to solve and the other half is based on developing, testing and iterating ideas into a scalable solution. In short, we think about design as a whole end-to-end process”.

So rather than seeing problem definition as a one off activity, it’s now what we do all the time, objectively helping the organisation to solve the right problems and resist its inbuilt solutionist behaviours.

The five step approach to problem definition

1 – Establish the need for a solution

This sounds completely obvious but just because you’ve seen or thought of a solution doesn’t necessarily mean one is actually needed.  Starting with a high level question of “What problem are we trying to solve here?” and being very clear about it is a good starting point. You’ll usually come up with a lot of further questions – so don’t even bother trying to fully define the problem at this point. There may not even be one.

2 – Match the problem to organisational strategy

Even if you’ve established the need for a solution – it may not be one your organisation is best placed to provide. No organisation, large or small, can manage more than five or six goals and priorities without becoming unfocused and ineffective. The best organisations don’t try and do everything. They focus on trying to solve fewer problems, in better ways.

That involves finding your ‘irreducible core’ of services and then constantly refining and innovating against it.

It also means saying no to trying to solve everyone else’s problems.

3 – Explore the context to the problem

Often your problem will be one that the organisation has tried to resolve before. We rarely stop to reflect on why our previous efforts failed and what we should avoid this time.

If the problem is industry wide, it’s crucial to understand why the market has failed to address it, and whether it is even feasible.

4 – Writing the problem statement

Now you’re ready to write something down. A problem statement should describe the undesirable gap between the current-state and future-state. It should avoid any mention of a solution and be no longer than a tweet.

5 – Initial prototype solution

As Simon Penny also wrote here , prototyping can also be used to test an idea; not by creating a smaller working version of a service or product, but by testing the many different component parts or even thinking abstractedly in order to start to uncover what it might feel like to use the service or product. This can be tested – with people – to help you further refine the problem. Thinking of prototyping as part of the problem definition helps you avoid falling in love with your first idea.

All of this takes time , and this is why our organisations are bad at it.

Falling in love with the problem , rather than the solution means:

  • Accepting your first idea could be the worst idea – and might be wrong
  • Being brave enough to pull the plug when you realise you’re not the ones to solve it
  • Becoming comfortable with failure – as the only way you’ll ever explore a problem worth solving is through a ‘try, fail, learn and try again’ model.

When you truly fall in love with problems, not solutions, you not only stand a better chance of solving them. You also start unlocking a path to a better, less complicated organisation.


Footnote:

By the way – it is possible to argue you can solve problems without first defining them.

I’m currently travelling and it’s inconceivable that we once had to carry suitcases. The first wheeled luggage was invented by Bernard Sadow because he had a bad experience in customs returning from Aruba. Struggling to carry his heavy luggage, he observed an airport worker effortlessly rolling a heavy machine on a wheeled skid. The rolling suitcase was born.

That’s not how our organisations work though. If the eureka moment was so common place we’d have solved most of our most intractable problems by now!

Know Your Customers, Just Never Ask Them What They Want

We do not really know what our potential users will really respond to, what they will understand or what they’ll hate until we really see them using it –Jonathan Courtney

1-694br3lur9zvingnknzxuq

If you are working on any new service change or product there’s one question I guarantee will be asked of you at some point:

“What do your customers think of this?”

The thing we never say – but we need to be brave enough to is this:

“We haven’t asked them – it would be a complete waste of time”.

Despite no evidence of any real impact, each year millions of pounds are spent across the social sector on market research, focus groups, and ‘coproduction’.

At best it’s well intentioned paternalism , at worst a cynical tick box exercise.

95% of products launched this year will fail – and it won’t be for lack of customer involvement. Many of these will have asked people to articulate what they want whilst failing to actually get to the core of what they need.

It is difficult for us as users , of any service , to think in abstractions or envision a new concept.

There is little evidence that we can even predict our own behaviour. We don’t necessarily know why we make decisions.

When anyone proposes a change – even humdrum day to day changes (think self-serve check outs in supermarkets , or charging people for plastic bags) – we don’t react rationally.

Our status quo bias, the tendency for us to lean towards doing nothing or maintaining our current or previous decision – is a strong reason for never asking customers what they want. Unless you want your business to stand still.

Customers often don’t know what’s good for them.

If you ever go to an airport here’s a quick experiment. Look at the queue of people checking in manually versus the queue for people who’ve checked in online and are using bag drop.

Despite all the benefits (huge time saving, plus the airline can’t close the flight and move on without you) people are disposed to stick to what they know.

These are probably the same strange group who applaud the pilot and crew when the plane touches down, simply for doing their job and not killing you.

Asking them to design your next service would be catastrophic. They’d request a lot of features that they would never use.

As Jason Fried has said – a great question to ask ourselves is  what are people going to stop doing once they start using our products or services?

That’s how Amazon and Google have conquered the world – not by surveying us to death – but by understanding our problems and taking them away one day at a time.

The challenge is understanding the problem better than your competitors and then road testing solutions. As Jonathan Courtney writes, the useful data comes not from research, not from surveys – but from the first user tests.

Every pound we put into asking customers what they want is basically wasted.  My aspiration at Bromford is for us to the become the best organisation at understanding the problem, before deploying rapid experiments to prove or disprove any solution.

Our customers have big problems to solve, the social sector faces unprecedented challenges – and we simply don’t have the time anymore.

 

Have you really got the time to be distracted by what customers think they want?

henry_ford_cph-3b34530

It’s a great line but there’s no evidence that Henry Ford ever said this. It never appeared anywhere until about 1970.

A better quote , and one he did say in his 1922 book, is this:

“I will build a car for the great multitude. It will be large enough for the family, but small enough for the individual to run and care for. It will be constructed of the best materials, by the best men to be hired, after the simplest designs that modern engineering can devise. But it will be so low in price that no man making a good salary will be unable to own one – and enjoy with his family the blessing of hours of pleasure in God’s great open spaces.”

Ford understood his customers aspirations before they did.

Knowing our customers is about a deep understanding of the day to day problems they face and the opportunities they haven’t even begun to realise.

You won’t get that from your next customer workshop.