Seeing the Problem: Facilitator’s Guide

"Fast response"          → How fast? 200ms? 2 seconds?
"Easy to use"            → For whom? In what situation?
"Secure"                 → From what threats? To what level?
"Better"                 → By what measure?

"Enhanced notifications"
  BizDev imagined:          Popup on client team lead's PC
  Backend developer:        Email / Slack webhook
  Frontend developer:       In-app badge, red dot
  User (team member):       Can't we just get a text?

"It should work just like it does now"  → Do you know how it works now?
"Obviously that wouldn't be done"       → What's obvious?
"While keeping the existing approach"   → What is the existing approach?
"Build it quickly"                      → How quickly? What can be sacrificed?

           Functions
           (what it does)
               △
              / \
             /   \
            /     \
           /       \
Attributes ─────── Constraints
(how it must do it)  (what cannot be touched)

Comparison Points
──────────────────
"Is there a case where different things were written in the same column?"
  → That difference is itself an example of between-interpreter ambiguity.

"Did anyone classify an Attribute as a Function?"
  → Invite discussion about why they classified it that way.

"Is the Constraints column the most empty?"
  → It usually is. Constraints are the hardest to surface.
     Ask "why didn't this one come to mind?" as a meta-question.

"How are you currently handling this problem?"
"Who is doing this task? How many people?"
"When does this problem feel most acute?"
"What happens if this isn't resolved?"
"Is there a workaround you're using right now?"

"What must this system absolutely do?"
"What must it never do?"
"What state would let you say 'this worked'?"
"What single missing thing would be most valuable?"
"Who judges whether this was successful?"

"Would you be okay with me asking you questions like this?"
"Is there anything I might be missing?"
"Can I check that I've understood correctly?"
"Could you connect me with someone who knows more about this?"
"Are any of my questions heading in the wrong direction?"

┌─────────────────────────────────────────────┐
│                                             │
│  Trigger ──→ [   Black Box   ] ──→ Output   │
│                                             │
│                  ↕ Edge conditions          │
│                                             │
└─────────────────────────────────────────────┘

Comparison Points
──────────────────
"Same interview subject — how different are the Black Boxes?"
  → The direction of the questions was different.
    Trace backwards: which question led to which discovery?

"Which team found the most edge cases — what questions did they ask?"
  → Teams that asked "what should it never do?" and
    "under what conditions does this fail?" find more edge cases.

"What happened in teams that used a Meta-Question?"
  → 'Is there anything I might have missed?' pulls out the most new information.
    Bring this experience into the full group share.

┌─────────────────────────────────────────────────────────────┐


==== Debrief Guide

=== 5. Debrief (10 minutes)

_Facilitator guide — anticipated resistance and responses_

'''



'''

== Before Drawing the Map — Problem Structure and Domain Model

=== Time Allocation

[cols="1,1,1", options="header"]
|===
| Order | Content | Time
|  | 0. Connection from previous session | 5 min
|  | 1. Opening provocation — The headache analogy | 10 min
|  | 2. Concept explanation (3 layers, Problem Framing, Domain Model) | 20 min
|  | 3. Fixed case exercise — Worksheet A-4 | 30 min
|  | 4. Real-work case slot — Worksheet B-4 | 20 min
|  | 5. Debrief | 10 min
|  | 6. Distribute Assignment Card #4 | 5 min
|  | *Total* | *100 min*
|===

=== Session Facilitation Notes

- ★ Don't give the answer in the layer classification exercise. The goal is the team agreeing on "which layer we're trying to fix."
- ★ In the Domain Model sketch, State design varies the most. If different groups drew 'Assigned' and 'Acknowledged' differently, bring it into the full comparison.
- ★ 'Do we always have to fix the root cause?' is an important question. Emphasize that it's a "conscious choice." It foreshadows Session 5's Spike and Session 7's Risk.
- ★ Repeatedly point out that the Domain Model is a "team vocabulary alignment process," not a "document."

=== Session Walkthrough

=== 0. Connection from Previous Session (5 minutes)

