Exercise 3: Why a Stale Expectation Is Often Worse Than None — Possible Solution ==================================================================== WHAT HAPPENS WITH NO EXPECTATION SET AT ALL ------------------------------ A user given no timeframe at all has genuine uncertainty (per this chapter's own reasoning in earlier exercises), but no specific promise has been broken - their frustration, if it builds, comes purely from not knowing, without the additional sting of having been told something that turned out to be wrong. WHAT HAPPENS WITH A STALE, UNUPDATED EXPECTATION ------------------------------ Per this chapter's own warn-box, "'you said 10 minutes, it's been an hour' adds a broken promise on top of the original delay." Here, the user isn't just uncertain - they were given a specific, concrete commitment that has now visibly failed. The delay itself is the same whether or not a timeframe was given, but the stale case adds a second, separate injury: the technician's own word turning out not to be reliable. WHY A BROKEN PROMISE IS A DIFFERENT, ADDITIONAL PROBLEM ------------------------------ An unmet expectation doesn't just fail to prevent frustration about the delay - it actively creates a new, separate reason for frustration: distrust in whatever the technician says next. Once one specific promise has visibly failed, the user has real, direct evidence to doubt the next timeframe or explanation offered, even if it's genuinely more accurate this time. WHY THIS ISN'T AN ARGUMENT AGAINST SETTING EXPECTATIONS IN THE FIRST PLACE ------------------------------ The problem isn't that an expectation was set - it's that it was left stale rather than actively updated once circumstances changed. Per this chapter, expectations "still need to be actively updated if they change" - the fix is a follow-up update ("this is taking longer than expected, here's why, and here's a new estimate"), not avoiding giving a timeframe at all. WHY THIS CONNECTS BACK TO THE CHAPTER'S OWN CORE ARGUMENT ------------------------------ The whole point of setting expectations early is preventing uncertainty from turning into frustration. A stale, broken expectation undoes that entirely and adds a new failure mode on top - which is exactly why the chapter treats actively maintaining an expectation as inseparable from setting one in the first place, not an optional extra step. WHY THIS WORKS AS AN ANSWER ------------------------------ It contrasts what happens with no expectation set versus a stale one, explains why a broken promise creates a genuinely new, additional source of frustration rather than just failing to prevent the original one, and explains why the fix is active updating, not avoiding expectation-setting altogether.