What we decide matters less than how we arrive there

There’s something we don’t usually pay attention to when working on a product. We focus on decisions — what to build, what to remove, what to prioritize — as if those decisions were the thing that shapes the outcome. But over time, I’ve started to notice that what really matters is not so much the decision itself, but how you get there.

Two teams can face the same situation, with the same constraints, the same information and even similar levels of experience, and still end up in completely different places. Not because one made better decisions in a vacuum, but because they interpreted what was happening in a different way.

There is always a moment before a decision where something shifts. A plan starts to break, a discussion gets tense, something doesn’t behave as expected. It’s a small moment, easy to overlook, but it’s where everything starts to take shape. Because in that moment, we don’t just react — we construct a meaning around what’s happening.

We tend to think we’re responding to reality, but what we’re actually responding to is our interpretation of it. The same situation can be framed as a problem, a delay, a failure… or as a signal that something deeper isn’t working yet. And that framing quietly defines what comes next: what we pay attention to, what we discard, what we consider urgent, and what we’re willing to question.

In product work, this is rarely made explicit. We talk about strategy, roadmaps, prioritization frameworks. But underneath all of that, there is a layer that is much harder to see: the collective way a team understands what is happening to them. When that layer is rigid or reactive, decisions tend to become defensive. You optimize for speed, for closure, for reducing discomfort. And from there, it becomes very difficult to see clearly.

I’ve seen projects where the problem wasn’t complexity or lack of resources, but something more subtle: a shared interpretation that had gone unquestioned for too long. Everything was being built on top of it, and yet no one was really looking at it anymore. The product kept moving, but it was moving within a frame that limited what could be seen and, therefore, what could be changed.

Design, in that sense, is not only about proposing solutions. It also has to do with creating the conditions for a different reading of the situation. Sometimes the most valuable contribution is not a new idea, but a shift in how the problem is understood. A question that slightly reframes things. A pause that interrupts the rush to decide. A way of looking that opens up alternatives that were not visible before.

Over time, I’ve started to think that products are shaped less by the decisions teams make, and more by the way those teams interpret what happens to them while building. That layer is quiet, almost invisible, but it’s where coherence — or its absence — begins.