Every product team I have worked on has, at some point, built something correct that did not work. The logic was sound, the feature was real, the engineering was good, and people still did not get through it. When that happens the instinct is to add: another tooltip, another onboarding step, another explanation. It is almost always the wrong direction, because the problem was never a shortage of information.
My thesis in one line: people do not experience a system, they experience a sequence, and most of what we call product quality is the work of deciding what comes first, what can wait, what should stay out of the way, and where a person rather than the software should make the call.
Five things I believe
1Every request has a price, and we rarely pay attention to it.
A phone number costs trust. A permission dialog costs confidence. A fourteen-field form costs the belief that this will be quick. We treat these as free because they cost us nothing to add, and the person absorbing the cost is not in the room when we add them.
The useful discipline is to put a price on each request and ask whether we are getting something worth it right now. Half the time the answer is that we are collecting a field because a system downstream once wanted it, and nobody has checked since. The cheapest conversion work available to most teams is deletion.
2The expensive-looking problem is rarely the one costing you people.
Teams reach for the visible lever, the redesign, the new brand, the rebuilt flow, because it is legible to leadership and satisfying to do. The thing actually losing people is usually a sentence that does not explain itself, a button labelled with an internal noun, or a question asked two screens too early.
This is unglamorous and it is where the returns are. I would rather ship five boring corrections that each remove a reason to leave than one ambitious redesign that moves the reasons somewhere else.
3Clarity is a sequencing decision before it is a writing decision.
Good copy cannot rescue a bad order. If you ask someone to verify their identity before they understand what they are signing up for, no amount of warm microcopy makes that reasonable, you have asked for a deposit of trust against a balance of zero.
So I start with three questions, in this order. What must be clear now? The immediate decision, with its reason and consequence in plain language. What can wait? Important is not the same as urgent, and asking later is frequently both kinder and more effective. What should stay human? Not every branch deserves automation.
4Trust is earned in stages, by software as much as by people.
We do not hand a new colleague broad authority on day one. We let them observe, practise somewhere safe, take smaller decisions, and grow into larger ones. Then we turn around and ask users to do the opposite with an automated system: trust the output, hand over the action, hope.
The better question is not “can this system do it?” but “what is the smallest responsibility it can earn next?” A system that makes its own limits visible is more credible, not less, and the route back to a person is part of the design, not an admission of failure.
5A measurement you cannot fail is not a measurement.
This one I learned the expensive way, running automated systems that reported success for weeks while producing nothing. A green check tells you a process finished. It does not tell you anything changed. A zero written where a missing value belongs is worse than a blank, because a gap invites a question and a confident zero closes one.
So: name the outcome before you build the check, and try to break the check on purpose before you believe a passing one. The same applies to a launch. Shipped is not working. Deployed is not working. One real person completing the thing on the other side is working.
What this rules out
A thesis is only useful if it makes some work unattractive. Mine rules out busy interfaces that hide the decision, intelligence that performs certainty it has not earned, growth that depends on somebody misunderstanding what they agreed to, and metrics chosen because they are easy to move.
It also rules out a certain kind of ambition. I would rather build one honest path that works than five clever paths that leave people feeling behind.
Attention is not the same as value.
In The last transmission, a ship collects samples and you decide when to secure them. A growing number makes potential gains visible; uncertainty makes stopping a decision. That sequence is the product you experience.
This experiment does not establish anxiety or measure dopamine. It illustrates a design choice: direct attention toward continuing, or provide clarity to decide when enough is enough. I would check whether people understood the consequences and could achieve their goal, rather than reward only more time or more taps.