'''

=== 1. Opening Provocation (10 minutes)

_"The Headache Analogy"_

Write briefly on slide or by speaking.

[quote]
____
_Someone complains of a headache every morning._
____
[quote]
____
_They go to a doctor who prescribes painkillers._
____
[quote]
____
_The painkiller relieves the headache._
____
[quote]
____
_But the next morning, the headache comes back._
____

[quote]
____
_The headache is a symptom._
____
[quote]
____
_The real cause turned out to be — chronic sleep deprivation and too much caffeine._
____

[quote]
____
_The painkiller fixed the symptom, but not the problem._
____

After a moment, ask:

[quote]
____
"Has anything like this happened to you in software development?
____
[quote]
____
 A time when you built what was asked, and a similar request came in again later."
____

Ask participants to raise their hands. Most will.

[quote]
____
"That's because you fixed the symptom.
____
[quote]
____
This session covers — how to distinguish symptoms from problems from root causes,
____
[quote]
____
and how to know when you've understood a problem well enough."
____

'''

=== 2. Concept Explanation (20 minutes)

==== Concept 1 — The Three Layers of a Problem (10 minutes)

Every problem situation has three layers.

Why does the distinction matter?

But this doesn't mean you always have to dig to the root cause. _Which layer to address is a conscious choice_. It's okay to decide to fix the symptom layer for a demo next month — as long as you know that is the decision you're making.

'''

_Problem Framing — How you frame it changes the solution_

How you frame the same phenomenon changes the shape of the Problem Space.

Which frame is "right" is not currently known. But _the most dangerous thing is having only one frame_. Recognizing that multiple frames are possible is the first practice.

'''

==== Concept 2 — Domain Model vs Design Model (Fairbanks) (10 minutes)

Fairbanks distinguishes three models surrounding software.

_Domain Model — Real-world concepts_

The _real-world people, actions, rules, and states_ that this system deals with.

Domain Model elements in the TeamOrder case:

_Design Model — The structure of the software being built_

ERD, API design, system diagrams. From here, you're in the Solution Space.

The mistake most engineers make:

What happens when the Domain Model is skipped?

The design diverges from the real-world concepts. During development, "how do we handle this case?" questions keep repeating. Most of those questions belong in the Domain Model layer.

_The time to move to the Design Model is when the Domain Model has sufficiently stabilized._

How do you know? When the team is speaking the same domain vocabulary. When "task" and "to-do" aren't used interchangeably. When "Assigned" and "Acknowledged" are distinct.

'''

=== 3. Fixed Case Exercise (30 minutes)


==== Small Group Share Guide

_Small Group Share (7 minutes)_

Pin or draw each group's Domain Model side by side on the board.

Facilitator guide:

'''

=== 4. Real-Work Case Slot (20 minutes)

==== Worksheet B-4 | My Real-Work Case: Layer Analysis + Domain Model

┌─────────────────────────────────────────────────────────┐
│  Resolvable Ambiguity                                   │
│                                                         │
│  • Someone knows the answer                             │
│  • Asking or researching will produce an answer         │
│  • The tools from Sessions 1–4 apply                   │
│                                                         │
│  Examples: "What is the response time requirement       │
│             for notifications?"                         │
│            "Is there a night shift?"                    │
│            "What is the budget ceiling?"                │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│  Essential Ambiguity                                    │
│                                                         │
│  • Nobody knows yet                                     │
│  • Asking yields no answer — reality hasn't             │
│    been decided yet                                     │
│  • You can only know by doing, by building,             │
│    by putting it in front of users                      │
│                                                         │
│  Examples: "Will users actually use this feature?"      │
│            "Will this approach fit our team's           │
│             workflow?"                                  │
│            "What notification format works in           │
│             this environment?"                          │
└─────────────────────────────────────────────────────────┘

Purpose:  Does this technology meet this requirement?
          Does this approach work in this environment?

Method:   As simple, fast, and disposable as possible
          Production quality not required

Outcome:  Yes/No or new questions
          Learning is the output, not the code

Facing this ambiguity — what will I do?

Question 1: Is there an action I can take to learn this?
             If yes → Resolvable → Weinberg strategy (questions, interviews)

Question 2: Still uncertain even after acting?
             → Essential → Cunningham strategy (Spike, minimum action)

