How do I separate what users say from what they need?

You can run the call. You ask good questions, people talk, you fill pages of notes. The trouble starts after — when the user's exact words slide into your spec dressed up as requirements, and no one checks whether they belong there. A request is not a need. It is what the need sounded like coming out of someone's mouth under time pressure, in their own language, shaped by whatever they've seen before. Your pod's job is to find the problem underneath — not to transcribe faster. This is not a flaw in one person's listening. It is a habit a team either builds together or fails together, because the quote that slips through unchecked becomes the feature no one can explain later.

◆ 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 distinction itself is simple to teach, but the slip happens in daily practice with a team, so building the shared habit matters more than explaining the idea.

How the two dials adapt to you →

What’s really going on

A user's words are a symptom, not a diagnosis. Every time someone on your pod reports a quote, make them also name the problem beneath it — in one sentence, before any requirement gets written. If no one can name that problem, the discovery isn't finished, no matter how good the notes look.

🔒 What you’ll build togetherUnlock by starting

A moveAfter every discovery call, write the user's exact quote. Below it, write one sentence naming the problem that made them say it — before you write a single requirement.

A moveBring that write-up to your pod and ask one teammate to challenge the gap between the quote and the problem you named.

A moveWhen you report findings to anyone, lead with the problem, not the quote. Reverse your usual order.

A movePick one requirement already sitting in your backlog. Trace it back to its original quote. If you can't find the problem behind it, remove it or go find the problem.

A moveChoose one call this week to run with a partner whose only job is writing down problems, not requests. Compare your two sets of notes after.

PractiseQuote vs Problem · a Pod of 4 · 30 min

What changes unlock by starting

You can show, for any requirement, the problem it answers — not just the quote it came from.
Your pod catches requirement-creep before it reaches a spec, because someone else checks your translation.
Stakeholders start asking 'what problem' instead of 'what did they say,' because your reporting trained them to.
You stop mistaking a loud request for an important one.

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.