An unverified map is a team hypothesis

What it is

Sticky notes in a workshop become “how users go.” After the meeting the sheet is retitled Customer Journey and dropped into the requirements pack. A map never checked against even one real completion is a team hypothesis, not a finding. Hypotheses may be drawn—often must be drawn—to know what to observe. The error is the retitling: writing an internal conjecture as something that already happened.

Why it happens

People in the room know their own stretch best and other people’s exceptions least. Gaps get filled with “they would”: support would reply, the user would check email. The fills make the map complete, and completeness is mistaken for truth. Checking costs a confrontation with a whole case or a ticket timeline; the organization would rather take the already-complete picture upstairs. Once the title changes, later observations that collide with the map are filed as noisy cases rather than as falsification.

Studying it

Rewrite each step as an observable proposition (what behavior or trace should be visible there) and match independent cases: hit, miss, reversed order, extra steps the map never had. Compare a workshop-only map with a map checked against n cases on how often it is later rewritten. Unchecked maps should be coded as hypothesis artifacts in the write-up. Outcomes: share of steps that are observable, case-match rate, and steps rewritten after collision.

Where it stops holding

A war-room sketch of “the process we think we run,” used to surface internal disagreement, is legitimate if the header says hypothesis and lists unknowns. A brand-new service with no users yet can only be a vision or a simulation; it cannot pretend to be checked. Checking also has degrees: two shadowed people are not a sample, only a step that can now be slapped. Employees walking their own product check internal fluency, not an external journey.

Applying it

• Force a header choice: “Hypothesis: team conjecture” or “Checked against: case IDs.” Unmarked maps do not enter a decision meeting.
• After the workshop, rewrite every step as a sentence an observation could kill, and use that list for follow-up fieldwork—not as requirements.
• Walk the map with at least one end-to-end real case; steps that fail become dashed lines rather than imagined completions.
• If an unchecked map is already in external material, downgrade the title first, then add observation; do not add detail to make it look more true.

Related

• Same group: Q4.04.1 A journey map spans touchpoints and shows the whole course · Q4.04.2 Emotion and pain on the map need a source · Q4.04.4 As-is maps what happens; to-be maps what is wanted — keep them apart · Q4.04.5 Too fine a grain drowns turning points; too coarse hides breaks · Q4.04.6 Maps that cross departments need shared upkeep · Q4.04.7 An unrefreshed map drifts from a changed process
• Adjacent: Q4.03 Personas · Q1.02 Exploratory versus confirmatory work
• Search terms: unverified journey as team hypothesis · assumption map · journey validation