15 September 2025
What I learned by putting down the laptop
There's a moment in almost every product research session where you see something that no survey would have caught.
For me, it was watching a payroll operator answer a phone call.
She was mid-task — updating a worker's record, halfway through a form — when the call came in. A query about a different worker entirely. Without missing a beat, she right-clicked the sidebar, opened a duplicate tab, navigated to the employee listing page, searched for the name, clicked through, and started answering the caller's question while the original tab sat frozen in the background.
The whole thing took maybe forty-five seconds. She didn't notice she'd done it.
I had been looking at Hotjar data for weeks trying to understand why our users were opening so many tabs. The data showed the behaviour clearly — strange navigation patterns, multiple concurrent sessions, what looked like frustration clicks. My working hypothesis was that operators were juggling multiple workers simultaneously and using tabs as a workaround for something missing in the product.
I was half right about the diagnosis. I was completely wrong about the cause.
The tabs weren't about juggling multiple workers. They were about interruptions. Phone calls. Colleagues asking questions. The constant context-switching that defines a busy operations environment. Users weren't navigating strangely because the product was confusing — they were navigating strangely because life kept interrupting them, and the product had no way to help them handle that gracefully.
Forty-five seconds to find a record. Multiplied across a team of ten, across a hundred calls a day. That's not a feature request. That's a structural problem hiding in plain sight.
I do in-person research visits with clients every quarter. They're deliberately low-key — no agenda, no script, just a request to sit alongside someone while they work and watch what happens. I'm not running usability tests. I'm not asking people to think out loud. I'm just watching.
It sounds simple. It's surprisingly rare.
Most product teams do research — it's scary how many don't — but the research happens at a remove. Surveys. Moderated interviews. Analytics dashboards. All of these are valuable. None of them show you what it looks like when someone answers a phone call mid-task, or has to read a confusing error message aloud to a colleague across the desk, or quietly develops a workaround so habitual they've forgotten it's a workaround at all.
The researcher effect is real — when you ask someone to describe how they use your product, they describe the version they think you want to hear, or the version they believe they use, which is often not the same as the version they actually use. Watching someone work bypasses that entirely. You see the shortcuts. The hesitations. The moments where they reach for the mouse and then stop and think. You see the workarounds.
And workarounds are the most valuable thing you can find in a research visit, because they tell you exactly what the product isn't doing that the user needs it to do. They're not feedback — they're evidence.
There's a version of this principle that gets talked about in product circles as empathy. Understand your users. Walk in their shoes. Build for their needs, not your assumptions.
All of that is true. But I'd push it further.
Empathy isn't a mindset you adopt in the abstract. It's something you earn by getting close enough to feel the actual pressure people are under. The time pressure. The accountability pressure. The pressure of a phone ringing while you're in the middle of something that matters.
You don't have to have worked in the same industry as your users to feel that. You do have to be in the room with them.
A 2025 survey of UK payroll professionals found that 74% lose at least eleven hours a week to inefficient systems — with nearly half losing sixteen to thirty hours weekly. Those aren't abstract numbers. When you've sat next to someone navigating that reality in real time, those numbers have a face and a name attached to them. The product decisions you make afterwards are different.
They're more specific. More considered. Less likely to solve the problem you imagined and more likely to solve the problem that actually exists.
The global search tool we built — the one that lets users find any record in the product instantly, from wherever they are — came directly from that site visit. Not from the Hotjar data, which I'd been looking at for weeks. Not from an interview, which would have told me users wanted better navigation. From watching someone answer a phone call.
The feature took weeks to scope and build. The insight that made it possible took forty-five seconds to find.
That's what I learned by putting down the laptop.
If you're a product manager reading this: when did you last sit next to one of your users and just watch them work? Not a demo. Not a usability test. Just watched.
Book the visit. You'll find something in the first 30 minutes that you couldn't have found anywhere else.