Problem Mapping

Problem Mapping

Problem Mapping helps teams understand and frame design challenges before jumping to solutions. Based on the "Understand" phase from Google Design Sprint methodology, this skill structures messy problem spaces into clear goals, assumptions, and pain points.

What This Skill Does

• Facilitates structured problem exploration through guided questioning
• Captures goals, users, constraints, and assumptions systematically
• Documents pain points and challenges
• Creates shared understanding document as sprint foundation
• Does NOT generate solutions or make decisions (that comes later)
• Does NOT interpret findings (humans decide significance)

Workflow Decision Tree

Start here: "I'd like to start a problem mapping session"

Claude will ask: "How are you running this session?"

1. Solo → Individual exploration with Claude
2. Team Sync → Team together, Claude facilitates discussion
3. Team Async → Team provides input separately, Claude synthesizes

Each mode follows the same 6-step questioning framework but adapts the interaction style.

Solo Mode

Use when working through problems independently - initial exploration, personal projects, or prep work.

How It Works

1. Claude asks structured questions about the problem
2. Think out loud and answer thoughtfully (don't rush)
3. Claude structures responses into problem map
4. Review and refine together

Question Framework

1. Problem Statement - What are we trying to solve?
2. Users/Stakeholders - Who's involved? Who's affected?
3. Goals - What does success look like?
4. Constraints - What's limiting us? (time, resources, technology)
5. Assumptions - What are we taking for granted?
6. Pain Points - What are the key challenges or frustrations?

Your Role

• Think out loud, don't self-censor
• Challenge own assumptions
• Ask Claude to dig deeper if stuck
• Don't rush - this is thinking time

Team Sync Mode

Use when team is together (in-person or video call) - kickoff meetings, workshops, retreat sessions.

Preparation

• Share problem context with team beforehand
• Reserve 45-60 minutes uninterrupted
• One person operates Claude (facilitator)
• Everyone else focuses on discussion

How It Works

1. Facilitator reads Claude's prompts to team verbatim
2. Team discusses each question together
3. Facilitator relays key points to Claude
4. Claude documents in real-time and keeps session on track

Roles

Facilitator (you):

• Read Claude's prompts verbatim (phrasing is intentional)
• Give space for discussion, don't rush
• Capture and relay team responses
• Trust Claude to redirect if discussion drifts

Claude:

• Provides structured prompts with facilitation tips
• Captures team responses
• Identifies when discussion goes off-track
• Reminds facilitator of next steps

Team:

• Discuss openly and challenge assumptions
• Build on each other's ideas
• Stay focused on current question

Timing

• Problem Statement (10 min)
• Users/Stakeholders (5 min)
• Goals (10 min)
• Constraints (5 min)
• Assumptions (10 min)
• Pain Points (10 min)

Total: ~50 minutes

Team Async Mode

Use when team is distributed, busy schedules, or when gathering diverse perspectives independently matters.

Process

Phase 1: Generate Questions (5 min)

• Brief Claude on problem
• Claude creates question set
• Review and adjust if needed

Phase 2: Distribute (You handle)

• Send questions to team via preferred channel (Slack/email/doc)
• Give clear deadline (24-48 hours typical)
• Encourage honest, individual responses (2-3 sentences per question)
• Team doesn't see each other's answers yet

Phase 3: Compile (10 min)

• Copy/paste all team responses to Claude
• Include who said what (names or roles)
• Perfect formatting not required

Phase 4: Synthesis (Claude does this)

• Structures all responses
• Identifies common themes
• Highlights divergent perspectives
• Reveals patterns in thinking
• Does NOT interpret what patterns mean

Phase 5: Review (Team)

• Share Claude's synthesis with team
• Team discusses what they see
• Humans interpret significance together

Format Flexibility

Claude asks what format works for your team:

• Markdown document
• Google Doc template
• Slack message format
• Email format
• Other

Output Document

All modes produce a structured problem map:

markdownCopy code
# Problem Map: [Project Name]

**Date:** [Date]
**Participants:** [Names/Roles]
**Mode:** [Solo/Team Sync/Team Async]

---

## Problem Statement
[Clear, concise description of challenge]

---

## Users & Stakeholders
**Primary Users:**
- [User type]: [Main needs/goals]

**Stakeholders:**
- [Stakeholder]: [Interest/influence]

---

## Success Criteria
What "good" looks like:
1. [Measurable outcome]
2. [Measurable outcome]
3. [Measurable outcome]

---

## Constraints
**Time:** [Limitations]
**Resources:** [Budget, team, tools]
**Technical:** [Platform, integration, legacy]
**Business:** [Policy, compliance, market]

---

## Assumptions
Things we're taking for granted (need validation):
- [Assumption about users]
- [Assumption about solution]
- [Assumption about context]
- [Assumption about feasibility]

---

## Pain Points & Challenges
Key problems and frustrations:
- [User pain point]
- [Business challenge]
- [Technical obstacle]
- [Process friction]

---

## Open Questions
What we need to learn or validate:
- [Research question]
- [Validation needed]
- [Knowledge gap]

---

## Next Steps
[If team decided on immediate actions]

Team Async Addendum

Async mode adds individual perspectives section:

markdownCopy code
---

## Individual Perspectives

**On [Topic]:**
- [Person A]: [Their view]
- [Person B]: [Their view]
- [Person C]: [Their view]

**Patterns Observed:**
- [Common theme]
- [Area of alignment]
- [Area of divergent thinking]

**Note:** Shows what team said, not what it means. 
Team discusses significance together.

Common Pitfalls

Claude catches these automatically:

❌ Jumping to solutions - "We should build X" ✅ Staying in problem space - "Users struggle with Y because Z"

❌ Vague goals - "Make it better"
✅ Specific criteria - "Reduce task time from 5 min to 2 min"

❌ Hidden assumptions - Treating beliefs as facts ✅ Named assumptions - "We assume users have smartphones (needs validation)"

❌ Problem statements that are actually solutions - "We need a mobile app" ✅ Clear problem statements - "Users can't access information when away from desktop"

Best Practices

All Modes

• Don't rush - this is thinking time, not execution
• Challenge assumptions actively
• Stay focused - one question at a time, resist solution talk
• Verify accuracy of documentation

Solo Mode

• Think out loud - more material = better structure
• Use "I don't know" - Claude helps figure it out
• Revisit earlier answers when new insights emerge

Team Sync Mode

• Read prompts verbatim - Claude's phrasing is intentional
• Embrace silence - let team think before answering
• Capture spirit, not transcript - main points matter
• Watch for energy - if stuck, tell Claude and ask for help

Team Async Mode

• Give clear deadline - respects team's time
• Encourage brevity - 2-3 sentences sufficient
• Don't prime responses - let team think independently
• Share synthesis before discussing - let it sit if possible

What Happens Next

After Problem Mapping:

1. Lightning Talks - Experts share knowledge about users, business, tech (use hmw-affinity skill during talks)
2. Prioritize - Which problems are most important?
3. Research - Which assumptions need validation first?
4. Ideate - Generate solutions (use crazy-8s skill)

Problem Mapping creates the foundation. Everything else builds on this shared understanding.

Note: In Google Design Sprints, Problem Mapping is part of the "Understand" phase. After this foundational work, teams conduct Lightning Talks where experts present insights. During talks, team members capture "How Might We" (HMW) opportunities - that's a separate skill (hmw-affinity).