Your product trio has interview notes, dashboards, support themes, and strong opinions. Yet when the next customer conversation begins, the team still isn’t sure which assumption matters most. That is the problem experience mapping should solve.

A useful experience map turns scattered knowledge into a visible, testable model of the customer’s experience. It helps you find gaps, design sharper interviews, identify opportunities, and decide what to learn before anyone starts defending a solution.

Set a boundary your team can actually investigate

An experience map is a visual hypothesis of what a customer does, thinks, encounters, and decides while trying to make progress. It is not a diagram of your product’s navigation, and it should not begin automatically at login or end at checkout. The customer’s experience may start before your product appears and continue after the final screen.

Scope determines whether the map will produce useful discovery questions. Map one isolated interface and you may miss the conditions that created the problem. Map the customer’s entire relationship with the company and the result may be too broad to influence a decision. Anchor the boundary to the outcome your team is responsible for.

Scoping decision	Question to answer	Common mistake
Outcome	What customer or business change is this discovery work meant to influence?	Using a feature launch as the outcome
Actor and context	Which customer is acting, and under what conditions?	Blending administrators, end users, approvers, and buyers into one generic user
Starting event	What happens that causes the customer to begin this experience?	Starting at the first product screen instead of the trigger in the customer’s world
Ending event	What observable event marks success, failure, abandonment, or a handoff?	Ending when your workflow ends even though the customer’s work continues

Suppose the desired outcome is more successful first campaign launches. A map of the setup wizard alone is probably too narrow. The relevant experience might begin when an operator receives campaign requirements and end when the campaign is verified as running correctly. That boundary exposes preparation, missing inputs, approvals, error recovery, and validation rather than treating completion of the wizard as success.

Write the scope as one sentence before drawing: This map follows a specific actor, beginning with a specific trigger, until a specific outcome or terminal event. If the team cannot complete that sentence, it is not ready to debate the map.

Build three rough maps before creating one shared map

The first shared drawing should not be created through open-ended group discussion. When everyone talks while one person draws, differences can disappear before they become visible. Give each member of the product trio the same scope and let each person map it independently.

A practical starting cadence is 20 minutes for individual mapping, 45 to 60 minutes for comparing perspectives, and a separate 30-minute co-creation pass. These are working timeboxes, not quality targets. The objective is to expose what each person believes, not to produce presentation-ready artwork.

Pass one: draw the experience individually

Use boxes, arrows, labels, and stick figures. Drawing skill is irrelevant. The constraint matters because a box forces you to name a moment and an arrow forces you to state what leads to what.

Represent one distinct action, event, or decision in each node. Include the normal path, but also draw retries, loops, delays, handoffs, error cases, and abandonment. Those branches often contain more discovery value than the happy path.

For each important node, capture the context that changes its meaning:

• What is the customer trying to accomplish at this moment?
• What do they do next, in observable terms?
• What information or input do they need?
• Where do they hesitate, fail, wait, or leave?
• What workaround do they use when the intended path breaks?
• Who else becomes involved?
• What are they thinking or feeling, and what evidence supports that interpretation?

Keep product features out of the node names unless the customer’s action genuinely requires one. Opens billing settings is a product-centered label. Tries to understand an unexpected charge describes the customer’s work and leaves room to discover how that work happens across email, invoices, help content, colleagues, and the product.

Be especially careful with thoughts and emotions. They are useful only when treated as hypotheses or grounded in customer evidence. Adding frustrated to every difficult step makes a map look empathetic without making it more accurate.

Pass two: synthesize without erasing differences

During the comparison, each person explains the reasoning behind the map while the others ask clarifying questions. The team is looking for differences in structure, not judging whose drawing is best.

1. Collect every unique customer moment from the individual maps.
2. Arrange the moments into a broad sequence without forcing every customer onto one linear path.
3. Collapse nodes only when they describe the same moment, actor, intent, and context. Similar wording is not enough.
4. Add arrows for forward movement, loops, retries, handoffs, errors, and exits.
5. Attach the relevant actions, thoughts, feelings, friction, and workarounds.
6. Preserve disputed sequences or interpretations as visible branches.
7. Mark the places where the team lacks evidence.

A shared map is not the average of three perspectives. It is a more complete model that retains meaningful variation. If one map shows a customer retrying while another shows the customer contacting support, keep both branches until evidence tells you when each occurs.

Treat disagreement as an interview backlog, not a meeting problem

When two team members disagree about the customer’s experience, the goal is not to reach consensus through persistence or seniority. The disagreement is information. Draw it precisely enough that it can be investigated.

