How to Separate Real Needs from Wants, Requests, and Noise

Once a team has aligned on who their users are, the natural next step is to understand what those users actually need. This is where things often get messy, because what teams hear, what they assume, and what users actually need are rarely the same thing.

Most organisations unintentionally blur the line between requirements, requests, preferences, and needs. The language all sounds similar, and teams often treat everything labelled a “requirement” as if it carries the same weight. But the consequences of this confusion are significant: backlogs swell with requests that have no meaningful impact on user progress, valuable work gets deprioritised, and teams end up optimising for wants rather than needs.

I saw this play out recently with a team who received what seemed like a concrete requirement: “We need a dashboard to track X.” It sounded clear, specific, and sensible. The team immediately began discussing chart types, layout, and where the data would come from.

But when we dug into the user’s context, something important surfaced. The user didn’t actually care about a dashboard. What they cared about was not being caught off-guard by sudden changes that required rapid action. The dashboard was simply the solution they had imagined as a way to meet that need.

The moment the team understood this, the prioritisation shifted dramatically. Instead of investing weeks building a dashboard, they delivered a lightweight alert mechanism — something the user could act on immediately. It solved the real need in a fraction of the time.

This is the heart of this stage of the User Needs Mapping process: discover their needs. Not the noise, the requests or the solutions disguised as needs. The real needs.

Why this distinction matters

A need represents the progress a user is trying to make in their world, independent of your product, your architecture, or your organisational constraints. Needs have consequences. If a need isn’t met, something meaningful fails: a deadline is missed, a regulation is breached, a workflow stalls, a risk materialises, or someone’s job becomes materially harder.

A want, on the other hand, is simply the solution the user has pictured. Wants often emerge from habit, preference, organisational bias, or an attempt to simplify the ask for the team. When teams confuse the two, they end up delivering the most polished version of the wrong thing.

This is where the Litmus Test I highlight in my book becomes so useful:

> If the thing you're building never gets delivered, who suffers — and how?

If no one suffers, it’s not a need. If only comfort or preference is affected, it’s not a need. If the consequence is unclear or speculative, it’s probably not a need. But if real progress is blocked: that’s where the need lives.

How teams fall into the trap

It’s easy to see how teams slide into solving for wants:

- A request is framed as a requirement.

- A stakeholder uses confident language.

- A user presents a fully formed solution instead of the underlying problem.

- Someone remembers the last time they built something similar and assumes the same need applies.

- The team feels pressure to be “responsive,” so they take requests at face value.

The irony is that wants usually appear clearer than needs; they are concrete, specific, and neatly packaged. Needs, by contrast, are often messy, abstract, or expressed indirectly. But solving for wants without uncovering needs leads to misaligned work, inflated backlogs, and flow that looks busy but delivers little meaningful progress.

Two questions to uncover real needs

To reveal the underlying need behind any request, ask:

1. Is this a need… or a request shaped by internal bias? Many requests reflect internal preferences, assumptions, or legacy behaviours rather than genuine user value.

2. What progress does the user want to make in their world, not ours? This shifts the focus back to the user’s environment, incentives, and constraints — not the organisation’s.

These questions reveal whether you’re dealing with a genuine need or just a well-worded request. When teams use this lens consistently, they quickly identify which work actually changes user outcomes.

Seeing the difference in practice

A simple way to illustrate the distinction:

Want: “We need a dashboard.” vs Need: “We need to spot changes early so we can act.”

Want: “Give us a button to export this.” vs Need: “We need to share accurate information with partners quickly.”

Want: “Build a feature to automate X.” vs Need: “We need to reduce the risk of errors during handover.”

Want: “Can you add a setting so we can customise this?” vs Need: “We need to complete this task without switching systems.”

The wants are solutions, while the needs are outcomes.

A closing reflection

Understanding and defining real user needs is a pivotal step in the User Needs Mapping process. As I highlight in my book "A clearly defined user need is more than a description of pain - it's a shared lens for more effective decision-making." When teams focus on the underlying progress the user is trying to make - rather than the requests they happen to express - everything becomes clearer: priorities, dependencies, feasibility, and ultimately, value.

If you'd like to explore this distinction more deeply, Chapter 3 of the book expands on this with examples, techniques, and simple tests you can apply immediately. User Needs Mapping: Aligning Teams Around What Matters is out now www.userneedsmapping.com/book