Ask a customer what they want and they'll describe a slightly better version of what they already have. That's not because they're unhelpful, it's because human imagination is anchored to the present. The needs that actually move markets are usually the ones the customer can feel but can't name. The work is learning to surface those.

The quick version

  • A need is a problem, not a feature. People "hire" a product to make progress in a situation, describe the progress, not the gadget.
  • Stated needs are the easy half. The valuable half is latent needs: real, but the customer hasn't articulated them, often because they've quietly accepted a workaround.
  • Asking isn't enough, watch. Interviews surface what people say they do; observation surfaces what they actually do, and the gap between is where unmet needs hide.
  • Not all needs count the same. Some delight, some merely prevent anger. The Kano model sorts them so you don't over-invest in the wrong ones.

The idea in depth

"Customer need" sounds simple until you try to write one down. Is "I want a faster laptop" a need? Not really, it's a feature request, framed by what the customer already knows exists. The need underneath is something like "I lose my train of thought when the machine stalls." One is a spec; the other is a problem you could solve a dozen ways. Getting from the first sentence to the second is the whole discipline.

Needs are jobs, not products

The most durable reframe comes from Clayton Christensen and colleagues in "Know Your Customers' Jobs to Be Done" (Harvard Business Review, September 2016): people don't buy products, they "hire" them to get a job done in a particular circumstance. Their example is a fast-food chain studying milkshake sales. Surveys produced tweaks that moved nothing. Then researchers watched when shakes sold, and found a morning spike from solo commuters. The job wasn't "a tasty dessert." It was closer to "occupy a boring one-handed drive without leaving me hungry by 10 a.m." A thicker shake served that job; a banana didn't.

The same article cites a McKinsey poll: 84% of executives called innovation extremely important to growth, yet 94% were dissatisfied with their own innovation performance. The gap, the authors argue, comes from measuring customers, age, income, attitudes, instead of understanding the job they're trying to do.

In practice: before you write a single feature, write the job as a sentence in the customer's voice, a verb, an object, and the circumstance. "Help me ____ when ____." If you can't fill that in from real evidence, you don't yet understand the need; you understand the product.

An honest limitation: jobs-to-be-done is a lens, not a measurement system. It tells you where to look, not how to prioritise. Critics note the "job" can be defined so loosely that almost any story fits it after the fact. It earns its keep at the discovery stage and needs a sharper tool once you're ranking opportunities.

Turn the job into measurable outcomes

That sharper tool is Anthony Ulwick's outcome-driven innovation, set out in "Turn Customer Input into Innovation" (Harvard Business Review, January 2002). Ulwick's insight is that customers are bad at proposing solutions but reliable at telling you the outcomes they're trying to achieve, if you ask in outcome language rather than feature language. He frames needs as metrics: a direction of improvement, a unit of measure, and the thing being measured. "Minimise the time it takes to detect the source of a payroll error," for instance, instead of "I want better reporting."

