I've set the wedding date.
I've not asked her out yet.
It’s obviously ridiculous when you say it out loud, but in software we do versions of this all the time. We decide when something will be delivered before we’ve really understood what it is, agree scope before we’ve tested whether the idea works, and commit to plans long before we’ve learned enough to know if those plans make sense.
Not because anyone is doing anything wrong. It’s just how organisations deal with uncertainty.
Early in a project, uncertainty is at its highest. That’s also the point where pressure for certainty is strongest. People want dates, budgets, roadmaps, something concrete to hold onto. It’s understandable, decisions have to be made somewhere. But there’s a tension here that rarely gets acknowledged: we tend to ask for precise answers at the exact moment precision is least available.
There’s a concept called the Cone of Uncertainty which describes this quite neatly. At the start of a project, estimates are highly unstable. As understanding increases, they become more reliable. We tend to acknowledge this in theory, then ignore it in practice.
Plans get made anyway. Dates get fixed anyway. Confidence gets implied anyway.
A more recent response to this has been product discovery. The idea is simple. Learn about the problem before committing too heavily to solving it. Talk to users, test assumptions, reduce risk by increasing understanding.
In theory, it is a way of delaying certainty until there is something real to base it on. In practice, it often sits alongside planning processes that still expect certainty upfront, so both things exist at once. We say we are learning, but still behave like we already know.
A few years ago, I worked on smaller teams where this tension was less visible. There was less distance between building something and seeing it used. You would ship something, watch what happened, then adjust. Sometimes that meant changing direction completely, sometimes it meant discovering the problem was not what we thought it was at all. It was not always tidy, but it was immediate.
As organisations grow, that immediacy gets replaced with structure. Roadmaps, planning cycles, delivery forecasts. None of these are inherently bad things, they exist for good reasons. But they introduce a kind of false precision, where the plan starts to feel more certain than the thing it describes. Once that happens, it becomes harder to change, because changing a plan looks like uncertainty, even when it is just learning.
That is the part I keep coming back to. Not that planning is wrong, but that we often become most confident at the exact moment we know the least. And software rarely behaves in a way that rewards that confidence.
We say we are learning, but still behave like we already know. It's not entirely different to what happens when MVPs become exercises in polish rather than learning.
The interesting part usually comes later, after the dates have been set, after the roadmap has been agreed, after the assumptions have finally met reality.