I once visited a construction site where the contractor’s headquarters had commissioned a tech company to build an on-site quality-inspection application. The developer had admitted to the site engineer that they had never set foot on a construction site before. The engineer showed me what he was actually using: his own phone camera and an Excel sheet. The new app did not map to how work actually happened on site.

This is not an isolated story. The vendor builds something technically coherent but operationally disconnected. The client, somewhere up the chain, had fallen in love with the idea of the solution before anyone had built an honest business case for it.

The result is a tool that gets demonstrated at a board meeting but isn’t used in the field.

A name for the gap

Ken Dooley, Chief Data Officer at Granlund and Professor of Practice at Aalto University, and Elisa Rönkä, Managing Director of Johnson Controls Digital Business EMEA, have written a book that provides a framework for this problem. It is titled “Inbetweeners – How to Translate Tech into Customer Value in the AI Era.“

The authors’ central argument is that the bottleneck in technology adoption is rarely the technology itself. It is the absence of someone who understands both the technical and customer sides well enough to bridge them, and who has the mandate and credibility to push back on complexity when it gets in the way. They call this person the inbetweener.

The concept is not new in practice. What is new is the systematic treatment of why the role is necessary, why it so often goes unfilled, and what it actually requires.

Why tech people resist simplicity

Ken and Elisa identify tendencies they observe in what they call creators, the technically brilliant people who drive innovation. Complexity bias leads them to believe that more features equal more value. If required to hold back, they take that as a personal defeat. Aesthetic bias leads them to believe that customers will appreciate sophistication if it is explained well enough. They rarely do.

The book’s illustration is pointed: the creator envisions a complex rocket, then launches a toned-down rocket, and delivers it to someone who needed a bike and a ramp. The customer did not fail to appreciate the engineering. The creator failed to ask the right question at the start.

I recognized this pattern immediately. In the early days of internet applications, I partnered with a startup building software for an AEC manufacturer. The client told me directly never to bring a developer to a client meeting. The developer could not communicate with business people, and the client had no patience for it. I became the translator by necessity. The book gives that role a name.

The client’s failure mode

The problem is not only on the vendor side. AEC firms have their own version of this dysfunction.

In my experience advising AEC firms, it is not unusual to find a company running dozens, even hundreds, of applications across its operations. This reflects years of departmental decisions that lacked coordination or governance.

The person driving technology adoption within the firm is often an R&D or IT manager who is closer to technology than to day-to-day operations. They build the business case in the language of technology rather than operations, and the people who would need to change how they work don’t feel the argument was made for them.

When the internal champion is more excited about the solution than rigorous about the problem, the investment gets approved but never truly adopted. The site supervisor keeps using his phone and his Excel sheet. The app sits on a server somewhere, waiting for a champion who never arrives.

Making the role intentional

The book mentions several tech company roles that have some elements of the inbetweener’s role: Product Manager, Growth or Commercialization Coach, Product Marketing Manager, Head of Strategy, Business Designer, and Service Designer. However, none of them closes the gap perfectly. Sales teams are often the first to hear that a product is too complicated, but in most technology companies, they are the last to influence what gets built.

For an AEC company, a perfect candidate is even harder to pinpoint.

The right person to become an inbetweener may already exist inside many AEC firms and tech vendors. What they typically lack is the organizational authority to challenge product or procurement decisions.

An inbetweener needs more than knowledge. They need standing to say the product is too complicated and for that statement to carry weight. According to the book, this is exactly what most technology organizations lack: not the insight, but the mandate to act on it.

A necessary hire from the get-go

For AEC tech startups and scale-ups specifically, the inbetweener is not a luxury for a later stage of growth.

The companies that struggle to convert pilots into contracts, or that build products their customers admire but do not use, typically lack this function entirely. The founders are brilliant, and the product is sophisticated. But nobody in the room is authorized to say it is too complicated.

The book will not solve this for any individual company. But it names the problem clearly enough that leaders can stop pretending the gap does not exist. That is a necessary first step. The second step is writing it into a job description.

Whether you are an AEC tech company founder, a product lead, or a business developer wondering why promising pilots keep stalling, this book is worth your time. Ken Dooley and Elisa Rönkä have done the hard work of turning a frustratingly common problem into a clear framework and a practical call to action. Pick it up before your next product review.

I thank the authors for letting me preview the book.