Focus on User Needs (Development II)

The biggest mistake organisations make is trying to satisfy their own needs rather than users’ needs. Internal meetings of department heads, who are focused on meeting their own Key Performance Indicators (KPI), descend into battles for power and resources, while meeting the needs of external users, (which is how organisations create value) get lost in melee.

Amazon famously keep an empty chair in meetings to represent end users. If a discussion veers into internal pre-occupations it can be snapped back to what matters by pointing to the empty chair and asking whether end users would care about this. Of course, budgets may have to be done, IT architecture reconfigured and staff assessments completed. But no-one should forget that “the purpose of a business is to create and keep a customer” (Peter Drucker). Get your priorities right!

However, whenever the topic of what users want or need comes up some bright spark will invariably pipe up with that old Henry Ford quote about ‘asking users what they want and faster horses’ (despite no evidence Ford ever said this). At this point the room spits into two: Between those who argue that we have to find out what users need before acting; and those who argue that, as the experts, we should just get on with making what users need. So, who’s right?

Let’s break this one down.

If you’re bringing something new to the world (or just to your market), something users have never seen before, they’re not going to say they want it because they don’t what it is. If users have never seen a car before they’re only going to be able to ask for a faster horse. But if we ask them what a faster horse for (answer: to get from A to B quicker) and ask them what else they might want (possible answer: getting there cheaper and more reliably) we can present our new car as having multiple horse power (making it faster), only needing to be ‘fed’ when it’s been used and not every day (making it cheaper), and never running off (making it more reliable). Potential users can now see how a car (something they’ve never seen before) gives them what they want. Here we’ve really listened to what users want and have offered them a new and innovative way to satisfy that desire.

Yet Ford didn’t invent the motor car (that was Carl Benz in 1886). By the time Ford was selling his model-T cars 20 years later users may have decided that they did want a car (due to its speed, cost and reliability benefits). However, they may have found the cost of a new car prohibitive and the scarcity of petrol stations to ‘feed’ it a concern. What these users needed was a way to overcome these pain points. Therefore, we might offer them financing options so payments could be spread out over time and we could lobby the mayors of local towns to invest in petrol stations so citizens used cars instead of horses (which gave mayors what they wanted — streets without piles of horse manure everywhere). Ford did both of these things. He listened to what users needed and helped them get what they wanted (a car that’s faster, cheaper and more reliable than a horse).

Therefore, you should:

1. Listen to what users want if you’re bringing something never before seen in your market (ex, a new form of transport, like Benz did) to make sure you’re satisfying real desires people have
2. Listen to what users need and remove the pain points that stop them getting what they want (ex, like Ford did) if current solutions are too expensive, unreliable or, in some other way, risky.

So the next time someone misquotes Ford at you, (so they can get back to their internal battles) post out that listening to users is always beneficial. User wants are enduring (we always want to get from A to B conveniently, affordably and reliably) and focusing on wants are your best guide to long-term innovation efforts. User needs do change with the times (we need a faster horse, a cleaner car, or more reliable public transport) and focusing on needs are your best guide for how to adapt your offerings in the short-medium term. The alternative, assuming users are idiots who would ask for a faster horse when cars are available is a risk you are probably best advised not taking.

This principle — focus on user needs —is part of the Wardley Mapping method for helping organisations communicate more clearly, develop effective teams, improve operations, accelerate learning, lead more decisively and structure themselves to deliver better results. To learn more get in touch with me at marcus@powermaps.net or visit powermaps.net.