flowchart TD
    A(["A customer in a situation"]) --> B(["Job to be done
the progress they want"])
    B --> C(["Desired outcomes
measurable success criteria"])
    C --> D(["Unmet outcomes
important but poorly served"])
    D --> E(["Opportunity to design for"])
    A -. "what they ask for" .-> F(["A feature request"])
    F -. "anchored to today" .-> A
From situation to opportunity: feature requests loop back to the present; outcomes point forward. Leaders Loop

Once needs are written as outcomes, you can survey customers on two scales, how important each outcome is, and how satisfied they are today. Outcomes that score high on importance and low on satisfaction are your underserved needs: the map of where to innovate. This is also the bridge to Jobs-to-be-Done analysis as a repeatable method rather than a one-off story.

So do this: rewrite your top customer "needs" as outcome statements (direction + metric + object), then score each on importance and current satisfaction. Sort the list. The high-importance, low-satisfaction rows are where attention and budget belong.

The limitation worth naming: outcome surveys are only as good as your outcome list. If you never surfaced an outcome, because it's latent, and nobody mentioned it, it won't appear on the survey to be scored. The method ranks the needs you already found; it doesn't find the hidden ones. For that you need to leave the desk.

Latent needs live in behaviour, not answers

This is the heart of the topic. A latent need is real and unmet, but the customer hasn't articulated it, usually because they've absorbed a workaround so thoroughly they no longer see it as a problem. The classic guidance comes from Dorothy Leonard and Jeffrey Rayport in "Spark Innovation Through Empathic Design" (Harvard Business Review, November–December 1997). Their point is blunt: customers' ability to guide development is limited by their own experience and imagination, so you have to identify needs they don't recognise, by watching them use products in their environment, not by asking. They lay out a five-step routine, observe, capture, interpret, brainstorm, prototype, and the signals to hunt for are workarounds (a sticky note on a screen), misuse (a tool bent to a job it wasn't built for), and friction the user has stopped complaining about because they assume it's just how things are.

The most valuable need is the one the customer has quietly given up on ever having met.

The move: spend an hour watching three real customers do the actual task, in their actual context, without your slides. Note every workaround and every hesitation. Each one is a latent need wearing a disguise. This is the same instinct behind usability & guerrilla testing, cheap, fast, in the field.

The limitation: observation is powerful but seductive. It's easy to over-read a single quirky user, or to project the solution you already wanted to build onto an ambiguous behaviour. Observation finds candidate needs; it doesn't prove they're widespread. Triangulate what you see against the outcome data and a larger sample before you bet on it.

Not every need carries the same weight

Even once you've found a set of real needs, they aren't equal. Noriaki Kano and colleagues showed this in their 1984 paper "Attractive Quality and Must-Be Quality" (Journal of the Japanese Society for Quality Control, vol. 14, no. 2). The Kano model sorts attributes by how they shape satisfaction. Must-be needs cause fury when absent but no joy when present, nobody praises a hotel for hot water, but they won't return without it. Performance needs scale linearly: more is better, and customers will pay for them. Attractive needs delight when present but aren't missed when absent, where latent needs and real differentiation usually live.

flowchart LR
    A(["A discovered need"]) --> B{"How does it
affect satisfaction?"}
    B -->|"Absent = anger,
present = neutral"| C(["Must-be
get it right, don't over-invest"])
    B -->|"More is
linearly better"| D(["Performance
compete on it"])
    B -->|"Present = delight,
absent = no harm"| E(["Attractive
where latent needs pay off"])
The Kano model: sort needs by their effect on satisfaction before you decide what to fund. Leaders Loop

So sort them: tag each need you've found as must-be, performance or attractive. Pour just-enough into must-bes (failing one is fatal, exceeding it is wasted), compete deliberately on performance needs, and reserve real ambition for one or two attractive needs, the place a latent need becomes a reason to switch.

The limitation Kano himself flagged: categories drift. Today's delighter becomes tomorrow's expectation. A phone camera was once attractive; now its absence is unthinkable. So the classification is a snapshot, not a permanent truth, re-run it as the market matures.

A worked example

Picture a mid-sized firm selling accounting software to small builders and tradespeople. (The figures here are illustrative, a composite to show the method, not a real client.) Support tickets are full of one request: "add more report templates." The obvious roadmap writes itself, ship a dozen new templates.

Instead the team runs the playbook. First, the job: they sit with six tradies and find the real situation isn't "I want reports." It's "at 9 p.m. after a 10-hour day, I need to know if I actually made money on the Henderson job, fast, on my phone, without a bookkeeper." That's the job to be done.

Next, outcomes. Rewritten as metrics, the needs become: minimise the time to see profit on a single job; minimise the steps to do it from a phone; increase confidence the number is right. An importance-vs-satisfaction survey of 200 customers shows the first scores 9/10 important and 3/10 satisfied, badly underserved. "More templates" scores 5 and 6: a real but weak need.

Then, observation. Watching customers reveals the latent need nobody filed a ticket about: builders were exporting data into a spreadsheet on a laptop in the van, because the phone view buried per-job profit three taps deep. They'd stopped complaining, it was "just how it worked." That workaround is the unmet need made visible.

Finally, Kano. More templates: a performance need, mildly useful. A one-tap, per-job "did I make money?" card on the phone home screen: an attractive need that would delight, and that no competitor offered. The team ships the card instead. None of the four tools alone would have got there: the job framed the problem, outcomes ranked it, observation found the hidden version, and Kano said which one to build. That sequence, and how it feeds a wider view of who you serve, connects directly to needs-based segmentation.

Frequently asked questions

What's the difference between a stated need and a latent need?

A stated need is one the customer can articulate if you ask, "I want it faster." A latent need is real and unmet but unspoken, usually because the customer has accepted a workaround and no longer registers it as a problem. Stated needs come from interviews and tickets; latent needs come from watching behaviour and noticing the gap between what people say and what they do.

If customers can't articulate latent needs, why talk to them at all?

Because talking and watching answer different questions. Conversation tells you the circumstance and the job, why someone is even in the market. Observation tells you where today's solutions quietly fail. You need both: the interview frames where to look, the observation finds what's hidden there. Skip the talking and you'll observe without knowing what matters.

Is this the same as jobs-to-be-done?

Jobs-to-be-done is one tool in the kit, not the whole kit. It's the framing move, defining the need as a job rather than a feature. Outcome-driven innovation makes that measurable, empathic observation finds the latent version, and Kano prioritises. They stack; treating jobs-to-be-done as the entire method is a common mistake.

How many customers do I need to watch before I trust what I've found?

For finding candidate needs, very few, even a handful of observations surfaces most major workarounds, because friction tends to be shared. For betting on one, more: confirm that what you saw shows up at scale through outcome surveys or a larger sample. Observation generates hypotheses cheaply; it doesn't validate them.

Doesn't this all just slow product teams down?

It front-loads a small cost to avoid a large one. The expensive failure is shipping the thing customers asked for, more templates, and watching it move nothing. A few hours of watching real users is far cheaper than a quarter spent building the wrong feature well.

Related in the Toolkit

Where to go next