Behaviors That Stick
Practice: The Assumption Audit

Name the assumption that could break your recommendation, before someone else finds it.

The Hook

Every recommendation rests on assumptions. The ones you haven't named are the ones that will surprise you.

DefaultBehavior SpectrumEmbedded
01
SIGNAL

Are they catching it in time?

A significant recommendation is about to go out. Note whether you're reviewing a draft, watching the pitch live, or hearing about it after.

You review their deck the night before — three assumptions, none named yet. A signal, not yet confirmed.
02
REDIRECT

Is the new or default action running?

Did they name their key assumptions and address the riskiest one, or present without examining what it depends on? Can't tell, ask. Can tell, reinforce it.

They mention adding a fallback after naming the API-timing assumption. You reinforce it: “Do that again.”
03
SHIFT

Is this a pattern, or one good moment?

Assumptions get named and tested before the recommendation goes out, not after pushback finds them. Check this holds across pitches.

Third proposal this month with assumptions named up front — not luck, a pattern.
04
EMBEDDED

Is it showing up unprompted?

No prompting needed. They audit their own assumptions by default, and pushback rarely catches them unprepared.

A stakeholder says, “Her recommendations always hold up.” You name it: “That's your reputation now.”
↺ Repeat until Embedded
Before (Old Pattern)
After (Embedded)
  • The Practitioner presents the recommendation.
  • The weak assumption surfaces when someone else finds it.
  • The Practitioner names the assumption that would change the answer.
  • It's addressed or disclosed before anyone has to ask.
The Goal

Consistent evidence assumptions are named and tested before the recommendation goes out — without a reminder.