We hear what users say. How do we find what they need?

You sit in the room together, and the user says what they want. Someone writes it down. Everyone nods. This feels like progress, but it is only the surface. You have recorded a sentence, not found a need. The mistake is comfortable, because it lets you skip the harder work of asking why. Users describe symptoms in the language of solutions. 'I want a faster export button' is not a need — it is a guess dressed as a request. Your job is not to honor the guess. It is to find the problem the guess was trying to solve. Do this together, not alone. One person hears what they expect to hear. A team, working with discipline, catches what one person misses. Assign the doubt. Argue about it. Then go test it against what the user actually does.

◆ How this problem reads on the two dials

GuidanceKnowledge

More coaching

Some to learn

1:1 with AureliusWith others (a Pod)

Some one-to-one

Practise with peers

The team likely already knows the idea of needs versus wants; what they lack is the shared discipline to apply it, argue it, and act on it in the room.

How the two dials adapt to you →

What’s really going on

The words a user gives you are not the requirement — they are a guess, dressed in the language of a solution. Separate them by asking what problem sits underneath the request. Then test that guess against what the user does, not what they say. Stop collecting quotes. Start hunting causes.

🔒 What you’ll build togetherUnlock by starting

A moveAfter every user statement, write the request on one line and your guess at the real problem on the next — do this before the interview ends, not after.

A moveAsk the user what they would do if this thing didn't exist. Watch for what they describe doing, not what they promise.

A moveAssign one person in the pod the sole job of hunting for the gap between what was said and what was done.

A moveBring your guesses about the real need to the group and argue them before anyone builds anything.

A moveWatch what the user does next week, not what they told you they'd do.

PractiseThe Gap Hunt · a Pod of 4 · 30 min

What changes unlock by starting

You stop building what users ask for and start building what they actually need.
Your team argues about the right problem before it argues about the right solution.
Fewer things get shipped, but more actual problems get solved.
The gap between saying and doing becomes visible to the whole team, not just to one sharp observer.

One object, two jobs: a public answer to a real problem, and — the moment you start the chat — Aurelius’s live plan for your version of it.