The Tool Is Not the Point

In 2013, I told my development team we were moving the new platform onto an enterprise low-code stack. Not the kind of low-code marketed today for SMB workflows or citizen developers. The kind designed for mission-critical enterprise systems with real performance, security, and integration requirements.

The reaction was immediate. One developer put it plainly. "This technology is only good for demos and small systems. I want Java or .NET on my CV. Nobody knows this stuff." Others nodded. The room was skeptical in the way technical people get when they feel their professional identity is being questioned.

I understood the concern. These were good engineers. They had invested years in specific skills and had legitimate career interests. But I was not making a technology bet. I was making a business bet. The question I kept returning to was not "what does this tool run on?" It was "what does this tool let us build, and how fast, and at what cost, and at what risk to the production environment?" The answer pointed clearly to enterprise low-code.

We moved forward. The team adapted. Within a year, the developers who had been most resistant were the most fluent. The market eventually proved the decision right. The platform category grew into something recognized, and the engineers who had demanded Java or .NET were now holding a credential that was, if anything, more differentiated.

But that is not the lesson I took from it. The lesson came later.

Building a healthcare platform is not like building most software. The people who define what the system should do are not the same people who use it. Product managers and program managers spend months mapping use cases, shadowing clinicians, running workshops, trying to translate lived clinical reality into functional requirements. Meanwhile, hospital departments keep arriving with lists. More features. More screens. More configurations. Always more.

I watched this tension play out across years of development. On one side, rigorous effort to understand what genuinely mattered. On the other, an institutional reflex to accumulate capability. The two forces were not aligned.

What I learned, slowly and through friction, was this. The use cases that genuinely matter to users are the only ones worth pursuing. Every feature added beyond that is debt. It consumes engineering time, complicates training, increases support load, and dilutes the value of everything around it. Hospitals do not fail to adopt software because it lacks features. They fail to adopt it because the features they have are not connected to how work actually happens.

The product instinct I had formed in 2013, which was about tools and speed and market position, was replaced by something more durable. Technology takes second row. The use case takes first row. If you cannot clearly describe what a real user needs to accomplish, and why solving it creates measurable value, the technology choice is irrelevant. You are building in the wrong direction at whatever speed.

When AI moved to the center of every executive conversation, I noticed how the question was framed. Everywhere it was the same: what can it do? Executives were evaluating models, benchmarks, demo outputs. The energy was the energy I had felt in 2013 about the new platform, before I had learned to ask the harder question.

I had already made that transition once. I knew what came after the initial excitement.

The question that matters is not what AI can generate. It is whether what it generates addresses something that genuinely matters to users and institutions, and whether institutions can absorb and operationalize that output. Those are not technology questions. They are use case questions. They require the same discipline that separates a useful healthcare platform from an overbuilt one.

This is the distinction that does not appear in any demo. A language model can produce clinical documentation at speed. Whether that output fits into how a nurse or physician actually moves through a shift, whether it integrates cleanly into existing workflows, whether it reduces cognitive load or adds to it, these are questions that require operational knowledge and user proximity. Not a benchmark.

The executives who will create real value from AI are not necessarily the ones who move fastest. They are the ones who have done the slower work. Understanding what their users actually need, what their institutions can actually change, and where the technology genuinely closes a gap versus where it creates an impressive artifact.

That slower work is not glamorous. It does not generate much conference content. But it is the difference between a platform that gets used and one that gets abandoned after the pilot.

My first interest in the enterprise low-code platform was the tool itself. That was the wrong frame, and I eventually outgrew it. The frame that replaced it was: what does this enable, for whom, and at what cost and risk?

I applied that frame to the healthcare platform work for years.

I applied it again when generative AI arrived.

The transition from tool excitement to outcome focus is not automatic. It requires experience with what happens when you skip it. Most organizations are going to learn that the expensive way.

The ones that do not will be led by people who have already made that transition, in some prior context, before the pressure arrived.

That preparation is not visible in any job description. It rarely appears in a board presentation. But it is the thing that determines whether a technology investment lands.