Most mapping disagreements fall into a few actionable forms:

• Sequence: the team disagrees about what happens before or after a moment.
• Path: the team expects different next actions, such as retrying, seeking help, delegating, or abandoning.
• Cause: everyone sees the same behavior but explains it differently.
• Population: the experience may vary by role, context, or customer type.
• Prevalence: multiple paths exist, but the team does not know which is common or consequential.

I recommend giving every material node or connection one of four evidence labels:

• Observed: the team has direct behavioral evidence for this moment.
• Reported: a customer described the behavior in a concrete past experience.
• Assumed: the team believes it happens but cannot yet support the belief.
• Conflicting: available evidence supports more than one interpretation.

The legend prevents a polished map from implying equal confidence everywhere. It also makes interview planning faster: start with assumptions and conflicts that could materially change how you understand the outcome.

Turn each disputed branch into a question about a real event. If the map assumes that an administrator retries after an import failure, do not ask, Would you retry? Ask the customer to describe the last import failure, what happened immediately afterward, what they tried, who became involved, and how the situation ended. A hypothetical answer tells you what sounds reasonable. A recent example gives you a sequence to compare with the map.

Useful prompts follow the structure of the experience:

• What was happening when you first realized you needed to do this?
• What did you do first?
• What happened immediately after that?
• Where did you pause, repeat a step, or change direction?
• What information were you missing?
• Did you involve anyone else? What did they do?
• What did you try when the expected path did not work?
• How did you decide you were finished, or decide to stop?

Update the map while the conversation is still fresh. Add missing moments, split nodes that hide distinct situations, and retain variants that matter. One interview can contradict an assumption or reveal a branch; it cannot establish that every customer follows the revised path.

Make the map change the next discovery decision

An experience map is not a roadmap, a requirements document, or proof that an opportunity is valuable. Its job is to improve the decisions surrounding discovery.

Use it to decide whom to recruit. If the critical uncertainty concerns customers who abandon after an approval handoff, a general sample of active users may not resolve it. Recruit people who recently encountered that handoff, including those who did not complete the experience.

Use it to decide what to ask. Each uncertain node should produce a small set of behavioral questions. Each disputed arrow should produce questions about sequence and causality. This creates an interview script tied to consequential uncertainty rather than a generic tour of the customer’s job.

Use it to decide what to measure. A funnel may reveal where behavior changes, but it rarely explains the surrounding intent or workaround. The map supplies hypotheses about meaningful branches. Instrumentation can then establish how often those branches occur, for which customers, and how they relate to the outcome.

Use it to identify opportunities without jumping to features. Look for moments where customers cannot make progress, repeat work, wait for another actor, assemble missing information, create a workaround, or abandon the attempt. Phrase the opportunity as a customer need or obstacle at that moment. Keep the proposed feature separate.

The experience map and opportunity solution tree serve different purposes. The map shows a sequence of customer moments and branches. The tree organizes the desired outcome, customer opportunities, possible solutions, and tests. Use the map to discover and locate possible opportunities; use the tree to structure choices about which opportunity and solution to pursue.

A simple operating loop keeps the artifact useful:

1. Select the outcome and map boundary.
2. Create individual maps and synthesize the shared hypothesis.
3. Mark unsupported nodes, disputed links, and consequential branches.
4. Choose the uncertainty most likely to change a discovery decision.
5. Recruit customers who have encountered that part of the experience.
6. Investigate recent behavior and update the map.
7. Translate supported friction or unmet needs into candidate opportunities.
8. Repeat as new evidence changes the model.

You can tell that the practice has drifted when the map mirrors your screen sequence, contains only a happy path, describes every moment with broad labels such as onboarding, or remains unchanged after customer conversations. A visually polished map that does not alter recruitment, interview questions, instrumentation, or opportunity selection is documentation, not discovery.

Key takeaways

• Scope the map around a desired outcome, a specific actor, and observable starting and ending events.
• Have every trio member draw independently before creating the shared map.
• Map customer actions, decisions, handoffs, errors, workarounds, loops, and exits rather than product screens.
• Preserve disagreement as branches and evidence gaps that can be tested in customer interviews.
• Keep the map alive by using it to change recruitment, interview questions, measurement, and opportunity selection.

For your next discovery cycle, choose one outcome and map the smallest end-to-end experience that could explain it. Stop before the drawing feels finished. Take its most consequential disputed branch into the next customer conversation, then revise the model from what you learn.

References

• Shivam.Consulting Blog — March CDH Book Club: Master Experience Mapping to Align Teams and Accelerate Discovery

---