Why documentation exists
Early documentation gives PM, UX, and engineering room to explore a problem before agreeing on a solution. The PRD, or equivalent closing document, comes later. Writing it before discovery treats an initial description as a decision before the team has enough evidence.
Improvement work needs a shared account of Where We Are, including the existing system and its constraints. New-feature work has no existing feature to work from, so its account of People must provide that context.
Eight clarity concerns
These eight concerns recur across the documents. Each needs less room for interpretation as the work approaches tickets and code.
1 · Problem
Agree on why the work is needed before moving on. Uncertainty belongs here. Defining the problem too precisely, too early, can conceal a solution choice inside it.
2 · Direction
Describe the outcome the work should produce, leaving the solution open. UX can begin exploring alternatives here. Beyond this point, the shape of the solution starts to matter.
3 · Where We Are (improvement work only)
Describe how the current system works, what is broken, and which constraints apply. Otherwise, the first week of improvement work goes into reconstructing this baseline.
4 · People
Describe who is affected, what they are trying to accomplish, and the conditions they work under. New-feature work depends on this account for orientation. Improvement work can also draw on Where We Are.
5 · Scope
Record what is in scope, what is excluded, and what remains undecided. Open questions should shrink as discovery tests the scope. An unchanged scope suggests those decisions are not being challenged.
6 · Slices (stories)
Describe units of value for users loosely enough to allow exploration. Tighten them into tickets later, in the PRD or backlog. Difficulty writing slices usually means the direction needs more detail.
7 · Constraints
Keep the legal, technical, deadline, non-functional, and integration constraints brief. A long list suggests that scope decisions have been recorded as constraints.
8 · Acceptance Criteria
Write binary pass/fail conditions that engineering can build and test against. If these are hard to write, earlier documents still leave decisions unresolved.
Three readiness thresholds
Each function can start once the artifacts it needs are clear enough. A single readiness gate can bring UX in too late or require detailed commitments too early.
PM can frame (after Direction)
Problem and direction are enough to frame the work and begin exploration. Waiting for people, scope, and stories to be settled can leave UX arriving after the decisions have been 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)
Earlier artifacts prepare engineering gradually. Acceptance criteria supply the last decisions needed to build without inventing what the documents left out.
Zoom out
04 · Learning & Feedback examines these decisions across an organisation, including which paths can run sequentially and which must remain open to evidence. Ambiguous Documents follows the documents used along one such path.
Prematurely final documents repeat the wider organisational mistake of treating uncertain work as settled.