Question 3: Is this decision actually needed right now?
             If not → Deferring the decision is the strategy
             (Fairbanks's "Just Enough" spirit)

Comparison Points
────────────────
"Did any teams classify the same ambiguity as R while another classified it as E?"
  → Why they saw it differently is the key.
    Is there anything classified as E where action is actually possible?
    Conversely, is there anything classified as R that nobody actually knows?

"What was most difficult when designing the Spike?"
  → Setting the standard for "the simplest."
    Guide participants to repeatedly ask
    "Can this be done even more simply?"

"Did anyone use the 'doesn't need to be decided now' column?"
  → This judgment itself is an important capability.
    Breaking free from the compulsion to resolve all ambiguity immediately.

Step 1: Extract the structure
  What is the core structure of this problem?
  (Abstract the actors, actions, relationships, constraints)

Step 2: Search for analogous problems
  Is there a problem in another domain that resembles this structure?

Step 3: Import the principle
  Apply the solution principle of the analogous problem to this problem
  (the principle, not the solution itself)

Step 1 — Extract the structure:
  "Delivering messages to multiple recipients,
   where recipients' states (online/offline/sleep) are uncertain,
   and message urgency varies"

Step 2 — Search for analogous problems:
  • Hospital ER triage — sequencing by patient urgency
  • Air traffic control — priority communication among multiple aircraft
  • Email spam filter — sorting by importance
  • TCP retransmission — retry mechanism when packet not acknowledged
  • Twitter notification batching — critical notifications immediately,
    rest bundled

Step 3 — Import the principle:
  TCP retransmission principle:
    "Retransmit if no delivery confirmation received"
    → Re-notify if team member notification acknowledgement is absent
  Triage principle:
    "Use different channels based on urgency"
    → Night-shift urgents via separate channel (SMS/call),
      regular via app push

"What kind of problem is this, fundamentally?"

Business research question frame:

"What did this service prioritize above all else?"
"What did it sacrifice?"
"Why did they choose this approach?"
"What type of user/environment is it optimized for?"
"In what situations does this design fail?"

Comparison Points
────────────────
"Did different teams find analogies from entirely different domains?"
  → The same problem can generate analogies from completely different domains.
    If one team found hospital triage and another found TCP retransmission,
    both are correct. And the principles extracted from each will differ.
    List those differences on the board.

"Where did things get stuck when importing the principle?"
  → Check: "Were they trying to copy the solution or import the principle?"
    The former usually ends with "it doesn't fit our situation."

"How did reading Trade-offs in business research
 differ from a simple feature comparison?"
  → Surface this question to help participants articulate
    the difference in research perspective.

Functionality
─────────────
"What the system does"
Examples: Sends a notification, assigns a task, shows a list

→ Can be accumulated sprint by sprint
→ Relatively easy to add later


Quality Attributes (the "-ilities")
────────────────────────────────────
"How well the system does it"
Examples: Performance, Availability, Security,
          Scalability, Modifiability

→ Secured through architectural decisions
→ Very expensive to change later
→ Unlike functionality, they trade off against each other

Cost of adding functionality later:          Linear
Cost of adding a Quality Attribute later:    Exponential

Risk-Driven Model — 3-step loop

┌─────────────────────────────────────────────────┐
│                                                 │
│  1. Identify failure risks                      │
│     "If this fails, does the project die?"      │
│                                                 │
│           ↓                                     │
│                                                 │
│  2. Choose techniques matched to the risk       │
│     Engineering risk → only Engineering         │
│     techniques are effective                    │
│                                                 │
│           ↓                                     │
│                                                 │
│  3. Stop when risk is sufficiently reduced      │
│     "Just Enough" — design is a means,         │
│     not an end in itself                        │
│                                                 │
└─────────────────────────────────────────────────┘

Engineering Risk                   Project Management Risk
─────────────────────────────────  ───────────────────────────────────
Problems of system analysis/       Problems of schedule, team size,
design/implementation              and priorities

"Performance won't meet           "We probably can't finish in 3 weeks"
 requirements"
"Can't guarantee data             "The team doesn't know this
 consistency"                      technology"
"There's a security               "Requirements keep changing"
 vulnerability"

→ Resolved with Engineering        → Resolved with PM techniques
  techniques                         (schedule adjustment, training,
  (prototype, load testing,           process improvement, etc.)
   threat modeling, etc.)

If any of the following are "YES," treat as an Engineering Risk

□ Does this system have demanding response time requirements?
□ Is data consistency critical to this system?
□ Does it handle security-sensitive data?
□ Is there a possibility of sudden traffic growth?
□ Do multiple teams touch the same component?
□ Does a failure in one component cascade to full system failure?
□ Are significant feature additions/changes expected later?
□ Is integration with external systems/services complex?

Low-risk areas:
  Elaborate design is actually wasteful
  → Cunningham: Simplest Thing
  → Fairbanks: Stop designing

High-risk areas:
  Insufficient design is the cause of failure
  → Fairbanks: Choose techniques matched to risk
  → Cunningham: Explore quickly with Spike

Comparison Points
────────────────
"Do teams have different top 3 risks?"
  → Same system, different risk priorities —
    what contextual difference drove that judgment?
    It may be the difference between demo perspective
    vs live service perspective.

"Are there cases where PM Risk and Engineering Risk were confused?"
  → Most commonly mixed:
    "I don't think we can build this in a month" → PM Risk
    "I don't think we can guarantee night-shift notification delivery" → Engineering Risk
    Point out that the techniques for addressing these two are completely different.

"Was the PART 4 decision — 'doesn't need to be done now' — difficult to make?"
  → If difficult — why?
    How do they reconcile with the pressure to "design everything perfectly"?
    This is the core shift in perception this session aims for.

Problem-Solution Fit check:

┌──────────────────────────────────────────────────┐
│ Problem definition (Problem Space exploration     │
│ results)                                         │
│                                                  │
│  - Who is suffering?                             │
│  - In what situation?                            │
│  - What workaround are they using now?           │
│  - What cost occurs if this isn't resolved?      │
│                                                  │
│           ↕  Does this correspond?               │
│                                                  │
│ Solution (Solution Space exploration results)    │
│                                                  │
│  - Whose pain does this feature alleviate?       │
│  - In what situation does it work?               │
│  - Does it replace the workaround?               │
│  - What remains unresolved?                      │
└──────────────────────────────────────────────────┘

Problem: "Team members miss tasks and the line stops"
Solution: "Nice notification UI + read receipts + notification history page"

→ Do read receipts and a history page prevent line stoppages?
  The core of the problem (guaranteed delivery) is missing.

Normal review                   Pre-mortem
───────────────────────────     ───────────────────────────────
Success bias develops            Imagining failure reduces bias
"It'll work out"                  "If it failed, why?"
Hard to find weaknesses          Weaknesses surface naturally
Psychologically hard to          Hypothetical failure creates
criticize in team setting        psychological safety

1. "Assume this solution was actually deployed."
2. "Six months have passed."
3. "It failed. For what reasons?"
4. Each person writes 3+ reasons individually (2 minutes)
5. Small group share → extract top 3 most-cited failure reasons
6. Can those reasons be addressed preemptively?

"Reasons TeamOrder's notification feature failed after 6 months"

• Night-shift urgent SMS costs ran higher than expected — feature was turned off
• Team members were receiving too many notifications and started turning them off
• Background notification policy changed after an iOS update
• Team leads didn't know what to do with team members who hadn't confirmed,
  so they stopped using it
• The factory's firewall was blocking FCM (discovered later)

Core comparison points for this session
────────────────────────────────────────
"Did anyone check 'things I no longer need to build appeared' in PART 3?"
  → This is the core conclusion of this session, and the entire workshop.
    Ask them:
    "What disappeared? How did you come to know it was okay for it to disappear?"

"Did the solution become simpler?"
  → For teams where it did: which session produced that simplification?
    (Session 2 FAC? Session 4 layer choice? Session 5 Spike? Session 7 Risk?)

"Among the Pre-mortem failure reasons,
 are there any that could have been caught with Session 2–4 tools?"
  → When this connection is visible, the entire workshop's learning
    has been integrated.