Drift: Why Your Journey Map Stopped Being True

Six weeks ago, your team ran a genuinely good cross-functional customer journey mapping workshop. Six or seven functions in the room, real alignment, a map that made the customer's actual experience visible in a way no individual dashboard ever could. People left energized. Someone even printed it and put it on a wall.

This week, Product shipped a change to onboarding. Small, sensible, well-reasoned on its own terms.

Nobody who pushed it was in the mapping workshop. Nobody who was in the workshop was consulted before it shipped. There was no reason for either group to think of the other. Mapping had ended. It was in the past.

Now the map on the wall describes a journey that, as of Tuesday, doesn't quite exist anymore.

The workshop did exactly what it was built to do. The map just has a shelf life nobody planned for.

What drift actually is

There isn't a precise word in most GTM vocabularies for a map that's still on the wall but has quietly stopped being true. Stale is close, but it implies simple neglect, like the map just needed dusting. What actually happened is more specific: reality moved, and the artifact didn't move with it. Not because anyone was careless. Because nothing in the process was built to notice.

Naming it precisely matters, because precise language is what lets a team act instead of just feeling vaguely uneasy about a wall poster.

This isn't a new problem, and it isn't unique to marketing. I saw a version of it firsthand working in healthcare technology, in a field that had already been forced to confront it. Clinical guidelines used to be published, printed, and treated as authoritative for years, until practitioners realized a static document in a fast moving field wasn't a reference anymore. It was a liability. The response wasn't updating it less badly. It was a different category of document: one built to be continuously reconciled against new evidence instead of periodically rewritten from scratch. The field called the result a living guideline. The name is the useful part. It isn't a document with a revision date. It's a document with a maintenance model.

Your journey map has the same problem, at a smaller scale and a faster clock speed. A pricing change, a support process shift, a reorg that moves who owns a handoff: any of these can make a mapped stage inaccurate within weeks of the workshop that produced it. If the map was built to fix sequencing debt, the stakes are higher still. A map that no longer reflects the real order of dependencies can quietly reintroduce the exact problem it was built to solve. If the map has no maintenance model, it doesn't matter how good the workshop was.

The two instincts that don't fix it

The first instinct is usually to schedule the fix: rerun the workshop every quarter. This solves for the wrong variable.

A full re-convening is expensive. Real time from real people across functions that don't report to each other. Running it on a calendar means paying that cost whether or not anything material actually changed. Do it when nothing's shifted, and the room nods through a status update. Skip a quarter because things felt quiet, and month five reveals what quietly broke in month two.

The second instinct is softer, and worse: trust someone to remember to update it. That isn't a plan. It's a hope. Without a named owner and a defined trigger, keeping it current becomes nobody's job the moment the workshop's energy fades, which is exactly when drift starts.

Neither fix addresses the actual constraint. The expensive thing, the room, the full cross-functional convening, and the necessary thing, noticing when reality has moved, don't have to be the same event.

Maintenance is not the same job as creation

The workshop is a founding event. It's where the map gets built, and it's worth the cost once, or rarely, when the map is fundamentally broken and needs to be remade. It was never designed to also be the maintenance mechanism. Asking it to do both jobs is why it keeps failing at the second one.

Maintenance needs to be cheap, distributed, and triggered by real events instead of a date on a calendar. A useful trigger list is usually short. A feature ships that touches a mapped stage. Pricing changes. A support escalation pattern shows up that didn't exist before. A reorg moves ownership of a handoff. None of these require reassembling the room. They require one person, the owner of that lane of the map, to spend twenty minutes checking whether the map still describes what's actually happening, and updating the one part that doesn't.

Drift is not one problem

Not every drift event needs the same fix, because not every drift event is the same kind of problem.

Say two teams, working independently, both build a re-engagement sequence for the same lapsed usage moment. Neither knew the other existed until a customer got both in the same week. That's overlapping drift, sitting in the process layer: two workstreams solving the same customer moment without knowing it. The fix is coordination. Someone has to notice the overlap and consolidate ownership. It's a smaller, earlier version of a pattern worth its own space: why separate teams end up solving the same problem before anyone planned it that way.

Now say the map still lists a team as the owner of a handoff that moved to a different team eight months ago, in a reorg nobody updated the map for, including the customer-facing language about who to contact. That's outdated drift, sitting in the positioning layer this time, not process. The fix isn't coordination. The map is accurate about what exists and wrong about who owns it and what customers are told. That's a correction, not a negotiation.

Same underlying failure. Reality moved, the map didn't. Different type, different layer, needing different people to fix them. There's a fuller breakdown of drift types and the layers they tend to show up in, in the companion log built for tracking this. It's worth its own space rather than a paragraph here.

Logging and deciding are different jobs

Cheap, distributed logging solves detection. It doesn't solve judgment: deciding when a handful of small drift events add up to something worth a room full of people again. That's a separate, smaller job. A short, regular synthesis, not a full re-convening.

The people logging drift as it happens don't need to be the same people deciding what to do about the accumulated pattern. Keeping those two jobs distinct is what keeps the second one short and high signal, instead of turning into another standing meeting that slowly becomes theater.

A map maintained this way stops being a monument to the day it was made. It becomes what it was always meant to be: a reasonably current description of what your customer is actually experiencing. That's a lower bar than perfect, and a much more achievable one than permanent.

---