Pick a listener
Who or what can you explain this to, without them trying to solve it?
- A colleague from another team, a friend, a pet, a toy duck
- An outsider makes you explain more, which helps
- Their only job: listen. No fixes, no opinions
Explain your problem, step by step, to a listener who just listens, and hear the gap for yourself.
Rubber-ducking means explaining a problem out loud, in detail, to a listener who doesn't help. Programmers made it famous: stuck on a bug, you walk a rubber duck through your code, line by line, and somewhere in the explanation you hear yourself say the thing that's wrong.
It works far beyond code. Any problem with a hidden snag, such as a schedule that doesn't add up, a process that keeps failing or an argument that won't hold together, can be ducked. The listener can be a colleague, a friend, a pet or an actual toy duck. Their job is to listen, not to fix: the insight has to come from you.
Use it when you've been staring at a problem alone, you're sure something is wrong but can't see what, or you're about to ask someone for help and want to check you can explain it first.
Each loop ends with a smooth explanation or a new snag to look at. Often the snag shows up in the first round.
Choose a part of the diagram or a tab to explore each step.
Who or what can you explain this to, without them trying to solve it?
What does your listener need to know first, before any of the detail?
What happens at each step, and why do you believe it works?
Where did you hesitate, hand-wave or say “and then it just works”?
Does the explanation now run smoothly from start to finish?
The listener does almost nothing, yet the problem gets solved. That's because the real work happens in the explaining.
In your head, a problem can stay a vague blur. To explain it, you have to put the steps in order, define your terms and fill the gaps. Learning research has long found that explaining something, even to yourself, deepens understanding and exposes what's missing.
When you know something well, you skim over the parts you think are fine. Explaining to a listener who knows nothing makes you slow down and say every step out loud, including the one you've been assuming works.
Saying something out loud is not the same as thinking it. You hear your own words, and a contradiction or a hand-wave that slipped past silently suddenly sounds wrong.
A helpful listener often jumps in with their own idea, which pulls you off your train of thought. A listener who stays quiet keeps you in charge, so the insight is yours and you understand the fix.
Find someone willing to listen for ten minutes, ideally someone outside the problem, or use a pet, a toy or an empty chair. Ask them to just listen: no advice, no questions.
Start with one sentence on what you're trying to do, then one on what's actually happening: “The schedule should cover every shift, but Tuesday nights keep coming up short.”
Explain the problem in order, as if to someone who knows nothing. For each step, say what it does and why you think it works. Point at the real thing as you go: the spreadsheet, the code, the form.
The moment you hesitate, hand-wave or say “wait...”, stop and look closely. That's usually the snag. Note it before you lose it.
Fix the problem, test it for real, then explain the whole thing once more. If it now flows, you're done. If not, go round again, or ask for real help with a clear explanation ready.
A listener (person, pet or duck), the actual thing you're working on, and ten quiet minutes. The AI prompt below turns AI into a patient duck that asks short questions, not solutions.
Subject: a community clinic's text-message reminder system. Goal: fewer missed appointments. Constraint: the clinic can't change its scheduling software, only the settings.
Lena, the clinic manager, asked the front-desk receptionist for ten minutes: “Just nod, please. Don't try to fix it.”
She began: “Patients book, the system sends a reminder, they show up. But more of them have been missing appointments since we switched it on.”
She walked through the settings screen by screen: the template, the patient list, the timing. “It sends the text 48 hours ahead, at 9 a.m....”
“...and it says ‘See you tomorrow.’” She stopped. Sent two days ahead, “tomorrow” was wrong. Some patients came a day early; others gave up.
She changed the message to show the actual date and time, sent a test to her own phone, then explained the whole flow again. It held together.
No new software and no meeting, and the receptionist never said a word. Missed appointments fell back within weeks.
Rubber-ducking works because the listener doesn't solve the problem, and AI's instinct is to solve it. With the right prompt, though, AI makes an excellent duck: always available, endlessly patient, and able to ask the short “what happens next?” questions that keep you explaining until you hear the snag yourself.
Tell AI to listen and ask only short questions, never to suggest fixes.
Be my rubber duck. I'll explain a problem. Only ask short clarifying questions. Never suggest a fix.
Have AI prompt you through each step, so nothing gets skipped.
After each step I explain, ask me only: 'What happens next, and how do you know?'
Ask AI to restate your explanation, so you can spot what's missing.
Restate my explanation as numbered steps. Mark any step where I never said why it works.
Still stuck? Turn your explanation into a clear request for a colleague.
Turn my explanation into a short help request: the goal, what happens, and what I've checked.
Describe what's not working, pick a mode, then copy the prompt into Claude, ChatGPT, Gemini or Copilot. In coach mode the AI acts as a patient duck: it listens, asks short clarifying questions and never hands you the answer.
The “Open in” links put the prompt in the web address. If your challenge includes anything sensitive, copy and paste instead.
After the session, click one to copy it, then paste it into the same chat.