Rush hour [EN]
🇧🇷 Leia a versão em português → Rush hour (PT-BR)
Although not formally defined, rush hour (not Jackie Chan’s movies) is a term almost everyone understands. It even has an entry in the Cambridge Dictionary:
the busy part of the day when towns and cities are crowded, either in the morning when people are travelling to work, or in the evening when people are travelling home
— Cambridge Dictionary
That shared understanding makes rush hour a useful metaphor for product organizations. Many people move in the same direction, often toward the same outcome—getting home, reaching the office, making it to school—guided by plans, priorities, and estimated arrival times.
But anyone who has been stuck in traffic knows that plans alone do not guarantee outcomes. Accidents, roadwork, weather, or a single stalled vehicle can ripple through the entire system. In product organizations, the same dynamics apply: even carefully planned work depends not only on flow, but on system conditions—incidents, hidden dependencies, contention for shared resources, and disruptions that can instantly invalidate any ETA and erode stakeholder confidence.
It’s not often possible to avoid rush hour, but product organizations can at least recognize when they are operating in it—and that awareness alone already changes how they plan, communicate, and respond.
You can’t always avoid rush hour—but you can recognize when your organization is operating in it.
Cities don’t solve rush hour by demanding better planning; they design systems that absorb congestion and recover from disruption. Product organizations face the same reality. Rush hour is not something to optimize away, but something to recognize and respond to as a systemic condition.