Rubber duck debugging - explaining a problem out loud, step by step, to an object that knows nothing - is the most underused diagnostic tool in product work. Engineers use it to find bugs. It works as well on a stalled roadmap, a conversion drop or a team argument, because saying the problem out loud exposes the gap in your own reasoning.

The time I nearly paid a branding agency $20K to rename nothing

A few years ago, one of my teams called an emergency meeting. Conversions were dropping and bounce rates were rising, and we decided we had a messaging problem. The ideas escalated quickly: new positioning, new pricing, a new audience, maybe a new company name. I came close to hiring an expensive branding agency that week.

Then a junior developer picked up the office rubber duck, walked to the whiteboard and said, "I'm going to explain what's wrong to the duck." She walked through it as if teaching a child: why the landing page was confusing, what users expected, what success looked like. By the end of her five minutes we could all see it. The call-to-action copy was bad. We rewrote two lines, tested them, and bounce rate dropped 30%.

That stuck with me.

Most "big problems" are badly explained ideas. Give them five minutes with a duck before you hire anyone.

Why saying it out loud works

Thinking feels fast because it lets you skip steps. Your head can hold partial ideas, vague beliefs and gut feelings side by side without noticing they do not connect. Speaking forces them into order, and the gaps show. You find out you are solving the wrong problem, that you skipped a step, that you assumed something you never checked, or that the answer was obvious and buried under noise.

It is the same effect as explaining something to a new teammate and solving it halfway through the explanation. The teammate is optional.

I saw it in a coaching session with a VP of Product. She started by laying out her complaints about her team, and partway through, with no prompting from me, she realized she had not clearly defined success for them in two months. The conversation ended as an alignment plan instead of a firing plan.

💡
Rubberducking is not just for code. Use it on a roadmap, an activation problem or a churn spike before you call a meeting.

How to rubberduck well

Pick a listener - a duck, a sticky note, a voice memo - and treat it as a student who knows nothing yet. State the problem as you would to a ten-year-old: what is happening, what you expected instead, and where the two diverged. Then tell the whole story out loud, in order, without summarizing. The moment you fudge a detail or jump a step, stop and name it.

When you get stuck, question yourself: what am I assuming here, where could this chain break, has this happened before, and is this a product problem or a people problem. End by choosing one thing to test next rather than a fix. The duck has no ego invested in being right, which makes it easier to pick a small test over a grand solution.

If you manage a team, ask people to do this before they escalate a problem. It saves hours.

Are You a Fit for Coaching?

Get your personalized assessment with 3 minutes.

Get Started >

Where it saves the day

A growth lead told me email had stopped working: click-through rates were falling. Midway through explaining it, she realized many of the emails pointed to pages with nothing useful on them. The email was fine and the content behind it was weak. That insight became part of a framework for growth decisions.

I asked a founder to pitch their product to the duck. Three minutes in, they could not explain the difference between two core features. The product was not sticky because it was confusing, so we re-sequenced the onboarding.

A team I advised had circled one initiative for weeks, and the PM was stuck in their own head. I asked them to describe out loud, with no notes, what success looked like next quarter, next month and next week. They had never defined success beyond a metric, so we turned it into testable outcomes.

When to use it with your team

The duck works best on purpose. Build it into retros and working sessions: one person explains the issue out loud, uninterrupted, while everyone listens. These are the moments where it pays off most:

Situation
What You Hear
How to Use the Duck
Product scope creep
"Well, we also promised to build…"
Ask: what's the core problem? Say it to the duck.
Team stuck in meetings
"We've had 3 brainstorms, no decision."
Someone present the issue to the duck. No interruptions.
Everyone feels overwhelmed
"It's just too much."
Walk through every deliverable to the duck. Spot duplication.
Misalignment with stakeholders
"They don't get it."
Explain their priorities to the duck. Are you sure it's them?
Metrics not moving
"We changed the CTA again."
Talk through the funnel end-to-end. Where's the leak?

It also works on emotions. A CEO I worked with was convinced a competitor was about to take their market. We rubberducked the threat, and by the end it was clear the real driver was fear of falling behind. We focused on learning instead of reacting. When you are stuck emotionally, name what you feel and tell the duck the story you are telling yourself. You can build the habit into your product roadmap process, onboarding, even Slack rituals.

Rubberducking works because it makes you listen to your own logic and catch where it breaks. Before you call the agency, the consultant or the all-hands, give the problem five minutes out loud.