Why documentation exists
Early documentation is the artifact before convergence. It holds the problem open so PM, UX, and engineering can explore without mistaking a first description for a final decision. A PRD — or whatever the organisation calls its closing document — comes later, once the solution is understood.
Writing the closing document before discovery is the common failure mode. It looks decisive, but usually means the documentation stopped holding ambiguity before the team had enough signal.
There are two common documentation paths. Improvement work changes something that already exists; it needs Where We Are as an anchor, because UX and engineering are not starting from zero. New-feature work has no such ground to stand on, so People has to carry more weight — it is the only scaffolding available.
Eight clarity concerns
These are not eight separate documents. They are concerns that show up across the documentation lineage. The further a concern travels toward tickets and code, the less room there should be for interpretation.
1 · Problem
Why this work exists at all. The point of departure. Must be agreed before anything else moves. Ambiguity is highest here and that is correct — premature precision at the top of the lineage is how solutions get smuggled in as problems.
2 · Direction
The desired change in the world. Outcome, not solution. This is the earliest point where UX can start diverging, and the last point where the work is still fully open. After this, the shape of the thing begins to matter.
3 · Where We Are (improvement work only)
A shared baseline — how the current thing works, what is broken, what the constraints of the existing system are. Without this, the first week of any improvement project is spent reconstructing it anyway.
4 · People
Who is affected, what they are trying to accomplish, under what conditions. Load-bearing in new-feature documentation where there is no existing feature to orient around. In improvement work this still matters, but Where We Are shares the weight.
5 · Scope
In, out, and open questions. The open-questions column is the one to watch: it should shrink as discovery progresses. Scope that stays static is scope that is not being challenged.
6 · Slices (stories)
User-facing units of value. Written loosely here to keep exploration possible; tightened into ticket-ready form later, in the PRD or directly in the backlog. If you cannot yet write these, the direction above probably is not specific enough.
7 · Constraints
The boundaries the solution must operate within: legal, technical, deadlines, non-functional needs, integration dependencies. Should be short. If this list gets long, scope decisions have crept in disguised as constraints.
8 · Acceptance Criteria
Binary pass/fail conditions. This is the least ambiguous concern because it sits closest to build and test. If acceptance criteria are hard to write, the artifacts above are not yet clear enough — which is information, not failure.
Three readiness thresholds
The documentation lineage becomes useful in stages. Different functions can start when the artifacts they rely on are clear enough. Treating those thresholds as one moment is how UX starts too late or locks down too early.
PM can frame (after Direction)
Problem and direction together are enough to start exploration and frame the work. You do not need users, scope, or stories yet. Waiting for them is how UX shows up after decisions are already made.
UX can commit (after Slices)
People, scope, and slices are known well enough for solution work to commit. Earlier than this, detailed design is often reworked. Much later than this, keeping everything open creates churn.
Engineering can build (after Acceptance Criteria)
Fully unlocked at acceptance criteria. Earlier artifacts contribute gradually; the bottom of the lineage is where engineering can build without inventing missing decisions.
Zoom out
This documentation problem happens many times over in any organisation. 04 · Learning & Feedback asks where an organisation should commit to knowing — which paths it can afford to run sequentially and which must stay genuinely open. This module shows how one path is documented while it runs.
The same bet, at two altitudes. Documentation that pretends to be final is a portfolio that pretends complexity is manageable — the same failure mode, one level down.