Wants, Needs, and the Strategic Blind Spot: How to Spot What Really Matters
“What are the users’ needs?” is not merely a list of desired features or expressed wants… Each capability, each component, ultimately traces its existence back to fulfilling one or more needs. If not, then its value and necessity must be questioned.
— Simon Wardley
Organizations rarely suffer from a shortage of ideas. Most teams have more features, projects, and “solutions” in progress than they can realistically deliver. The problem isn’t ambition—it’s misalignment.
Too often, we confuse wants with needs. We act on surface-level requests without tracing them back to the deeper outcomes that truly matter. And when we do that, we burn time, money, and energy building things that sound useful… but don’t move the needle.
Why the Difference Matters
Wants are easy to come by. They show up in stakeholder wishlists, customer feedback, internal roadmaps, and executive mandates:
- “We want to adopt microservices.”
- “We want to improve the dashboard design.”
- “We want AI in the product by Q3.”
But unless these wants are grounded in a clear user need—an outcome someone is striving to achieve or a problem they cannot work around—they’re risky bets. They might create value… or they might add complexity without impact.
A Litmus Test
If the thing you’re building never gets delivered, who suffers—and how?
If there’s no meaningful consequence, it probably wasn’t a real need.
What Is a ‘Need’?
Simon Wardley offers a useful lens:
“Needs are not feature requests. They are the fundamental outcomes users require to get their job done—often unstated, and sometimes unrecognized.”
They also evolve over time. A novel feature that delights today may become an expected baseline tomorrow. Understanding needs is not a one-time task—it’s an ongoing activity.
Wardley also suggests we categorize needs in three tiers:
-
Expressed Wants
What users (or internal stakeholders) say they want. These are often superficial, framed as solutions:“I want a mobile app.”
-
Expected Needs
The standard capabilities users assume will be there. Hygiene factors that don’t win hearts, but their absence causes pain:“I expect secure login, search that works, uptime.”
-
Hypothesized Needs
Latent or emerging needs that aren’t yet expressed. These are differentiators—your strategic bets:“We believe users will need real-time insights to make faster decisions.”
Strategically, the pitfall is over-investing in expected needs (because they’re clearer) while neglecting the deeper hypotheses that drive competitive advantage.
Why Organizations Get This Wrong
Many companies are excellent at understanding how things work internally—processes, systems, org charts—but less skilled at understanding the external outcomes they exist to serve.
In practice, this means:
- Roadmaps reflect internal priorities, not user impact
- Teams optimize for handoffs, not outcomes
- Strategy becomes reactive (“what should we build next?”) rather than proactive (“what need should we solve?”)
And when teams are structured around internal capabilities instead of value delivery, the mismatch grows worse. The more disconnected your work becomes from real user needs, the slower and more expensive progress gets.
Mapping to See Clearly
This is where User Needs Mapping comes in.
It’s a practical technique for identifying and visualizing:
- Who your users are
- What they’re trying to achieve
- What needs must be met for them to succeed
- And how those needs connect to the services, capabilities, or teams in your organization
Rather than jumping straight to features or delivery, a user needs map helps you work backwards from need → capability → delivery. It creates clarity. It exposes gaps. It helps you decide why something is worth doing—or not.
An Example: Want vs Need
Let’s say your CTO says:
“We want to migrate to microservices.”
Sounds reasonable. But if you map it out:
- User: Internal product teams
- Need: Ability to make changes independently without waiting on others
- Current friction: Changes to one service cause regressions in others due to tightly coupled architecture
- Consequence: Slower delivery, higher coordination overhead
Now the “want” for microservices becomes a strategy to fulfill a very real need: reducing delivery friction. And that’s a very different conversation.
Making Better Strategic Bets
The most effective organizations don’t chase every want. They build from a clear understanding of:
- What users expect
- What differentiates them
- What assumptions they’re making
Then they align teams, platforms, and investments to meet those needs faster and more reliably than the competition.
Next Steps
If you want to avoid wasting time on wants and start organizing around real needs:
- Explore User Needs Mapping
- Book a short session to explore how mapping could help your teams gain strategic clarity.
- Or try our free “Is this a Want, a Need, or a Hypothesis?” worksheet:
TL;DR Summary
Wants ≠ Needs. Acting on wants without validation creates risk.
Real user needs are about outcomes, not features—and they evolve over time.
Categorize needs as expressed wants, expected needs, or hypothesized needs.
User Needs Mapping helps you trace delivery work back to real needs.
Strategically, needs help guide team design, prioritize investments, and enable faster flow.