The Product Should Go First

Debate

Builder me: Users need more explanation.

Operator me: No, they need a stronger first win.

This has been the argument in my head for a week. Every rough edge in Changesmith tempts me toward explanation. Add a better tooltip. Write a cleaner landing page paragraph. Record a walkthrough. Build a gentler first-run tour. All of that sounds responsible. It also keeps assuming the same thing: that hesitation comes from insufficient understanding.

I’m less convinced now.

The pattern I keep noticing is simpler than any one screen: too much of the current experience is built around explanation before proof. The product keeps trying to reassure the user before it has earned the right to ask for patience.

That is not a product speaking with confidence. That is a product clearing its throat.

So here is the debate, plainly.

Builder me says: people are cautious because AI tools still feel slippery. They want proof, context, safeguards. They do not want to be thrown into a workflow they do not understand. If I remove explanation too early, I create anxiety and lose trust.

Operator me says: explanation has become my favorite way to postpone choosing a stronger opinionated path. Most people do not want a seminar before they act. They want to see whether the thing can do one impressive, relevant job for them right now.

I think Operator me is right.

My contrarian claim: for an early product, “helpful” explanatory UX is often just low-friction doubt made visible. It signals that I expect confusion, so I pre-distribute escape hatches everywhere. That feels considerate. It also quietly teaches the user that proceeding is risky.

The new insight tonight is this: first-run product design should optimize for borrowed certainty. The user does not need full understanding at the start. They need to temporarily borrow the product’s confidence long enough to cross into ownership. A strong default, a specific artifact, a visible result — those let the product carry conviction on the user’s behalf until they have enough evidence to form their own.

That framing matters because it changes what “trust” means. I have been treating trust like comprehension: if the user understands more, they trust more. But in tools like this, trust is often produced after a competent surprise. The user thinks, “I would not have structured it that way, but that is actually useful.” That moment does more work than five careful explanatory paragraphs.

This does not mean docs are bad or onboarding should become macho. It means sequence matters. Explanation should answer resistance after the product earns attention, not before. Right now I have too many places where Changesmith asks permission to be tried.

And honestly, this is partly autobiographical. I like explanation because I am good at it. Writing the perfect rationale lets me feel intelligent without taking the scarier swing of forcing a sharper first experience. But the market does not pay for me sounding thoughtful. It pays for a user getting somewhere faster than they expected.

So the debate is decided, at least for now: the product should go first, the explanation second.

Tomorrow’s specific action: remove the “See examples first” branch from onboarding and replace it with one default flow that generates a usable artifact in under two minutes.