Do not try to walk on someone else’s shoes. Instead, try to understand their motives with empathy.
People sitting at the table in an office with laptops in clear weather (image: Khalid Odeh @ scop.io)
“If I had asked people what they wanted, they would have said faster horses.”
— not Henry Ford
The famous quote, wrongly attributed to Henry Ford,¹ highlights the peril of asking users to define solutions rather than describe problems, and the risk of asking the wrong questions when identifying users’ pain points. It also makes clear how language shape requirements.
The limits of my language mean the limits of my world
Motivation is multilayered. Most people are aware of the superficial motives for their actions — like grabbing a jacket because it’s cold — but not so much the deeper intentions behind their specific choices, such as habitual preferences, functionality considerations, social pressure, and emotional relationships.
Describing Jobs to be Done, Bob Moesta² discusses how difficult it is for customers to transition without a push away from their current state. It is when inconvenience outweighs convenience that users seek alternatives that will make them more successful. In order to convince consumers to change, we must erode barriers of habit while promoting the suitability of new choices. This is as much true for individual consumers as it is to enterprise companies: the decisions behind purchasing a new software for a team or buying a new cooking utensil are not as different as they might seem at first. But in order to capture users’ needs and be able to reduce the friction between their current option and us — or to increase the friction between us and competitors for our existing users —, we must first grasp how people use words to describe their pain points. As noted by psychology Professor Bernard Guerin:³
“Our talking and writing are controlled by the audiences and discourse communities around us. To understand our use of ‘words’ we do not need to know people’s cognitive or brain processes, we need to understand what was going on in the worlds of these people and what they were accomplishing with those words.”
We like to think we use language very clearly and objectively, and (naturally) if others don’t understand us then the fault lies in them: we chose the best words and communicated precisely what we intended.
Only, that’s not true. This quote attributed to the late advertising tycoon David Ogilvy makes it quite clear why understanding the context in which people communicate and the job done by the words they use is so central to building effective solutions.⁵
“The trouble with market research is that people don’t think how they feel, they don’t say what they think, and they don’t do what they say”
Which is to say, we need to understand what is the job done by the words used by people in order to build solutions to their problems.
Job-ception
Conversations occur between the factual and the ideal — between the actual problem and the perceived problem. The language used in framing questions is crucial, since we can’t control how other people make distinctions or use language. We should focus on what is under our control: our choice of words, interpretation, and how responses lead to meaningful actions.
A ragged, broken old triangle (image: Bernard Guerin)
If you were asked what do you see above?, you’d likely answer a triangle. But if asked to draw a copy of it, you’d sketch three angled corners and a tiny bit of straight line near the one on the bottom right. The only difference between these results is the language used in the prompt.
People participating in a conversation make their own assumptions about what was meant from what was said, and they may come out with very different understandings of what actually needs to be done. When defining qualitative goals⁴ based on our observations from user interviews, it is important to keep in mind we are always choosing an interpretation of the events.
If product teams can’t agree on the interpretation of those interviews, we usually embark on a series of fiddly conversations to try and come to an agreement: meetings are scheduled, documents are written, comments are added, clarifications are requested. We schedule more meetings in order to generate further alignment and ensure sync and type millions of characters into files and messages and notes. We create more words to try to clarify the initial words, but talking about things won’t solve whatever issues users have with them. We have actually to go and do stuff to change them.
(I know, sucks, right?)
…but moooooom!
Hence assigning designated drivers for the initiatives we work on: someone tasked with drawing the line in the sand for the specific qualitative goals and their requirements. A designated driver is someone empowered to decide what good factually looks like.
Action speaks louder than words but not nearly as often
Language is a powerful tool for communication and influence. Without it we don’t get buy-in, and so fail at combining the efforts of larger groups towards a common goal. Without language, complex tasks become borderline impossible to complete.
But without converting language into action — without converting that buy-in into an actual plan which we then execute — we can’t cause change to happen. Anything that cannot be accomplished at the individual level grows out of reach.
Ask any software developer what is the one thing they wish they could change in their lives in order to improve delivery, and more often than not you’ll hear less meetings. It’s not because developers don’t understand the importance of buy-in and alignment. Rather, this is a critique of our inefficiency at making meetings and documentation meaningful. Being the ones responsible for the delivery, developers have perhaps a clearer view on how much excessive talk hampers productivity.
Language is unable to single-handedly cause anything into existence — you don’t ‘get’ anyone to do anything, as Matt LeMay⁶ puts it. Trying to do that means handing over success definitions to others and will only make you hostage to them. And if (when) definitions change (because reasons), you’ll be doomed either to failure or to a new list of features to build.
LeMay proposes we should stop asking questions like how do we get executives to stop handing us lists of things to build? and instead ask how do we help executives understand the trade-offs that will best achieve their goals? This gives us more control because it is within our power to decide what we can or can’t, will or won’t do to help. In turn, doing so preserves our ability to set our own goals. In his words, “if you don’t know what you’re trying to achieve, all you can do is have these fiddly conversations.”
You mean to say I need to help them to help myself?
For product teams, understanding user and customer motivations is vital, but we must also consider motivations within our business. Our role includes assisting decision-makers in understanding what is achievable, positioning the business strategically, and promoting overall value. Saeed Khan⁷ defined it so:
“Product Management is about driving product success, not delivering product features.”“… far too many companies struggle with business success because they don’t have a clear connection between what they do in Product and what they want to do in business.”
Connecting product activities with business objectives is essential for success. It is the connection between the ideal and the factual. To that end, product teams must strip communication down and focus on the essentials⁸ so that a shared qualitative definition of success can arise. After agreeing on what is under our control, we can proceed to align with other teams, negotiate with stakeholders, and maintain agility for short-term deliveries. By focusing on our control points, we reduce friction:
between product teams, increasing delivery quality and velocity.between product and business, improving value delivered to customers and users.between business and investors, multiplying gains to society.
Notes
¹ Patrick Vlaskovits @ Harvard Business Review, Henry Ford, Innovation, and That “Faster Horse” Quote, Aug 29, 2011.
² Bob Moesta @ Lenny’s podcast, The ultimate guide to JTBD | Bob Moesta (co-creator of the framework), Aug 24, 2023.
³ Bernard Guerin @ Holistic Elephants, How the original argument for beginning cognitive psychology was wrong, Aug 10, 2019.
⁴ Ivan Monteiro @ Medium, Guilty reading, Jan 5, 2024.
⁵ Tom Wood @ Foolproof, User research and design: Three old chestnuts cracked, Aug 2, 2017.
⁶ Matt LeMay @ UX Brighton 2022, You don’t “get” anyone to do anything, Mar 16, 2023.
⁷ Saeed Khan @ Medium, Product Management: It’s a System for Business Success, not Product Features, Jul 19, 2023.
⁸ One page, one hour summarizes this brilliantly: “we spend way too much time working alone to make our deliverables impressive, and not nearly enough time working together to make them useful.”
On understanding one’s real motivations was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
