Logged
Every product team is told to remove friction. It is one of the few pieces of advice nobody argues with, which is usually a sign it is hiding something.
We split friction into two kinds, and we treat them in opposite directions.
Betraying friction — delete it to death
This is friction that exists because we did our job badly.
The screen takes too long. The thing you need is three taps in and named something you would never guess. The back button loses your work. You tried the obvious thing and the product punished you for it.
None of this is principled. It is just bad, and it is bad in a way that quietly tells the person using it that their time is worth less than ours. We delete it without discussion and we do not require a business case to do it.
Protective friction — keep it, on purpose
This is friction that exists because the smooth version would be worse for you.
An answer that does not flatter you. A path that does not get shorter the more you use it. The absence of a nudge that would have got you to open the app again tonight. A place where the product declines to be clever and leaves the work with you.
Every one of these could be smoothed out. Each time, some number would improve. That is exactly why they need protecting: the arguments for removing them will always be well-formed, quantified, and made by someone acting in good faith at the end of a hard quarter.
The rule for when we cannot tell which it is
Most real cases are ambiguous. Someone says a step is confusing; someone else says the step is the point. Both are describing the same screen honestly.
So we wrote down a default and a burden:
When it is unclear which kind of friction something is, it counts as protective. The person who wants to remove it carries the burden of proof.
Not the person who wants to keep it. That asymmetry is the whole mechanism. Without it, ambiguity resolves toward removal every single time — because removal is what the dashboard rewards, and keeping is what nobody gets credit for.
Why this is written down rather than understood
A shared understanding lasts exactly as long as the people who shared it.
The pattern is familiar enough to stop trusting: someone leaves, someone new arrives with a mandate to improve the numbers, and a protective step gets removed by a person who has no idea it was load-bearing, in a change that looks entirely reasonable and passes review.
That is not a failure of judgment. It is a failure of the previous team to leave behind anything capable of saying no.
So it is written down — with a default and a burden of proof — where a new person reads it before touching anything. It is still weaker than we would like. A document only works when someone opens it. Where one of these can be converted into something a machine enforces, we convert it, and that is a separate post.
This is a build log. It describes a decision already made, not a plan.