Learning to Sit With Not-Knowing

Aerial view of a single white wind turbine in green farmland, with a pale road winding and forking up through paddocks and patches of forest to reach it.
You can see the turbine, but the road only ever shows you the next bend.

There is a particular silence that falls in a room when someone asks a question no one can answer yet. A stakeholder wants to know which of three directions the product should take. Engineering wants to know the shape of the thing before they estimate it. Support wants to know what to tell the customers who keep asking. And the honest answer, the one almost nobody says out loud, is: we do not know yet. We have not seen enough to know.

What happens next tells you a lot about a team. Most of us reach for something to fill the silence. A firmer estimate. A roadmap with more rows. A metric that looks precise. A decision framework with named quadrants. Anything that converts the discomfort of not-knowing into the comfort of an artefact. This quarter I am writing about navigating complexity, and the first thing worth naming is that a lot of what we call rigour is really a fear of ambiguity wearing a suit.

Why we flinch

The flinch is understandable. Not-knowing feels like a failure of the job. A product manager is supposed to have the answer, or at least a plan that looks like one. Ambiguity reads as being unprepared, and being unprepared reads as being replaceable. So we manufacture certainty. We turn a genuinely open question into a task with a due date, because a task can be tracked and a due date can be reported, and both of those feel like progress even when the underlying question is exactly as open as it was that morning.

I have done this more times than I would like to admit. Faced with a problem I could not yet see clearly, I have written the confident one-pager, sized the work to the day, and presented a roadmap that implied I understood the terrain. Some of that was useful. Most of it was a way to stop feeling the discomfort of not knowing, and it usually cost the team a fortnight of building the wrong thing with great conviction.

The trap is that some work genuinely is knowable in advance and some genuinely is not, and we treat them the same way. Setting up a deployment pipeline, migrating a known dataset, wiring a payment provider you have used before: that work is complicated but not uncertain. You can plan it, and a plan is the right tool. But deciding what a confused customer actually needs, or whether a new market wants the thing at all, or how a team should reorganise around a shift you can only half see: that work is a different kind. You cannot reason your way to the answer up front. You act, you watch what happens, and the sense of it usually only arrives afterwards, looking obvious in hindsight in a way it never was at the time.

Treating the second kind like the first is where the fear does its damage. We demand a plan for something that can only be learned, and then we defend the plan because we said it out loud, long after the ground has told us it was wrong.

Not-knowing is not the same as drifting

I want to be careful here, because sitting with not-knowing is easy to confuse with dithering, and they are opposites. Drifting is avoiding a decision you already have enough to make. Sitting with not-knowing is refusing to fake a decision you genuinely cannot make yet, while actively working to earn it.

The difference is whether you are doing anything to close the gap. A team that is drifting talks in circles and waits for clarity to arrive on its own. A team that is sitting well with uncertainty is doing the opposite: running the small experiment, having the customer conversation it has been avoiding, shipping the narrow slice that will teach it something real. It holds the question open on purpose, and it moves toward an answer at the same time. That is not indecision. It is the discipline of not deciding before you can see.

There is a useful habit hidden in that. Before you decide, spend real effort on where you are looking. Two people staring at the same dashboard will read completely different situations depending on what they already believe, what they have lived through, and what they are afraid of. Most bad calls I have watched, including my own, were not failures of decision. They were failures of orientation. We decided crisply from a picture of the world that was already wrong. Slowing down to check the picture, to ask what we are actually seeing and what we might be missing, is not a delay. It is the part of the work that makes the eventual decision worth anything.

A rough map beats a false forecast

None of this means flying blind. The way out of the fear is not more courage, it is a better relationship with uncertainty, and the practical form of that is a map rather than a forecast.

A forecast pretends to know the future: here is what will happen, here is when, here is how much. A map only claims to show the terrain: here is roughly where we are, here are the parts that are settled and the parts that are still moving, here is what looks like a cliff. A map is honest about what it does not know, and that honesty is exactly what makes it useful. You can act from a rough, truthful map. You cannot act well from a precise, confident fiction, though it is much more comfortable to present.

In practice this looks ordinary. It is a short written picture of the problem that says plainly what is known, what is assumed, and what is still genuinely open, rather than a plan that quietly launders assumptions into facts. It is the willingness to write "we do not know this yet, and here is the cheapest way to find out" as a line item, next to the things you are sure of. It gives the team something real to stand on without asking anyone to pretend.

It also changes how you spend time. If you cannot know the full scope of an uncertain piece of work, you can still fix how much of the team's attention it is worth right now, and let the scope flex inside that. Decide the effort, hold it firm, and treat the question of what fits as the interesting one. That is a way of committing to a direction while staying honest that the details will move. You are not promising the destination. You are promising to keep walking and keep looking.

What I am practising

I do not think the fear of ambiguity ever fully goes away, and I am sceptical of anyone who says theirs has. What changes is your tolerance for the silence, and what you do with it.

The habit I am trying to build, and mostly failing at in the usual human proportion, is to notice the flinch. To catch the moment I am about to convert an open question into a false certainty just to feel better, and to ask instead: what is the smallest thing we could do this week to actually see more? Sometimes that is a customer call. Sometimes it is a narrow build. Sometimes it is simply saying to the room, out loud and without apology, that we do not know yet, here is what we are doing to find out, and here is when we will decide.

That last sentence is harder to say than it sounds, and more respected than you expect. Teams do not lose faith in a product manager who admits the terrain is unclear and shows a genuine way through it. They lose faith in the one who was certain and wrong, and certain again the next time. Not-knowing, held well, is not weakness. It is the beginning of actually seeing the thing, which is the only place a good decision has ever come from.

The next time the room goes quiet on a question you cannot yet answer, resist the urge to fill it with a plan. Fill it with the smallest honest step toward seeing, and say when you will decide.