Needs vs. Solutions: Why Stakeholders Confuse Them and What to Do

The single most common problem in discovery interviews is not reluctant stakeholders or vague answers. It is premature solutions. People who work close to customers tend to describe what customers need in terms of what the organization should build — and the two are not the same thing.

This is not laziness or bad thinking. It is a natural consequence of working in a solution-delivery context. When your job is to build or improve products and services, you tend to perceive customer problems as opportunities to apply your existing toolkit. The solution arrives before the need is properly understood.

What This Looks Like in Practice

A stakeholder says: "Our customers need a better onboarding email sequence."

This sounds like a customer need. It is not. It is a proposed solution to an unstated need. The underlying need might be: "Customers need to understand what they will gain from the product before they invest significant time in it." Or it might be: "Customers need to know what to do first when they arrive in the product."

These are different needs, and they could be addressed by different solutions — a redesigned onboarding flow, a better in-app tooltip, a one-page quick-start guide, or a more focused signup questionnaire. The email sequence is one possible answer. It is not the need itself.

When a journey map is populated with solutions rather than needs, it becomes a premature feature list. It forecloses design options before the problem space has been properly explored, and it makes it harder for teams to collaborate because each team's proposed solutions are implicitly competitive rather than complementary.

"Instead, gently redirect: 'What is the customer trying to accomplish? What is the underlying need here?'"

The Redirecting Questions

When a stakeholder offers a solution, two questions reliably surface the underlying need.

"What is the customer trying to accomplish?" This moves the conversation from the proposed intervention to the customer's goal. It shifts the frame from "what should we build?" to "what does the customer need to succeed?"

"What is the underlying problem this solves?" This surfaces the pain or friction that motivated the solution proposal in the first place. Often the stakeholder knows the pain intimately — they have seen it in customer service tickets, heard it in sales calls, observed it in user testing — but they have already jumped to their preferred solution without articulating the problem explicitly.

The goal is not to dismiss the proposed solution. Solutions proposed by people close to customers often contain genuine insight. The goal is to record the need first and connect the solution to it — so that the relationship between problem and response is visible on the map.

Why Needs-First Mapping Produces Better Solutions

When the journey map is organized around needs rather than solutions, two things happen that do not happen otherwise.

Multiple solutions become possible. A clearly articulated need is an open invitation. Any team that understands the need can propose a response. When the map shows "customers need to understand the sustainability claims of the products they are considering," the marketing team, the product team, and the content team can each identify how their capabilities contribute — rather than waiting for a single designated team to own the problem.

Solutions from different teams become compatible. When teams start from the same need, their independently developed solutions tend to address different aspects of the same problem. This creates natural opportunities for combination rather than competition. Emerging solutions that address the same underlying need can be merged into a single coherent Big Solution rather than remaining as parallel, duplicative efforts.

The Map Tells the Difference

On a well-structured journey map, needs and solutions live in separate lanes for a reason. Needs belong in the research layer — they are what the customer requires. Solutions belong in the design layer — they are what the organization proposes to deliver.

When solutions migrate into the needs layer, the map loses its ability to support creative design. Teams read the solutions as requirements and stop exploring the underlying problem. The map confirms existing plans rather than challenging them.

Keeping needs and solutions distinct is not a methodological nicety. It is the mechanism through which journey work produces options rather than just validating decisions that have already been made.