If I Had Asked People What They Wanted…

Why customers cannot design your solution — and why listening is not the same as copying requests

At DMCA Solutions, we frequently observe a structural misunderstanding in industrial product development:

Companies assume customers can define what they need.

They cannot.

Not because they lack expertise, but because they operate from a different perspective.

Customers describe symptoms, not root causes.

They describe features, not outcomes.

This is where product strategies systematically fail.

Henry Ford’s often-quoted statement captures the issue well:

"If you ask customers what they want, they will describe incremental improvements on what already exists. Not because they lack vision, but because they are anchored in their current reality."

In industrial environments, this leads to a predictable pattern:

companies build exactly what was requested

— and then discover the market did not move.

The Core Problem: Request ≠ Need

Customer input typically falls into three categories:

• Direct feature requests (“make it faster”, “make it lighter”)

• Workarounds disguised as requirements

• Cost-driven constraints expressed as product demands

None of these represent the actual underlying problem.

They represent the customer’s interpretation of a limitation in their system.

Why New Product Development Fails

Across industrial markets, failure patterns are consistent:

1. Assumption-driven development

   Internal teams rely on intuition instead of structured problem validation.

2. Competitor replication

   Companies react to competitors rather than redefine customer value.

3. Surface-level customer feedback

   Feedback is collected, but not decomposed into root causes.

The result is predictable: technically correct products that solve the wrong problem.

From Requests to Root Causes

Effective product definition requires a shift in questioning:

Instead of asking:

“What do you want?”

Ask:

• What outcome are you trying to achieve?

• What is currently preventing that outcome?

• What has already been tried and failed?

• What constraint is driving this request?

Each request is a signal. Not a solution definition.

The Five Whys in Industrial Context

The Five Whys method is not a tool for explanation — it is a tool for structural clarity.

In most cases, the initial request disappears entirely after 3–5 iterations.

What remains is the actual problem space — often unrelated to the original specification.

DMCA Perspective

In sourcing and industrial solution design, we repeatedly observe the same dynamic:

• The requested specification is rarely the optimal solution boundary.

• Once the underlying constraint is identified, the required solution often shifts significantly

• sometimes away from the original product category entirely.

This is where value is created: not by fulfilling requests, but by redefining the problem.

Key Takeaway

Customers are essential sources of insight.

But they are not solution designers.

Competitive advantage is created by those who translate requests into underlying needs — and then design what customers could not articulate themselves.