Operators weren't struggling with delays. They were struggling with uncertainty.
I started this project assuming traffic delays were the core problem. Eight interviews later, it became clear that delays were only the symptom. The real cost was uncertainty — and operators had been silently absorbing it for years.
It seemed like a simple operational inefficiency. Add less buffer, recover the lost time, improve service. But the more operators I spoke to, the clearer it became that the buffer wasn't irrational — it was load-bearing. It was the only reliable tool they had.
The right question wasn't "how do we reduce buffer?" It was "why does buffer exist at all?"
Before exploring solutions, I wanted to understand how transport operators actually plan their day. What tools did they trust? How did they make dispatch decisions? And why were large schedule buffers considered normal practice?
I conducted eight semi-structured interviews across Hyderabad and Bangalore. Each ran 30–40 minutes, focused on planning workflows, dispatch decisions, routing tools, and operational pain.
Beyond direct answers, I paid close attention to contradictions, workarounds, and repeated behaviours. When users consistently create their own solutions to a problem, those workarounds reveal more than the complaints themselves.
Individual workflows varied, but the same operational behaviours appeared repeatedly across all eight interviews.
Operators had already adapted to delays. The delays themselves weren't what drove decision-making. The inability to predict them was.
Google Maps answered: What is happening right now?
Operators needed: What is likely to happen tomorrow?
Rather than competing with routing platforms, the product would focus on a different layer entirely — not navigation, not dispatch management, not fleet tracking.
Every feature in the product exists because of something discovered during research. Nothing was designed in a vacuum.