When Everyone Wants Certainty You Don't Have

This week, I was working on the next phase of a large transformation.

Creating the vision was the easier part. At that level, you can talk about where you're going, what you're trying to change, and what the future could look like.

Then the questions got more specific.

Leadership wanted the roadmap. The teams downstream wanted clear requirements so they could start planning. The people being asked to support the plan wanted enough certainty about the outcome to put their names behind it.

All fair questions. Except we were still in the concept phase — shaping the work while three groups critical to moving it forward were asking for a level of certainty we didn't have yet. And we couldn't simply wait until we did.

The Pressure: Certainty Before You're Ready

I've seen this tension repeatedly in transformation work. The closer you get to execution, the more people need specificity. Leaders need to make decisions. Teams need to plan. Stakeholders need to know what they're supporting.

But transformation doesn't always develop in that order. Sometimes you have to shape the roadmap before every requirement is known. You have to make decisions while dependencies are still emerging.

This is especially true in AI and other emerging areas, where some of what you need to know can only be learned by doing the work.

So you're caught between two risks:

• Move too early, and you may commit to things you don't yet understand.
• Wait for certainty, and the work may never move.

What's Really Happening

Under that pressure, the instinct is often to resolve everything. Add more detail. Get answers to every open question. Put dates against the roadmap because people need dates.

But not every unknown is equally important.

• Some uncertainty prevents the next move.
• Some matters three steps from now.
• Some will resolve as the work progresses.

Treating all of it as equally urgent creates a lot of activity without necessarily creating clarity.

The better question is: What specifically needs to become clear for us to take the next meaningful step?

Create Clarity Around the Next Move

Start with what you actually know

What decisions have been made? What constraints are real? What information do you have enough confidence to work from?

Identify the next meaningful move

Not "finish the roadmap." Something concrete: approve the direction, validate a use case, start discovery, make a technology decision, or give a downstream team enough definition to begin planning.

Work backward

What has to become clear for that move to happen? Which decision is blocking it? Which assumption needs to be tested? Which dependency needs to be resolved? What information does the next team actually need?

Those are the uncertainties worth working on now. Everything else can remain visible without being resolved yet.

Key takeaway: Sequence matters. If you need to learn A before you can decide B, and B determines C, trying to create certainty around C today isn't better planning — it's working out of order.

Letting the Rest Wait

When everyone wants certainty you don't have, don't try to eliminate all the uncertainty at once.

Resolve what's needed for the next move. Keep the remaining unknowns visible, but let them wait until the sequence requires them.

In complex work, you rarely create clarity everywhere at once. You create it where it's needed next — and use it to keep the work moving.

Try this: Map your current unknowns, then ask which ones actually block the next meaningful move. Work on those first. Leave the rest visible but unresolved until the sequence demands them.