Customers Can Tell Us What They Want (If We Ask the Right Questions)
“If I’d asked people what they want, they would have told me a faster horse.” – Henry Ford
This quote is almost certainly apocryphal, but it persists because it reflects a challenge many practitioners feel: getting reliable customer input is difficult.
I still hear this quote from innovation professionals and leaders. It shows up in conference talks, LinkedIn posts, and strategy meetings. And it points to a genuine problem worth solving.
The challenge comes from something subtle: the phrase “what they want” has two completely different meanings. Understanding this distinction transforms how we approach customer discovery.
Two Meanings of “Want”
When people say “customers cannot tell us what they want,” which meaning of “want” are they using?
Meaning #1: What solutions/features customers want
Meaning #2: What customers are trying to accomplish
It’s true that customers cannot reliably tell us what solutions they want. That requires design expertise and technical knowledge they don’t possess. When we ask them to design products, we put them in an impossible position.
But customers can tell us what they’re trying to accomplish, how they measure success, and where they still struggle given their current product or service solution. That taps into their lived experience and authority; they are the source of truth about this. They do know.
Think about the doctor-patient relationship. Your doctor doesn’t ask, “What treatment do you want?” That would require medical expertise you don’t have.
Instead, your doctor asks, “What’s wrong?” You respond: “I hurt my shoulder lifting weights.” You’re sharing the unique information you have (your symptoms, your goals) so the doctor can apply the unique information they have (diagnosis, treatment options) to help you. This role clarity applies to innovation as well: customers provide their struggles and goals; practitioners translate them into actionable opportunity statements.
Why Jobs-to-Be-Done (JTBD) Matters
In 2005, customers could not have designed Spotify. They could not have asked for “a streaming service with 100 million songs and AI-generated playlists.” That’s a solution, Meaning #1.
But if you had asked a different question like “What about consuming the music you love is frustrating?” customers could have described their struggles:
- “It takes too long to find new music I’ll enjoy”
- “It takes too long to access a specific song I want to listen to”
- “My CDs take up too much space”
The JTBD practitioner would then restate these pain points as preliminary outcome statements to get feedback from the customer, “So, what I hear you saying is that you want to:
- “Minimize the time it takes to find new music you would enjoy”
- “Minimize the time to access a specific song”
- “Minimize storage space required for your music collection”
In collaboration with the customer, the JTBD practitioner can then validate or revise each statement, one at a time, until they accurately state what the customer is trying to accomplish. The customer provides the struggle in their own words. The practitioner re-formats it into outcome language so they are explicit instructions for innovation.
Notice the format of a good outcome statement. Each statement specifies a direction (minimize), metric (time, storage space), and object of control (finding new music, accessing a specific song). This outcome statement structure was developed by Tony Ulwick, founder of Strategyn and pioneer of Outcome-Driven Innovation (ODI).
The key is to define “customer needs” as the jobs (functional, emotional, and social) they want to accomplish, the outcomes they use to measure success, and where they struggle (their unmet needs).
By decoupling needs from solutions, JTBD makes it possible for companies to:
- Uncover customers’ unmet needs in virtually any market in an actionable format
- Obtain explicit instructions from customers about where to focus and what to do to create new value.
- Obtain measurable criteria for evaluating solutions
- Turn the front end of innovation (understanding customer needs) into a repeatable business process
Failing to Separate Needs from Solutions Costs Us
When teams rely on iterating their way to success without this information, they often impede learning by creating a new challenge: confounding the experiments by testing two unknowns simultaneously.
Unknown #1: Do customers consider this need important and unsatisfied?
Unknown #2: Does our solution address it effectively?
When both are unknown, learning from experiments becomes difficult. Did customers not care about the need you targeted, or was your solution simply ineffective at addressing a real need?
Google Stadia illustrates this challenge. Groundbreaking cloud gaming technology. Billions invested. But without validated customer outcomes, the company couldn’t interpret why users weren’t engaging. Was the need not important? Was the solution not addressing it well? The service ultimately shut down a few years after launch when usage and adoption remained below expectations. That’s not good science. Good science isolates the variable you want to test.
With JTBD, teams separate these two questions. First, determine which outcomes customers consider important and poorly satisfied. Then, test whether your solution improves those specific outcomes. Each experiment produces clear learning because you know what you’re testing.
Jobs-to-Be-Done’s Precision Creates Three Capabilities
- Systematic discovery. Discovery becomes a repeatable process that consistently reveals where to focus and what to do to create new value.
- Clear targets for innovation. Instead of “improve the user experience,” teams target “minimize time to complete checkout.”
- Measurable progress. Teams can evaluate every solution feature against specific outcomes customers use to measure success.
This front end of innovation approach complements other innovation approaches downstream by providing the foundation that makes them more effective. When you have validated jobs and outcomes, iteration has clear direction. Experiments test solution efficacy, not whether the need exists.
The challenge isn’t that customers cannot tell us what they want. The challenge is asking them effective questions about what they want to accomplish, how they measure success, and where they still struggle. Jobs-to-Be-Done provides the specific, systematic language that unlocks this capability.
What’s one question you’ve found that consistently gets useful customer insights? I’m always curious what works for other practitioners.
What I’m Working On
I’m collaborating with the Global Innovation Management Institute (GIMI) to create an ISO-certified Level 1 course on Lean JTBD OS™ that makes this approach accessible for innovation professionals and leaders. Lean JTBD OS is an AI-augmented innovation operating system that systematically uncovers customers’ unmet needs through qualitative discovery, transforming innovation from guesswork into a repeatable business process.
Want to be notified when when it launches? Email me at [email protected] and I’ll make sure you are alerted.
