Go stand where the work happens
A while back I spent some time doing delivery runs for Zepto in India. Not managing them - doing them. Picking up the bag, finding the address, handing over the order, riding to the next one.
I didn't do it because I love traffic. I did it because I wanted to understand last-mile delivery, and I had a hunch the dashboard wasn't telling me the whole truth.
It wasn't. From a desk, a delivery is a row in a table: assigned, picked up, delivered, a number of minutes. On the road, a delivery is a locked gate, a phone that won't pick up, an elevator that's out, a building with no number on it. The dashboard counts the minutes. It doesn't tell you where they go.
After a handful of runs I had found three specific friction points, each quietly costing fifteen minutes or more per delivery. None of them showed up in the data we already had. You could only see them by standing where the work happened.
I think about this a lot now that I build software for other people's work. It's easy to build for the dashboard - the clean, abstract version of a job that lives in a database. It's harder, and far more useful, to build for the locked gate.
So the rule I keep coming back to is simple: before you build the tool, go do the work. Stand where it happens. Watch what actually slows people down. The dashboard will still be there when you get back, and you'll finally know what it's hiding.