The five lenses I run before I touch code

Most builders build for one person. Themselves. Then they act surprised when the product is brittle.

I learned this the slow way. Now I run every brief through five lenses before I write a line. Each one is a different person reading the same plan and noticing different things.

The user. What is the actual job they're trying to get done? Not what I think they want. What they would say if I asked them. If I can't write a sentence the user would nod at, the brief is wrong.

The skeptic. What's the strongest version of the argument against this? Not the lazy version. The argument made by someone smart who has seen this fail before. If I can't articulate it, I'm building on top of an assumption I haven't tested.

The next builder. Six months from now, someone has to extend this. Maybe me, maybe someone else. What will they curse? What will they need to know that isn't written down? If the answer is they'll figure it out, I'm offloading complexity onto a future person who won't have the context I have today.

The operator. Three months in, this thing is in production. What breaks? Who pages? What does the runbook look like? If I can't write the runbook before I write the feature, I haven't designed the feature. I've designed an aspiration.

The accountant. What does this cost in time, in money, in maintenance, in attention? What's the smallest version that proves the same thing? If I'm not embarrassed by how small the first version is, the first version is too big.

Five lenses. Maybe twenty minutes of writing. The brief comes out of the other end with most of its weak points already named.

The cost of this exercise is small. The cost of not doing it is everywhere. In the bug you'll ship. In the assumption you didn't test. In the user you didn't actually talk to. In the runbook you'll write at 2am.

Most "agile" is the absence of this discipline dressed up as a virtue. Speed without lenses is not speed. It's just rework, deferred.