Years ago I worked on a software project for specialist users. They hated it. Absolutely despised this application. When I finally got the chance to visit the dev team in Long Beach, what I discovered what that almost none of them had ever actually used the software they were building. Some had never even seen it.

They were good developers. Smart people. Building features in a vacuum based on specs handed down from somewhere, with zero connection to the reality of what users actually needed. From their perspective they were doing everything right. They had automated unit testing, pipelines, write nice, testable requirements from the user stories, all of it. But no one on the team had ever really sat down and executed all the user stories, in order, over a period of days, to simulate the full end to end steps of the entire complex workflow.

You know what I did? I made the entire dev team attend the introductory user training. They took a full sprint and sat in the same seats as new users, clicking through the same frustrating workflows, experiencing the same pain points. Suddenly they understood why users were so angry. Features that seemed clever on a whiteboard were nightmares in practice. That one sprint opened more eyes than months of bug reports ever had.

I keep seeing this pattern repeat.

Organizations hire a bunch of smart, enthusiastic people who are excited to “build cool stuff.” They spin up enablement programs and lunch-and-learns with content that makes you wonder if anyone here ever actually done the job they’re building for?

The answer, often, is no. They’ve read about it. They’ve seen a demo. They’ve talked to stakeholders. But they’ve never sat in the trenches doing the work.

And it shows. The tools feel disconnected. The training feels theoretical. The “enablement” enables nothing because it wasn’t designed by anyone who needed to be enabled.

Here’s my challenge if you’re building tools, platforms, or processes for other people. Go do their job! Not a ride-along. Not a shadowing session. Actually do the work, as much as you’re able. Feel the friction. Experience the frustration. Understand which parts of your “cool stuff” actually help versus which parts just created more work for someone.

It’s not enough to be smart. It’s not enough to be excited. You have to be connected to the people your work is supposed to serve.

Otherwise you’re just coding in a vacuum.