An Island, Several Time Zones and a Kiosk: What Real-World Pilots Teach You

The first pilot client for the new version of our self-service kiosk was Burger King in La Réunion.

On a map, that is an island in the Indian Ocean, more than 9,000 kilometres from our offices in France, and two or three hours ahead of us depending on the season. In practice, it was the most useful education in product management I have ever had.

The office is a comfortable lie

In the office, the kiosk worked. It ran on a clean network and went through test scenarios written by the people who had built it.

A store is a different world. The hardware is the real hardware, in its real installation. The network is whatever is actually there. The payment terminal and the till have to talk to the kiosk while a queue forms behind a customer who has never seen the screen before. And none of those conditions wait until you are ready.

What distance forces you to do

When a problem appears in a store next door, someone walks over and looks. When it appears on an island several time zones away, you have to be able to understand it from where you are. That changes how a team works.

Test cases have to be precise, because the person running them may not be able to ask you what you meant. Diagnostics have to be built into the product, because you cannot lean over anyone's shoulder. And the hours when everyone is available to make a decision become scarce, so decisions have to be prepared before those hours start.

The lesson I would pass on is one I learned the hard way: we went to the field later than we should have. Every week in the lab felt like progress. Most of what mattered was waiting in the store.

Then the teams got bigger

Later, coordinating different teams across France, the United States, the United Kingdom, Germany and Australia, I met the same problems at another scale. The time differences within Europe are small, but the distance between teams is not only a matter of hours.

People read the same specification differently. Priorities that are obvious in one office are invisible in another. Work moves from product to engineering to testing, and at every handoff some of the reasoning stays behind. The most useful thing I could do was usually unglamorous: make sure each piece of work had one clear owner, and that the reasons travelled with the task.

I see it again with AI agents

Building agents today, I recognise all of this.

Scripted tests pass, and then a real employee phrases a request in a way nobody predicted. A demo environment behaves, and then a real system times out. When an agent fails in production, you cannot lean over its shoulder either, and you will only understand what you took the trouble to record.

Lessons

1. Write down what you expect, precisely enough for someone who cannot ask you what you meant.
2. Build the ability to see what happened into the product itself.
3. Make every handoff explicit, between two people or two agents.
4. Leave the lab earlier than feels comfortable.