The Gap Between "It Works" and "They'll Use It"

There are two different jobs hiding inside most software projects, and most teams only staff one of them.

The first job is making the thing work. Correct logic, clean data, a system that does what it's supposed to do when you press the button. This is the job engineers are trained for, hired for, and measured on. It's necessary. It's also not sufficient.

The second job is making the thing get used. That's a different discipline entirely, closer to translation than engineering. It means sitting with the person who has to enter the data and understanding what they're actually optimizing for, which is usually not "help the company's reporting." It means noticing that the system is technically correct and still going to get ignored, and being willing to say so before launch instead of after.

I've spent most of my career in the seam between these two jobs, inside Salesforce orgs, inside a construction software vendor, inside migrations where a company split in two and every system had to follow. The pattern is consistent: the projects that stuck weren't the ones with the cleanest code. They were the ones where someone kept asking "will the person actually do this" as a real design constraint, not an afterthought bolted on after the build.

That question doesn't get asked by default. Engineering incentives point toward shipping the correct version. Sales incentives point toward closing the deal. Nobody's job description says "make sure this survives contact with an unexpected Tuesday afternoon." That's the gap. It's not a technical gap, the tools to close it already exist. It's an attention gap, and it's usually cheaper to close early than to discover six months post-launch, when the workaround spreadsheets have already calcified into the real process.