Twenty minutes watching someone use the system

The highest-value thing I’ve done for a product I maintain wasn’t technical. It was watching someone use it for twenty minutes without saying anything.

Not a requirements meeting. Not a bug report. Watching the actual work happen: which screen they leave open all day, which field they fill first, where they stop, what they do twice because the first time didn’t take.

What you find is never in a ticket

• The workaround they invented and now consider normal — and never mentioned, because from their side that’s just how the system works.
• The screen they open thirty times a day, which nobody has ever prioritised because it’s not interesting.
• The field they always leave empty — which is required, so they type a dot.
• The report they export and edit in a spreadsheet every time — which is a feature request nobody filed.
• The place where they wait — which in your development environment is instant.

The hard part is staying quiet

Every instinct wants to say “there’s a faster way”. And the moment you do, you stop learning: now you’re watching them use it the way you’d use it. The confusion is the data.

For software people are required to use — as opposed to software they choose — this matters more than for any consumer product. They can’t leave, so they don’t complain: they adapt, and their adaptations become invisible.

Twenty minutes, once a quarter. I’ve never done it without changing what I planned to work on next.

It’s part of how our systems evolve: the roadmap doesn’t come only from what’s requested — it comes from watching the real operation. That’s why, in our method, discovery never really ends.