I Already Knew Where He'd Click Next
and What That Told Me About the System

The room had about 100 people.

A partner was presenting their system. ITSM, endpoint protection, cybersecurity scenarios. Standard conference format. I was watching the screen from my seat.

Early in the demo, during basic ITSM navigation, something happened that I did not expect.

I knew where he was going to click next.

Not because I had been briefed. Not because I already knew this particular product. I just watched the consultant move from screen to screen, scenario to scenario, and I was already there before he arrived. Agent availability calendar. Change management flow. Reporting. Each transition landed exactly where I would have put it.

I leaned toward our technical architect sitting nearby and said something quietly. He nodded. He had already worked with this system on the technical side. For him it was not intuition. For me it was.

We had reached the same conclusion from different directions.

We have been evaluating systems for a while now. More than ten products in our industry. The reason is simple: I kept hearing the same thing from clients and colleagues. Expectations built up through marketing and sales cycles. Then the real implementation. And then the gap.

Not a gap in features. A gap in effort.

What was promised worked. But only if you pushed it. Constantly. Every step required energy from someone. The vendor consultant learned to apologize in a certain way, with a certain tone, because they had done it many times before. The implementation team spent days on logic that was never documented. And very often, one person somewhere on the vendor side held the secret. They knew how the system actually worked. Which meant the system did not work. That person worked.

Nobody was wrong exactly. Everyone was just tired.

Two systems in the same category, described with the same words, can require completely different amounts of other people's energy to function.

This is not visible in a feature list. It is not visible in a proposal. It is sometimes not even visible in a prepared demo, if the consultant has rehearsed around the rough edges carefully enough.

But sometimes it becomes visible in a small, unremarkable moment.

You stop listening. You start predicting. And the predictions are correct.

That is not admiration for good design. That is recognition. The system's internal logic and your own logic are moving in the same direction. You do not need to learn its language because it is already speaking yours.

After the conference I thought about what exactly I had observed.

The consultant was confident, but that alone means nothing. Confident people present bad systems all the time. What was different was that his confidence was not performance. He was not filling space between clicks. He was not managing the distance between what the system could do and what he had promised it could do.

He was just moving through the system. And the system was letting him.

A system that fights its own users during a demo will fight its own users during deployment. The demo does not lie. It compresses the truth, but it does not replace it.

This pattern is not limited to enterprise software.

Any solution, any process, any tool carries an embedded energy cost. Some of that cost is visible upfront. Most of it is not. It shows up later, distributed across dozens of people, hundreds of interactions, in the form of workarounds, re-explanations, and the particular exhaustion of having to push something that should move on its own.

Organizations absorb these costs quietly. They hire people to manage the friction. They build internal knowledge around the gaps. They adapt. And after enough time, the adaptation becomes invisible, and the system looks like it is working.

But it is not the system that is working.

It is the people around it.

I have started to pay attention to a different question when evaluating technology.

Not: what can this system do?

But: how much will this system cost the people who use it every day, in energy, in attention, in the quiet effort of making something function that was supposed to function on its own?

Some answers are visible in a spreadsheet. Some are visible in a reference call. And some are visible early in a demo, during basic ITSM navigation, when you realize you already know where the consultant is going to click next.

That moment is not trivial.

It is the system telling you something true about itself.