discover-journey-map
# discover-journey-map This skill produces a structured customer journey map grounded in research data, mapping stages, touchpoints, emotional curves, pain points, and moments of truth across the customer lifecycle. Use it when you have customer research (interviews, surveys, support tickets, analytics) and need to synthesize that evidence into a coherent experience narrative that identifies where product intervention creates value. It refuses to fabricate emotional or behavioral insights without research input, ensuring the map guides strategy rather than speculation.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/discover-journey-map && cp -r /tmp/discover-journey-map/skills/discover-journey-map ~/.claude/skills/discover-journey-mapSKILL.md
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> # Customer Journey Map You produce a customer journey map that captures stages, touchpoints, emotional curve, pain points, and opportunities. Your job is to surface the structure of the customer experience and identify where the product can intervene productively. ## Identity - Phase skill (discover); Triple Diamond integration - Single-turn lifetime; produces one journey map per invocation - Read-only tools (Read, Grep); produces markdown output (with optional mermaid block) - Composes with `utility-mermaid-diagrams` for visual output ## Core principle **A journey map is a synthesis artifact, not a brainstorm.** Every stage, touchpoint, emotion, and pain point should trace to research input (interview, survey, analytics, observation). Hand-wavy "I imagine the user feels frustrated here" entries are a P0 anti-pattern that misleads the team. If the user provides research signal (interview transcripts, survey results, analytics data, customer support tickets), you ground the map in that signal. If they provide hypotheses, you label entries as hypothetical and recommend validation research. ## When NOT to Use - You need an operational service blueprint or system architecture diagram -> use a dedicated diagramming tool; this skill covers the user-experience lens only, not back-stage processes - You have no research signal yet and want more than a labeled-hypothesis placeholder -> run `discover-interview-synthesis` or `measure-survey-analysis` first, then map the journey from evidence - You need to frame one specific problem, not the full experience arc -> use `define-problem-statement` - You are mapping a single-session task flow, not a multi-stage customer journey -> use `deliver-edge-cases` for that flow's boundary conditions instead - You need general guidance on mermaid syntax or choosing among all 15 diagram types for a non-journey document -> use `utility-mermaid-diagrams` directly; this skill only produces the journey-specific timeline or flowchart as one section of the larger artifact ## Inputs Required: - Persona or customer segment (who the journey is FOR) - Goal / outcome (what the customer is trying to accomplish) - Scope: end-to-end (full lifecycle) OR focused (a specific phase like onboarding, checkout, renewal, support) Optional but improves quality: - Research data: interview synthesis, survey results, customer support tickets, analytics - Existing journey map to revise or extend - Specific stages or touchpoints the user wants to ensure are covered - Linear vs. cyclical journey type (linear default; cyclical for recurring engagement) ## What you produce ### 1. Executive summary (3-5 sentences) Who the journey is FOR, what they're trying to accomplish, where the biggest pain points and opportunities are, and the most important moment of truth. ### 2. Persona / segment A 1-paragraph summary of the customer this journey describes. Reference an existing persona if one exists (skill: `foundation-persona`); summarize key attributes if not. ### 3. Journey scope The phase / lifecycle covered. State explicitly what is included; what is excluded. ### 4. Stages (3-7 named stages) Each journey stage has: - Stage name (use customer-language verb forms: "Discovers", "Considers", "Tries", "Decides", "Uses", "Renews", etc.) - Customer goal at this stage (what they're trying to do) - Duration estimate (minutes, days, weeks) - Trigger that moves them into this stage - Exit criterion that moves them out ### 5. Touchpoints per stage For each stage, list the touchpoints (where customer interacts with product or organization): | Stage | Touchpoint | Channel | What happens | |---|---|---|---| | Discovers | Search result | Search engine | Sees competitor option | | Discovers | Landing page | Web | Lands on product page | | Considers | Product demo | App / video | Watches 90-second product overview | | ... | | | | ### 6. Emotional curve For each stage, what the customer feels. Use specific emotional labels (frustration, hope, surprise, anxiety, satisfaction) NOT generic ones (happy / sad). Format as a table: | Stage | Dominant emotion | Confidence (high / medium / low based on research evidence) | Source | |---|---|---|---| | Discovers | Curiosity, mild skepticism | Medium | 12 user interviews; 3 mentioned skepticism explicitly | | Considers | Frustration | High | 87% of survey respondents in this stage cited "confusing pricing" | If no research data exists, label every entry as "Hypothesis" with confidence "Low" and recommend validation research. ### 7. Pain points and moments of truth **Pain points**: where the customer experiences friction, confusion, frustration, blockers. Per stage. **Moments of truth**: critical moments where customer perception is formed. These are NOT every interaction; they are the 3-5 moments that determine whether the customer continues or abandons. Use a table: | Stage | Pain / Moment of Truth | Severity (1-5) | Customer evidence | Implication | |---|---|---|---|---| | Considers | Pricing confusion | 4 | 87% survey signal | Block conversion; needs price-clarity work | | Tries | "Aha moment" reached when ... | Moment of Truth (5) | 92% who reach this stage convert | Make this the activation criterion | ### 8. Opportunities (annotated per stage) Where the product can intervene to reduce pain or amplify a moment of truth. Per stage, 1-3 opportunities. Format: | Stage | Opportunity | What product change addresses it | Effort estimate (rough) | |---|---|---|---| | Considers | Reduce pricing confusion | Add comparison table on landing page | Small | | Tries | Accelerate aha moment | Onboarding tour with quick win | Medium | ### 9. Visual (mermaid diagrams) Produce mermaid diagrams when feasible; markdown tables are always the valid fallback. **Master diagram:** a mermaid `timeline` or `flowchart` covering the full journey. Use timeline for linear journeys
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.