From Friction to Flow - SmashingConf

I am attending SmashingConf Freiburg as an employee of Pax—thank you to Pax for the opportunity. I took notes on the talks and am sharing the thoughts they prompted here. This is a personal conference note, not a transcript and not a statement by Pax.

This is another post in a series of notes from SmashingConf Freiburg. The 2026 conference is taking place in Freiburg from September 7 to 10. The official schedule is here.

Joe Natoli’s talk, Friction to Flow, described a familiar product-development problem: developers often feel that management does not understand them, while management feels equally misunderstood by developers. Add design, product management and executives, and there are several perspectives on the same product—each with its own concerns, language and pressure.

That does not mean one side is right and the others are wrong. In Joe’s framing, the different angles are all valid. The work is to make them meet before they turn into expensive late surprises.

Friction usually protects something

Friction rises and falls in every team. It becomes easier to work with when we ask what someone is trying to protect.

A developer who says, “This will create technical debt,” may be protecting code quality, architecture or the team’s ability to change the product later. A product manager under pressure from several directions may be protecting a commitment, a customer need or the room to make a decision at all. Product managers are often in the most difficult position: they sit in the middle and receive pressure from every side.

This is why disagreement can feel personal. When people care deeply about a product, they send signals through the phrases they choose. Those signals are real, but they are not necessarily the whole argument.

The useful move is to stop taking sides. A conflict is rarely black and white, and there is usually a solution that each person can accept—even if it is not their first choice.

Make the case for the product, not the discipline

One point from the talk stayed with me: do not make an argument about your discipline alone. Instead of saying, “This will screw the architecture,” explain the product and business consequence: “This could work now, but it may affect our ability to change the product in three months.”

This is not about dressing up a technical concern in business language. It is about doing the extra work to connect cause and effect. If a decision will make a future release slower, more fragile or more costly, that is a product concern. It becomes discussable by people outside engineering when we explain it in those terms.

The same applies in the other direction. A delivery date, a market opportunity or a customer commitment should not be treated as pressure that engineers simply have to absorb. It is information about the outcome the product needs to achieve. A team can then assess the trade-off together.

Move disagreement upstream

Joe called this moving upstream: bringing friction to an earlier point in time where a question can still change the decision. All teams disagree. The more important question is when they disagree in the process.

Late friction—on release day, or after a release—costs more because there are fewer good options left. It is usually better to surface the uncomfortable question early, reach an agreement as soon as possible and leave time to adapt.

That does not mean trying to eliminate disagreement. “Disagree as long as it is useful” is a much better goal. Product teams need enough tension to discover risks and alternatives. They do not need tension that has been carried quietly until the only remaining choices are delay, rework or blame.

My take: learn the work around your own

I find this a very valid description of something I have often experienced. Everyone in product development needs to make a genuine attempt to understand the work and constraints of the others.

From my developer perspective, that starts with an uncomfortable question: what does the company actually make money with? It can be surprisingly hard to answer clearly, even inside a company. But it changes how we see a backlog item or a technical decision when we understand the customer, the service and the business outcome connected to it.

It also helps to talk to people outside our usual technical circle. Job shadowing, pairing across roles or temporary job sharing can reveal constraints that a ticket or a meeting never makes visible. I have seen people at Pax do this especially well: they make room to understand another participant’s work before deciding what that person should do differently.

The focus should stay on the product rather than on the discomfort of getting there. At every iteration, designers, developers, product managers and leaders can ask: what does this look like from the customer’s perspective? Customers are the people who ultimately choose and fund the product. Keeping that in view gives the team a shared reference point when the internal perspectives pull apart.

For app products, this is part of the work we care about in development partnerships: not only building the next feature, but helping teams make durable decisions together. If you are navigating those trade-offs in your own product, get in touch.