Bill W:
Chad G:
#8 of 10 in a series: Why Obvious App Improvements Don’t Get Made
Why is reversing a bad app decision sometimes harder than making it in the first place?
This story will examine escalation of commitment in software and product management. A redesign may consume months of work. A new architecture may require large migrations. Executives may have publicly endorsed the strategy. Teams may have reorganized around it. By the time serious problems become undeniable, changing direction can mean admitting that a great deal of effort must be discarded or redone.
We want documented cases where organizations persisted after warning signs appeared, and enough evidence to distinguish stubbornness from genuine switching costs.
What had already been invested? Who had attached their reputation to the decision? Were technical dependencies making reversal dangerous? Did teams keep believing one more patch would solve the problem? At what point did the cost of continuing finally exceed the psychological and operational cost of turning around?
This matters because users often experience the result as bewildering delay. “Everyone hates this—why don’t they just put it back?” may sound obvious from outside while the company sees a network of sunk costs and commitments.
Sunk costs should not determine future decisions, but human organizations are not spreadsheets. Reputation, career incentives, pride, deadlines and fear of disruption all enter the calculation.
The finished story will look for app-specific examples rather than relying only on general psychology research.
Sometimes the most important product decision is not choosing a direction. It is recognizing when the direction has failed—and giving people inside the organization enough permission to say so.
