Every vendor who walks into a meeting already knows what you need. They knew before they learned anything about your specific projects, your team, your constraints, your history. They knew from their product roadmap.

Be skeptical of that certainty. It’s almost always wrong.

What Henry Ford actually got wrong

There’s a quote that gets attributed to Henry Ford (“If I had asked people what they wanted, they would have said faster horses”) that gets used constantly to justify ignoring what customers say they need.

It’s a poor framework, and the built industry has used it to excuse decades of building tools for problems that weren’t the actual problems.

The customers were right that they wanted to get somewhere faster. They were also right that horses were inadequate. The problem wasn’t their diagnosis. The problem was that they didn’t know what was technically possible. Listening to them closely, understanding the actual need underneath the proposed solution, would have led to the automobile just as surely as ignoring them.

In construction technology, the equivalent error is watching a senior superintendent struggle with a coordination problem and deciding you know better what the solution should be. Listen to the superintendent. The real problem is in what they describe, not in what they propose.

The market-listening problem in AEC

The built industry has a specific version of this problem. Most of the people building technology for it have never spent real time on a job site. They’ve interviewed contractors. They’ve watched demos. They’ve read research reports.

They haven’t felt the actual frustration of trying to manage subcontractor coordination across three trades when everyone’s running two weeks behind and the owner wants a status update by Friday.

That gap between observed problems and lived problems is where poor technology gets built. Tools that solve the version of the problem that’s easy to describe in a demo, not the version that actually costs money on projects.

What this means for owners evaluating vendors

When a technology vendor or consultant tells you their solution will fix your project delivery problems, ask them to describe the problem first. In detail. Without mentioning their product.

If they can’t describe your actual operational reality (the specific friction points, the information gaps, the moments where decisions get made on bad data) they’re selling you a solution to a problem they’ve modeled, not a problem they understand.

The best vendors listen more than they talk in early conversations. They ask questions that reveal they’re genuinely uncertain about your specific situation. They’re willing to say “I’m not sure our product addresses that specific issue” when they’re not sure.

That kind of honesty is a strong signal. Vendors confident they have all the answers before understanding your situation are telling you something important about how the relationship will go.

The startup problem in construction tech

There’s been an enormous amount of venture capital invested in construction technology. Most of it has been chasing the same handful of problems (scheduling, document management, safety, project reporting) that are easy to demo but hard to get teams to actually adopt.

The less visible problems (the ones that are genuinely hard to describe, that live in the coordination gaps between companies rather than inside any one firm) have attracted less investment and produced fewer solutions.

Those are usually your actual problems.

The right question isn’t “which technology is available?” It’s “what is the problem costing me, and has anyone built something that actually addresses it?” The second question is harder and more likely to lead somewhere useful.

Not knowing the answer immediately isn’t a weakness. It’s the starting point for finding something that actually works.