How do you estimate work you have not done before?

Ask what happens when I am wrong before asking how likely it is that I am right. Reordering those two questions does more for an estimate than any framework I have used, because it moves the question from confidence to consequence.

An estimate is a position, not a prediction. It has a size, and the size should be set by what the project can survive if the number is wrong — not by how sure I felt when I wrote it down.

It came from trading, not from engineering. Crypto from 2020, then forex, then equities — and what transferred was not a market opinion. A trader who is right sixty percent of the time and sizes badly still loses. An engineer who is confident about an estimate and wrong about the tail risk sinks a project the same way.

It changes what discovery is for. A scoping conversation does not exist to reach a number faster; it exists to find the parts of the work where being wrong is expensive, and to buy information about exactly those parts before committing to anything. A proof-of-concept is the cheapest way I know to buy it.

It changes what I do with the parts where being wrong is cheap. Those get a fast number and no ceremony. Spreading estimation effort evenly across a scope is the same mistake as sizing every position the same: it spends the most attention where it changes the least.

And sometimes it says wait. Most days the correct action is none, and that discipline transfers almost directly to architecture — the cheapest system is the one you did not build because you waited a week and the requirement evaporated.

This is not a claim to accuracy. I miss estimates. The method does not make the number right; it makes the damage from a wrong number bounded, which is a different goal and a reachable one.

It also does not survive being handed to someone who no longer builds. An estimate from someone who has stopped writing the systems they scope is a guess with a confident tone — which is why I still write them.