Main idea

A document that gathers what a team knows about a product opportunity — the business, the customer, the user, the technology, the standards, the competition, the history of decisions — can be nothing more than a pile of facts. Everything in it then looks equally weighted, and reading it does not say where the team is solid and where it is moving blind.

What changes the nature of the document is a writing constraint: marking, for each element, whether it belongs to what you know, what you believe, what makes you doubt, or what goes unsaid. The last two registers are the ones missing everywhere else — a specification has no room for a doubt, and a framing presentation erases any trace of one.

So the value of the document is not in accumulating context, it is in forcing you to qualify what you hold. What becomes visible after that qualification is the risk areas: the places where a decision rests on a belief nobody has checked.

Why it matters

It gives you a criterion for judging a framing document without judging its content: if it contains no doubt and nothing left unsaid, it was not written, it was presented.

It also shifts what a team should expect from alignment. Agreeing on facts costs nothing; agreeing on what you believe without knowing it is what surfaces disagreements before they get paid for in development.

Nuances and limits

The distinction is unstable over time: a verified belief becomes knowledge, and knowledge ages and turns back into a hypothesis. The document only holds if it is dated and revisited, otherwise it freezes an expired qualification.

And some teams cannot write down their doubts safely: in an organization where displayed uncertainty is punished, the "what makes me doubt" column stays empty for reasons that have nothing to do with the subject.

Open questions

• What is it, in the way a team works, that makes writing down a doubt safe enough to be done honestly?