The first step in our process, in the era of AI

We do not start by building.

That is easy to forget right now, when everyone assumes speed is the whole point of AI. The instinct is to build a prototype the same day someone describes an idea, because building has gotten fast enough that skipping the thinking feels like the responsible move. Before we make any move, we spend a few meetings just trying to zoom out and understand the whole picture behind the idea, not just the feature someone is asking for, but the business behind it.

The idea that shows up in the first meeting is rarely the real one. It is just how the partner understands it at that point. The real one tends to surface later, in the second or third conversation, usually as a correction to something we assumed too early.

This did not come from a book. In 2020 we worked on an esports platform for Logitech. We did not own the product, and we relied on our previous knowledge instead. In some way, all the decisions their team made seemed fine to us. We did not zoom out enough to see that player needs, the end users of the platform, mattered more than staff needs. After that, we changed how we work on projects. We look at the whole system before we build anything, and the first goal is to understand who the end user actually is.

Once we have that, we map out the whole system before we touch anything: what it depends on, and where it would quietly assume something that is not true.

A real systems map from an early scoping session

Then we spend about a week building a first version of the prototype. This is the same process we used before AI existed. AI just lets us move through it faster without changing what we are actually doing.

Based on that first version, we take it back to the partner early, before it is finished. What comes back is rarely about the interface. It is usually about a part of the plan that only became visible once there was something to react to. Over the next week or two we just refine it, sometimes a small adjustment, sometimes something closer to the center of it.

By about two weeks in, we have what I would call a ready to go prototype, not an MVP and not a finished product. Once we are on the same page and have a clear idea, that is when we define scope, not before. By that point we know what the real architecture needs to be and what infrastructure it depends on, because we are not guessing anymore.

If we had defined scope first, we would be building it around assumptions instead of around something that already exists and already sat in front of the partner and got a real reaction. The prototype is what makes the next decision possible to make honestly instead of hopefully, not the deliverable itself.

I still do not know how much of this is discipline, and how much is just fear of building the wrong thing quickly. From outside, both would look the same.