Working with ambiguity

In product work, most things aren't clear at the start. A request comes in but the need behind it hasn't been fully explained. The business side wants a result, but it's not always obvious which problem we're solving. A user says what they want, but what they say sometimes doesn't directly point to the real need.

This is a natural part of product work. The issue isn't that the topic is unclear at first; the issue is treating the ambiguity as if it doesn't exist.

For me, a good start isn't crafting big statements or jumping straight to solutions. The topic comes first. Who is this for, which problem are we trying to solve, what happens if we don't solve it today, what changes if we do? Work done without answering these questions often looks like progress but actually scatters.

A misunderstood topic doesn't reach the right outcome, no matter how well it's managed.

That's why the most valuable work on the product side is sometimes not designing a new feature but describing the existing request correctly. Simplifying a sentence, leaving out a few unnecessary headings, making the real need visible: these moves seriously ease the work.

Waiting for everything to become completely clear isn't right either. You usually won't have all the information. Some details emerge later. Some decisions clarify as the work moves forward. What matters here is not moving blindly with missing information, but moving forward while knowing what you don't know.

In these situations I try to bring the topic into a small, clear frame. First I describe the matter. Then I separate out its boundaries. Then I pick the first step as small and meaningful as possible.

Because if the first step is chosen well, the work starts to reveal itself.

Speed is sometimes misunderstood on the product side. Speed isn't doing everything at once. Speed is seeing early what matters and putting energy in the right place. Otherwise the team works hard, meetings happen, things get discussed, and the result stays unclear.

Good product work starts here, I think. Starting without knowing everything, but moving forward knowing what you don't know.

Ambiguity may not disappear completely. It doesn't need to. When the topic is understood correctly, the first step chosen well, and progress made visible, the work stops being a scattered idea.

From that point on, what's needed is simpler: keep the work moving, see where it gets stuck, and correct course when needed.