One of my better habits as a product manager is also one of my worse ones.

I keep finding another question.

What happens when there are multiple agents? What happens without a particular identifier? What if the customer already has this information elsewhere? Will the user understand this term? Does the object still make sense if the workflow changes?

That instinct has helped me catch problems before they became product decisions.

It can also keep a decision open for too long.

I noticed this while working through several product models where every new scenario improved the design a little. At first, the improvement was meaningful. An assumption would break, we would revise the model, and a previously awkward case would suddenly make sense.

Eventually something changed.

We were no longer discovering structural problems. We were debating possibilities.

That made me think about uncertainty differently.

Some uncertainty can be reduced by reasoning. If three sessions can contribute to one business outcome, I can test whether a session-level economic model still makes sense. If two parts of a platform can independently calculate the same price, I can reason about what happens when they disagree.

I do not need to ship anything to discover those problems.

Other questions are different.

Will developers actually provide this metadata consistently? Will customers understand the terminology?

Will anyone use this filter? Does this workflow occur frequently enough to deserve its own object?

I can form an opinion, but there is a point where another discussion produces almost no new information.

The answer has to come from reality.

A question I increasingly use on myself is:

“What would I need to learn to change this decision?”

If the answer is another scenario we have not thought through, I probably need to keep thinking.

If the answer is user behavior, implementation experience, or production data, then thinking has reached its limit.

Reversibility matters too.

I am comfortable moving quickly on a label or a UI arrangement because it can be changed. I am more cautious about a public API, a billing rule, a core product object, or something developers will embed throughout their applications.

The cost of being wrong is different.

I used to think rigor meant resolving as much uncertainty as possible before something was built.

I think about it differently now.

Rigor is also knowing which uncertainties deserve to remain unresolved until the product encounters the world.

Sometimes shipping is not what happens after the thinking is finished.

Shipping is how the thinking continues.