Good Enough Was Never the Problem

There's a zipper on a bag that never shipped.

Everything about it was right, the weight, the tooth, the pull. It had cleared every check at the sampling stage, but somewhere between that and final sign-off a minor rattle surfaced at the pull end, barely perceptible, the kind of detail most people would never register. I called the sample back and sent for another.

By the time it arrived, I'd also revisited the lining spec, reconsidered the base, and started questioning the strap width. The zipper had been fine all along. The rest of it wasn't.

The Two Kinds of Perfectionism

Perfectionism has a good reputation in product design. It reads as rigour, as taste, as the mark of someone who genuinely cares. In the right part of the process, it is all of those things.

There's a version that genuinely helps, catching real problems early, before tooling is locked, when errors are still cheap to find and easier to fix. That version makes better products.

And there's a version that does quiet damage, the kind that reopens settled decisions, applies new criteria to work that was already closed, and mistakes personal preference for genuine necessity. It doesn't improve the product. It delays it, and gradually it erodes whatever confidence you've built in your own judgement. When every call is back up for review, the message underneath is that nothing is ever truly decided, just temporarily paused.

The Real Cost of Displacement

The zipper was fine the first time.

What actually happened wasn't that I caught a problem, it's that I created one. The rattle gave me a reason to stall on something that hadn't been fully resolved, and rather than naming that directly, I attached the uncertainty to a detail that was easier to point at.

That's the real cost of perfectionism in product development, not the time it takes, but the displacement. The inability to say this is what I'm actually uncertain about, so instead you keep auditing the zipper, the lining, the strap, generating surface noise to avoid sitting with the actual question.

What Actually Changes

The fix isn't lower standards. It's clearer thinking about which decisions are closed and which are still open, and writing that distinction down somewhere you'll see it. I keep that kind of working thinking in the Interface Notebook, what's settled stays settled unless something genuinely new arrives, and what's still open stays visible until it isn't.

Perfectionism applied at the right moment is a standard worth holding. Applied at the wrong one, it's usually a sign that something else hasn't been named yet.

The zipper was fine. That was the thing that needed saying.