From friction to product

An operation does not need more technology simply because new technology exists. It needs a new form when a recurring difficulty begins to consume time, context, attention and decision-making capacity.

At that point, friction is no longer merely an inconvenience. It becomes raw material for a product.

The challenge is resisting the urge to jump straight to a solution. A single request may express a preference, and one complaint may be an isolated event. But when different signals point to the same rupture, there is something larger to understand: information that never arrives, a process dependent on memory, a queue that keeps returning or a decision that is always late.

Observe before proposing

Observing an operation means following what actually happens, not only what the designed process says should happen. It means identifying where people improvise, which information moves through parallel channels, when context disappears and which tasks still rely on manual effort.

Good observation looks for patterns: the same problem across different teams or locations; similar informal workarounds; missing information generating rework; a process that works but demands disproportionate attention; or leadership discovering a problem after the opportunity to act has passed.

The goal is not to catalogue failures. It is to understand the relationship between people, data, decisions and consequences.

Translate without reducing

After observation comes translation: the passage from a reported pain point to a product hypothesis.

“We need an app” is not yet a hypothesis. “We need to reduce the loss of context between an incident and the team responsible for it” points to a verifiable transformation. When technology is defined too early, the operation must adapt to the tool. When the problem is translated clearly, technology can take the form best suited to the real workflow.

Translation also requires choosing what will not be solved yet. Relevant products do not emerge from the sum of every request. They emerge from a clear decision about which friction should be removed first and which behavior needs to change.

Test behavior, not only interfaces

An interface can be understood in a demonstration and still fail in daily use. Testing a product therefore means observing whether it appears at the right moment, reduces steps, preserves context and produces a better action.

The test should reveal whether people know what to do without excessive training, whether information reaches someone able to act, whether the new flow removes a task instead of merely moving it, and whether the operation can understand the current state of the process.

The product evolves not by accumulating features, but by moving progressively closer to the reality it needs to organize.

Integrate in order to exist

A digital product never operates alone. It meets existing systems, rules, responsibilities, devices, channels and infrastructure limits. Integration is therefore not a technical stage added at the end; it is part of the experience.

Entering operation means finding a clear place within the real system. The product must know where signals come from, how they are organized, who can act and where context is returned.

Scaling means preserving the logic

Scale is more than serving more people. It means allowing a product to cross new locations, volumes and situations without losing the clarity that justified its creation.

The cycle does not end at launch. Operations continue producing signals, new friction emerges and the product begins generating evidence of its own. Observing, translating, testing, integrating and scaling become one continuous system of evolution.

That is how a recurring difficulty stops being treated as an exception and begins to guide a product with form, function and the potential to endure.

Principle in operation

This idea takes shape in JogaJunto.

Explore the product →