Need-Solution Separation¶

Why It Matters¶

When users request features or solutions, they're performing amateur design based on limited knowledge of what's possible. Taking requests literally leads to building what people ask for rather than what would actually solve their problem. Need-solution separation lets you honor users' expertise about their problems while bringing your expertise about solution spaces.

The Key Move¶

When someone requests a specific solution ("add a button for X"), resist implementing directly. Instead ask: "What are you trying to do when you'd click that button?" or "What problem would that solve?" Keep asking until you reach the underlying need - something that doesn't reference implementation. Only then generate solutions, which may or may not resemble the original request.

Classic Application¶

The famous Ford quote (likely apocryphal but illustrative): "If I asked people what they wanted, they'd say faster horses." The need is "get places quicker." The requested solution is "faster horses." Separating these allows considering cars. Real version: Early Ford focus groups did request specific car features, but Ford's team asked why, discovering needs like "feel safe" (leading to safety glass) versus "have a speed indicator" (leading to innovation in instrumentation).

Surprising Application¶

Managing workplace requests. Employee asks for "a raise" (solution). Need-solution separation asks: what's the underlying need? Could be financial stress (need: more money), feeling undervalued (need: recognition), seeing peers earn more (need: fairness), wanting career growth (need: advancement). Each need has different solutions - budget adjustment, public recognition, compensation transparency, promotion path. Taking the request literally addresses only the first possibility.

Failure Modes¶

Over-psychologizing - dismissing what people say they want in favor of what you think they "really" need. Users sometimes accurately specify good solutions, especially domain experts. Infinite regress - asking "why" forever without settling on a need to solve. Ignoring feasibility constraints - finding the "real need" doesn't help if you can't address it. Arrogantly assuming users don't understand their own needs.

Go Deeper¶

Ulwick, What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products; Kujala, "User Involvement: A Review of the Benefits and Challenges" (Behaviour & Information Technology, 2003)