The operational detail that changed how I think about software
Before building software, I spent years in service operations. One thing I keep returning to is where work actually happens.
Important work rarely happens at a desk. It happens in a kitchen during a busy service, a storeroom with weak signal, a hotel room between turnovers, or a handover at the end of a shift.
Yet many tools are designed around the final dashboard, rather than the moment someone has to capture what is happening.
I have become convinced that if a workflow is awkward where the work occurs, the data it creates will eventually be incomplete, delayed, or unreliable.
That changed the question I ask before adding anything:
Not “Will this look useful in a report?”
But “Can someone use this while the work is actually happening?”
For founders who have spent time close to their users’ daily environment: what detail about the real workflow changed how you thought about building?
Replies
This hits close to home for me. I took initiative and built an internal tool for my boss a couple weeks ago, and last Friday we finally sat down to go through it together and get her feedback.
What humbled me most was when she pointed at a feature and asked "why is this here? How does this work? What am I supposed to do with this?"
After discussing thoroughly, it turned out that something I had built in beforehand was not part of her normal workflow at all. Instead of removing work, it had essentially added an additional task to her job.
So what changed about how I think about building: I stopped assuming I know what a job title requires before building a fix for it. The workflow in my head and the workflow in her actual shift were two different things, and only one of them matters.
I'm curious how you handle this at the discovery stage, do you shadow people while they work before building anything? Or is there a lighter way you've found to catch these assumptions early?