Audience: Fullstack engineers with 3–4 years of experience | Structure: 8 sessions × 100 minutes

How This Workbook Is Organized

This workbook is the participant material for the workshop. It is a space to write, fill in, and record during each session.

Worksheet A  Fixed case exercise forms provided for each session
             The TeamOrder case is explored session by session using different tools

Worksheet B  A form for carrying a single real-work case across all 8 sessions
             Each session applies the new tool to your own real-work problem
             At the end of Session 8, you will have one completed analysis

Assignment   A short practical task to complete at work after each session
Card

TeamOrder Case Introduction

This is the fixed case that runs through the entire workshop.

Company:  Enterprise SaaS startup, just post-Series A
Team:     4 fullstack engineers, 1 BizDev

Minjun (BizDev, 31)               Brings in client deals
Jiyeon (Fullstack, 28, 3 yrs)     Confident building things fast
Seunghyun (Fullstack, 32, 5 yrs)  Team senior / point-of-view character
Hyuntae (Fullstack, 26, 1 yr)     Most junior. Asks what everyone else takes for granted

─────────────────────────────────────────────────────────────────────────
Starting requirement for Session 1:

  Minjun: "Can you beef up the team collaboration features?
           Notifications and task assignment. We need a demo next month."
─────────────────────────────────────────────────────────────────────────

Contents

Session Title Core Concepts

1

Solution Addiction — The Habit of Skipping the Problem Space

Problem Space vs Solution Space · Einstellung Effect · Presumptive Architecture

2

The Anatomy of Ambiguity — A Language for Decomposing Requirements

Functions / Attributes / Constraints (FAC) · Three Sources of Ambiguity

3

Whoever Asks Designs — Context-Free Questions

Context-Free Questions · Black Box Test · Jobs-to-be-Done

4

Before Drawing the Map — Problem Structure and Domain Model

Symptom-Problem-Root Cause layers · Problem Framing · Domain Model

5

Walking Through the Fog — Living with Ambiguity

Resolvable vs Essential Ambiguity · Spike Solution · Technical Debt

6

I’ve Seen This Problem Before — Analogical Reasoning

Analogical Reasoning · Problem-Type Reduction · Trade-off Research

7

Where to Focus Your Energy — Risk-Driven Design

Quality Attributes · Engineering Risk · Risk-Driven Model

8

Seunghyun’s Map — Validating and Integrating the Solution

Problem-Solution Fit · Pre-mortem · Integration Retrospective

1. Solution Addiction — The Habit of Skipping the Problem Space

Core Question: Am I understanding the problem, or recognizing a pattern?

Core Concepts: Problem Space vs Solution Space · Einstellung Effect · Presumptive Architecture

1.1. 3. Fixed Case Exercise

1.1.1. Worksheet A-1 | TeamOrder Case: Drawing the Map in My Head

Worksheet A-1 | Session 1 / TeamOrder Case

Name: ________________________
Date: ________________________

Can you beef up the team collaboration features? Notifications and task assignment. Demo next month.

— Minjun

PART 1. What’s in my head right now (3 minutes, no filtering)

Write down everything that comes to mind the moment you hear this requirement.
(Technology, structure, time estimates — anything)

________________________
________________________
________________________
________________________

PART 2. Classification (5 minutes)

Sort what you wrote above into two columns.

Problem Space (related to understanding the problem) Solution Space (related to solving it)

 
 
 
 
 
 

 
 
 
 
 
 

PART 3. My Presumptive Architecture (5 minutes)

"I assumed this is a ________________ kind of system."

What is the basis for that assumption?

  • I’ve built something similar before

  • This is how the team usually handles these cases

  • I know this technology well

  • It just came to mind naturally

  • Other: _______________

If this assumption were wrong, what would change?

________________________
________________________
________________________

PART 4. Remaining questions in the Problem Space (10 minutes)

Write down as many things as possible that you still don’t know — things you’d need to ask about.
(No good or bad questions. Volume is the goal.)

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
...

Total count: ______

1.2. 4. Real-Work Case Slot

1.2.1. Worksheet B-1 | Register Your Real-Work Case

Worksheet B | My Real-Work Case (used across all 8 sessions)

Name: ________________________

Pick one requirement or request you received in the last three months —
something that still feels unclear,
or where you finished and thought "that wasn’t what they wanted."

Case title (one line):
________________________

Original requirement (as close to verbatim as possible):
________________________
________________________
________________________

Applying Session 1:

What Solution Space items came to mind when you first heard it:
________________________

What was your Presumptive Architecture at the time?
________________________

Looking back now, questions you should have asked:

1.
2.
3.

1.3. 6. Assignment

Assignment Card #1

Assignment Card #1

From a requirement or work assignment you receive this week, choose one:

  1. Write down the Solution Space items that came
    to mind the moment you heard it.

  2. From that requirement, write a list of
    things you still don’t know. (At least 5)

  3. Either add that case to Worksheet B, or
    continue with the case you already registered.

Preview of next session:
The anatomy of requirements — Functions, Attributes, Constraints

(Continue to next session)

2. The Anatomy of Ambiguity — A Language for Decomposing Requirements

Core Question: What does it mean for a requirement to be "clear"?

Core Concepts: Functions / Attributes / Constraints (FAC) · Three Sources of Ambiguity

2.1. Worksheet A-2 | TeamOrder Case: Dissecting Ambiguity

Worksheet A-2 | Session 2 / TeamOrder Case

Name: ________________________
Date: ________________________

Can you beef up the team collaboration features? Notifications and task assignment. Demo next month.

— Minjun

When the team lead assigns a task, the team members never find out. They have to send a separate Slack message, and it’s such a hassle.

— Minjun

PART 1. Finding the Sources of Ambiguity (7 minutes)

Find all the ambiguous parts in the two statements above and mark them.
Then classify what type of ambiguity each one is.

Ambiguous expression Type (linguistic / between interpreters / missing context)

1.

 

2.

 

3.

 

4.

 

5.

 

6.

 

PART 2. FAC Breakdown (10 minutes)

Separate what can be read from Minjun’s words
from what is still undetermined (?).

Stated (Confirmed) ? (Still Unknown)

Functions (what it does)

 
 
 

 
 
 

Attributes (how it does it)

 
 
 

 
 
 

Constraints (conditions/limits)

 
 
 

 
 
 

Are the "?" columns larger than the "confirmed" columns?

  • Yes (Normal. More exploration is needed)

  • No (You may have filled it in too quickly — review again)

PART 3. What’s the most dangerous gap? (5 minutes)

From the "?" items, choose the one where starting development
without knowing it carries the highest risk of rework or failure.

Most dangerous gap:
________________________

Why:
________________________
________________________

Who needs to be asked, and what question, to resolve this?
________________________
________________________

Small Group Share (8 minutes)

Groups of 3–4 compare PART 2 results.

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.

Full Group Share (7 minutes)

Collect each group’s "most dangerous gap" onto the board. If different groups chose different things — why is the core of the discussion.

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

2.2.1. Worksheet B-2 | My Real-Work Case: FAC Breakdown

Worksheet B-2 | Session 2 / My Real-Work Case (continued from Session 1)

Name: ________________________

Real-work case from Session 1:
(Write the title again)

________________________

Break down the original requirement using FAC.

Stated (Confirmed) ? (Still Unknown)

Functions

 
 

 
 

Attributes

 
 

 
 

Constraints

 
 

 
 

Looking back:

Which FAC item did I miss when I first received this case?
________________________

What actually happened (or almost happened) when we proceeded without knowing it?
________________________
________________________

If I had had this tool at the time, what would I have asked first?
________________________
________________________

2.3. 6. Assignment (5 minutes)

Assignment Card #2

Assignment Card #2

Take one requirement you received this week
and break it down using a FAC table.

Pay particular attention to:

  1. Attributes column — Is a quality standard ("how it should be done")
    stated explicitly?
    If not, what question could surface one?

  2. Constraints column — Has "what cannot be touched"
    been stated?
    Does anything feel like an unstated assumption?

  3. Add the result to Worksheet B.
    You’ll continue using it next session.

Preview of next session:
Questions for filling FAC — how should you ask?

(Continue to next session)

3. Whoever Asks Designs — Context-Free Questions

Core Question: What BizDev wants and what users need are different — how do you surface them?

Core Concepts: Context-Free Questions · Black Box Test · Jobs-to-be-Done

3.1. Worksheet A-3 | TeamOrder Case: Interview + Black Box

Exercise Setup

Pairs of two. Assign roles.

  • Interviewer (as Seunghyun): Interview Minjun using Context-Free Questions

  • BizDev (as Minjun): Receive the Minjun card below and answer only from that information

Minjun Role Card (do not show to the interviewer)

You just came back from a conversation with Client A (a mid-sized manufacturer). What you know:

  • 3 team leads at the client each assign tasks to 5–10 team members

  • Currently: assign in the system, then send a separate Slack message

  • Team members miss tasks 1–2 times per week

  • Team leads frequently go out to the factory floor → use mobile

  • The demo will be shown to team leads (team members come later)

What you don’t know (answer "I’m not sure" if asked):

  • Notification response time requirements

  • Technical specs of the existing system

  • Budget

  • Team members' device environment
Worksheet A-3 | Session 3 / TeamOrder Case

Name (Interviewer): ________________________
Name (BizDev): ________________________

PART 1. Interview (15 minutes)

Use Context-Free Questions to interview Minjun.
Create at least 2 questions from each of the three categories below and actually use them.

[ Process Questions — how is it happening? ]

Question What you discovered

Q:  
A:  

 

Q:  
A:  

 

Q:  
A:  

 

[ Product Questions — what should it be? ]

Question What you discovered

Q:  
A:  

 

Q:  
A:  

 

Q:  
A:  

 

[ Meta-Questions — questions about the questioning ]
(Try at least 1)

Question What you discovered

Q:  
A:  

 

PART 2. Black Box (10 minutes)

Fill in based on what you discovered in the interview.
Mark anything still unknown as [?].

Feature name

________________________

Trigger (when does it start?)

________________________

Input (what goes in, who provides it?)

________________________

Output (what comes out, to whom?)

________________________

Edge cases (conditions where it doesn’t work)

  1. ________________________

  2. ________________________

  3. ________________________

PART 3. Update FAC after interview (5 minutes)

Compare with your Session 2 worksheet.

Newly filled in from the interview Still marked [?]

 

 

 

 

 

 

Most unexpected discovery from this interview:
________________________

Was there a question where you got stuck? What type was it?
________________________

Small Group Share (5 minutes)

Groups that used the same role card compare their Black Boxes.

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 this absolutely 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.

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

3.2.1. Worksheet B-3 | My Real-Work Case: Applying Context-Free Questions

Worksheet B-3 | Session 3 / My Real-Work Case (continued from Session 2)

Name: ________________________

Most important [?] item in my real-work case FAC:
(from Session 2 worksheet)

________________________

Create Context-Free Questions to fill in this [?].

Process Questions (how is it currently happening?):

  1. Q1. ________________________

  2. Q2. ________________________

Product Questions (what should it be?):

  1. Q1. ________________________

  2. Q2. ________________________

Meta-Question (what might I be missing?):

  1. Q1. ________________________

Who could actually be asked these questions?

Target When/How will you ask?

 

 

Draw the Black Box for your case.
(Based on information currently available. Use [?] freely)

Feature name

________________________

Trigger

________________________

Input

________________________

Output

________________________

Edge cases

  1. ________________________

  2. ________________________

3.3. 6. Assignment (5 minutes)

Assignment Card #3

Assignment Card #3

This week, have a short conversation with a BizDev, product manager, or teammate.

Conversation target:
Someone who could resolve one of the [?] items in your real-work case (see Worksheet B-3)

What to try:

  1. Use one of the Context-Free Questions naturally in the conversation

  2. After the conversation, record what you discovered in Worksheet B — especially any unexpected answers

  3. If possible, update the Black Box

Preview of next session:
Understanding problem structure — symptoms, problems, root causes, and Domain Model

(Continue to next session)

4. Before Drawing the Map — Problem Structure and Domain Model

Core Question: How do you know when you’ve understood a problem well enough?

Core Concepts: Symptom-Problem-Root Cause layers · Problem Framing · Domain Model

4.1. Worksheet A-4 | TeamOrder Case: Layer Analysis + Domain Model

Worksheet A-4 | Session 4 / TeamOrder Case

Name: ________________________
Date: ________________________

What we know so far (summary from Sessions 1–3):

  • Team lead assigns task in system, then separately messages on Slack

  • Team members use tablets/phones on the factory floor

  • Missing a task causes a line stoppage

  • Night shift urgent assignment cases exist

  • Demo scheduled for team leads next month

PART 1. Layer Classification (8 minutes)

Classify the phenomena below as symptom / problem / root cause.
(There may not be one right answer — discuss with your team)

Phenomenon Layer Reason

Team members miss tasks

 

 

Team lead sends a separate Slack message after assignment

 

 

Line stoppages occur

 

 

Team members don’t check Slack much on the floor

 

 

The assignment workflow happens outside the system

 

 

Which layer should we address, given the demo purpose and one-month timeline?

Selected layer

________________________

Reason

________________________

PART 2. Problem Framing (7 minutes)

Write at least 2 ways the phenomenon "team members miss tasks" could be viewed through a different frame.

Frame 1

________________________

Solution that comes from this frame

________________________

Frame 2

________________________

Solution that comes from this frame

________________________

Frame 3 (if any)

________________________

Solution that comes from this frame

________________________

Which frame did the team choose? Why?
________________________

PART 3. Domain Model Sketch (15 minutes)

Sketch the Domain Model for the TeamOrder case.
Fill in the categories below, or draw freely in the box.

Actors (who is involved?)

________________________

Actions (what actions take place?)

________________________

States (what states can a task be in?)

________________________

Rules (what rules must be respected?)

________________________

Objects (key concepts/items the system handles)

________________________

Check: Is the whole team using the same vocabulary?

Were there concepts that were confusing or named differently by different people?
________________________

What definition did you agree to use?
________________________

Small Group Share (7 minutes)

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

Comparison Points

"How differently was State drawn across groups?"
→ State design varies the most.
Teams that treated 'Assigned' and 'Acknowledged' as the same vs different —
this difference will completely change DB design and API design later.

"How many Rules were found?"
→ Did any teams include the night shift urgent rule?
Teams that didn’t — reflect on why it was left out.

"How different is the Domain Model from your current design (if any)?"
→ Large gaps are future rework points.

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

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

Worksheet B-4 | Session 4 / My Real-Work Case (continued from Session 3)

Name: ________________________

Classify the phenomena observed in your case by layer.

Observed phenomenon Symptom/Problem/Root Cause Confidence (High/Medium/Low)

1.  

 

 

2.  

 

 

3.  

 

 

4.  

 

 

Which layer did we actually fix?

  • Symptom layer

  • Problem layer

  • Root cause layer

Was that choice conscious, or did you realize it in hindsight?
________________________

Sketch the Domain Model for your case.

Actors

________________________

Actions

________________________

States

________________________

Rules

________________________

Objects

________________________

Reflection:

What is the gap between the Domain Model you just drew and the actual design/implementation?
________________________

What problems did (or might) that gap create?
________________________

4.3. 6. Assignment (5 minutes)

Assignment Card #4

Assignment Card #4

Refine the Domain Model of your real-work case.

Specifically check:

  1. States — Did you list all the states the core concept (e.g., task, order, user) can be in?

  2. Rules — Are there real-world rules that aren’t reflected in the system?

  3. Show your Domain Model to one teammate and ask "does this look right?" Record any parts they understood differently.

Preview of next session:
Living with ambiguity — how do you handle ambiguity that cannot be resolved? (Cunningham)

(Continue to next session)

5. Walking Through the Fog — Living with Ambiguity

Core Question: How do you handle ambiguity that cannot be resolved?

Core Concepts: Resolvable vs Essential Ambiguity · Spike Solution · Technical Debt

5.1. Worksheet A-5 | TeamOrder Case: Ambiguity Diagnosis and Spike Design

Worksheet A-5 | Session 5 / TeamOrder Case

Name: ________________________
Date: ________________________

Current state of the TeamOrder case (accumulated from Sessions 1–4):

  • Domain Model roughly sketched

  • Black Box draft exists

  • Some FAC Attributes still [?]

  • Goal: demo in one month

PART 1. List the ambiguities (5 minutes)

Write down all the ambiguities in this case that are still unresolved.

  1. ______________________________

  2. ______________________________

  3. ______________________________

  4. ______________________________

  5. ______________________________

  6. ______________________________

PART 2. Diagnosis — Resolvable vs Essential (8 minutes)

Apply the diagnostic question to each ambiguity.

Diagnostic question:
"Is there an action I can take to find this out?"

Ambiguity Type Basis

1.

* [ ] R * [ ] E

2.

* [ ] R * [ ] E

3.

* [ ] R * [ ] E

4.

* [ ] R * [ ] E

5.

* [ ] R * [ ] E

6.

* [ ] R * [ ] E

R = Resolvable (can be resolved by asking/investigating)
E = Essential (only knowable through trying/building)

PART 3. Spike Design (12 minutes)

Choose the most important item from those classified as Essential
and design a Spike for it.

Ambiguity to explore:
______________________________

What is the simplest exploratory action?
(knowing it will be thrown away, as fast as possible, as minimal as possible)

______________________________
______________________________

If this Spike succeeds, what state are we in?
(what do we need to know to say "it worked"?)

______________________________

If this Spike fails, what state are we in?
(what negative outcome lets us say "that’s a no"?)

______________________________

Estimated time: * [ ] 1–2 hours * [ ] Half a day * [ ] A full day * [ ] More

What decision can we make based on the Spike result?
______________________________
______________________________

PART 4. "Does this decision actually need to be made right now?" check (5 minutes)

From the remaining Essential ambiguities,
which ones do NOT need to be decided right now?

(One month to demo. Does this ambiguity affect the demo?)

Ambiguity Needs decision now? Reason

* [ ] Yes * [ ] No

* [ ] Yes * [ ] No

* [ ] Yes * [ ] No

Small Group Share (5 minutes)

Comparison Points
──────────────────
"Is there an ambiguity one team classified R and another classified E?"
  → Why they saw it differently is the key.
    Was there anything classified E where action was actually possible?
    Conversely, was anything classified R that nobody actually knows?

"What was the hardest part of designing the Spike?"
  → Pinning down what "simplest" means.
    Repeatedly ask: "Can this be made even simpler?"

"Did people use the 'no decision needed right now' column?"
  → This judgment is itself an important capability.
    Moving away from the compulsion to resolve all ambiguity immediately.

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

5.2.1. Worksheet B-5 | My Real-Work Case: Reclassifying Ambiguities

Worksheet B-5 | Session 5 / My Real-Work Case (continued from Session 4)

Name: ________________________

List of unresolved ambiguities in my case
(transfer the [?] items from Sessions 2–4 worksheets here):

  1. ______________________________

  2. ______________________________

  3. ______________________________

  4. ______________________________

  5. ______________________________

Diagnose each ambiguity.

Ambiguity R / E Diagnostic basis

1.

* [ ] R * [ ] E

2.

* [ ] R * [ ] E

3.

* [ ] R * [ ] E

4.

* [ ] R * [ ] E

5.

* [ ] R * [ ] E

Choose one from those classified as Essential:

How did you handle it at the time?

  • Made an assumption and moved on

  • Kept asking but got no answer

  • Just built it to find out

  • Deferred the decision

  • Other: ______________________________

Looking back, what approach would have been best?
______________________________
______________________________

If you were to design a Spike for that Essential Ambiguity,
what would the simplest exploratory action be?
______________________________

5.3. 6. Assignment (5 minutes)

Assignment Card #5

Assignment Card #5

This is a retrospective assignment.

Look for an experience within the last 6 months
where you "only found out by doing."

Write down:

  1. Was that ambiguity Resolvable or Essential?

  2. How did you handle it at the time?
    (Assumption / asking / just building / deferring)

  3. If you had designed a Spike, how would you have done it?
    Design the "simplest exploratory action" now.

Preview of next session:
I’ve seen this problem before —
analogical reasoning and business research

(Continue to next session)

6. I’ve Seen This Problem Before — Analogical Reasoning

Core Question: You may not be seeing this problem for the first time — who has already solved it?

Core Concepts: Analogical Reasoning · Problem-Type Reduction · Trade-off Research

6.1. Worksheet A-6 | TeamOrder Case: Analogical Reasoning + Problem-Type Mapping

Worksheet A-6 | Session 6 / TeamOrder Case

Name: ________________________
Date: ________________________

Core problem structure of TeamOrder (review):
"Reliably deliver urgent task notifications with varying priority levels
to field workers in an unreliable network/power-saving environment,
and allow the team lead to confirm receipt."

PART 1. Analogical Reasoning (15 minutes)

Find problems with a similar structure in a different domain.
Extract the principle that could be learned from each.

Analogous case 1:
Domain: ______________________________
What makes it similar: ______________________________
Solving principle used in that case: ______________________________
What can be imported into TeamOrder: ______________________________

Analogous case 2:
Domain: ______________________________
What makes it similar: ______________________________
Solving principle used in that case: ______________________________
What can be imported into TeamOrder: ______________________________

Analogous case 3:
Domain: ______________________________
What makes it similar: ______________________________
Solving principle used in that case: ______________________________
What can be imported into TeamOrder: ______________________________

PART 2. Problem-Type Mapping (5 minutes)

Reduce the core problem of TeamOrder to a problem type.
(Multiple selections allowed)

  • Matching

  • Trust

  • Cold Start

  • Visibility

  • Rate Control

  • Consistency

  • Other: ______________________________

Known solution patterns for the selected type(s):
______________________________
______________________________

PART 3. Business Research (10 minutes)

Choose one service that deals with a similar notification/task assignment problem
and analyze it from a Trade-off perspective.
(e.g., Slack, Asana, PagerDuty, Naver Works, Kakao Work, etc.)

Service analyzed: +++______________________________+++
What this service prioritized above all else: +
+++______________________________+++
What it gave up (or where it is weak): +
+++______________________________+++
Type of user/environment it is optimized for: +
+++______________________________+++
Why this service's design doesn't fit +
TeamOrder's users (factory floor workers): +
+++______________________________+++
One way TeamOrder should differ from this service: +
+++______________________________+++

Small Group Share (10 minutes)

Comparison Points
──────────────────
"Did different teams find analogous cases in entirely different domains?"
  → The same problem can yield analogies from completely different places.
    If one team found hospital triage and another found TCP retransmission,
    both are valid. The principles they extracted will differ.
    List those differences on the board.

"Where did you get stuck when importing the principle?"
  → Check: were you trying to copy the solution, or import the principle?
    The former almost always ends with "that doesn't fit our situation."

"How was reading Trade-offs different from simply listing features?"
  → Bring out this question to get participants to articulate the difference
    in research perspective.

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

6.2.1. Worksheet B-6 | My Real-Work Case: Applying Analogical Reasoning

Worksheet B-6 | Session 6 / My Real-Work Case (continued from Session 5)

Name: ________________________

The core problem structure of my case in one sentence:
(based on Session 4 Domain Model + Session 5 ambiguity diagnosis)

______________________________
______________________________

Find 2 or more analogous cases with a similar structure in a different domain.

Analogous case 1:
Domain / Service: ______________________________
Similar structure: ______________________________
Principle to import: ______________________________

Analogous case 2:
Domain / Service: ______________________________
Similar structure: ______________________________
Principle to import: ______________________________

If you were to reduce your case to a problem type:

Problem type: +++______________________________+++
Commonly used solution patterns for this type: +
+++______________________________+++

Looking back:

Did you use analogical reasoning when you first received this case?

  • Yes — what analogous case did you reference? ______________________________

  • No — would the cases you found now have helped at the time? ______________________________

Most useful analogous case and why:
______________________________

6.3. 6. Assignment (5 minutes)

Assignment Card #6

Assignment Card #6

For your real-work case:

  1. Take the most useful analogous case you found
    and actually apply its principle to your case.
    Add "result of applying the imported principle"
    to Worksheet B.

  2. (Optional) Find a service or open-source project
    that deals with a similar problem.
    Write 2–3 sentences about it from a Trade-off
    perspective rather than a feature list.

Preview of next session:
How deep should you design —
exploring the Solution Space with Risk-Driven thinking

(Continue to next session)

7. Where to Focus Your Energy — Risk-Driven Design

Core Question: Should every requirement be designed to the same depth?

Core Concepts: Quality Attributes · Engineering Risk · Risk-Driven Model

7.1. Worksheet A-7 | TeamOrder Case: Risk Identification + Technique Mapping

Worksheet A-7 | Session 7 / TeamOrder Case

Name: ________________________
Date: ________________________

TeamOrder current situation summary (accumulated from Sessions 1–6):

  • Core feature: task assignment notification + acknowledgement

  • Users: factory floor team leads (assigning) / team members (receiving, tablet/phone)

  • Environment: unstable Wi-Fi, power-saving mode, night shift operation

  • Notification channel: regular uses FCM app push, night shift urgent unresolved

  • Timeline: demo in 1 month

PART 1. Identify potential failure risks (7 minutes)

Write down as many ways as possible this system could fail.
(No good or bad risks. Volume is the goal)

PART 2. Classify the risks (5 minutes)

Classify each risk above.

Risk E / PM Quality Attribute (if applicable)

1.

* [ ] E * [ ] PM

2.

* [ ] E * [ ] PM

3.

* [ ] E * [ ] PM

4.

* [ ] E * [ ] PM

5.

* [ ] E * [ ] PM

6.

* [ ] E * [ ] PM

7.

* [ ] E * [ ] PM

8.

* [ ] E * [ ] PM

E = Engineering Risk     PM = Project Management Risk

PART 3. Prioritize + map techniques (10 minutes)

Choose the top 3 Engineering Risks and map the appropriate
exploratory/validation technique for each.

Risk #1 (most critical):

If this risk materializes:

Response technique:

  • Prototype / Spike

  • Load / performance test

  • Architecture review

  • Security analysis (Threat model)

  • Real environment test

  • Diagramming / modeling

  • Other:

When and how will you use this technique:

Risk #2:

If this risk materializes:

Response technique:

  • Prototype / Spike

  • Load / performance test

  • Architecture review

  • Security analysis (Threat model)

  • Real environment test

  • Diagramming / modeling

  • Other:

When and how will you use this technique:

Risk #3:

If this risk materializes:

Response technique:

  • Prototype / Spike

  • Load / performance test

  • Architecture review

  • Security analysis (Threat model)

  • Real environment test

  • Diagramming / modeling

  • Other:

When and how will you use this technique:

PART 4. "What doesn’t need to be designed right now" (8 minutes)

Based on the risk checklist:
what has low enough risk for this demo (1 month)
that design energy doesn’t need to be spent on it right now?

(e.g., "Scalability — only 15 users now, irrelevant for the demo")

Item Reason

1.

2.

3.

When will you revisit these?

Small Group Share (8 minutes)

Comparison Points ────────────────── "Do different teams have different top-3 risks?" → Same system, different risk priorities — what contextual difference produced that judgment? May be a demo perspective vs production perspective gap.

"Are there cases where PM Risk and Engineering Risk are confused?" → Most commonly mixed: "We probably can’t finish in a month" → PM Risk "We probably can’t guarantee night notification delivery" → Engineering Risk Point out that the techniques for each are completely different.

"Was 'no need to decide now' hard to fill in?" → If yes — why was it hard? How do you negotiate with the pressure to design everything perfectly? This is the core mindset shift of this session.

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

7.2.1. Worksheet B-7 | My Real-Work Case: Risk Identification + Design Energy Allocation

Worksheet B-7 | Session 7 / My Real-Work Case (continued from Session 6)

Name: ________________________

Top 3 Engineering Risks in my case:

1.
Quality Attribute:
Response technique:

2.
Quality Attribute:
Response technique:

3.
Quality Attribute:
Response technique:

Looking back:

Where did I actually spend design energy when working on this case?

Part where I spent the most design time:

Part where I moved through fastest:

From a Risk-Driven perspective — is there an inversion needed?
(Something heavily designed with low risk /
Something quickly passed over with high risk)

________________

7.3. 6. Assignment (5 minutes)

Assignment Card #7

Assignment Card #7

Choose the most important Engineering Risk
in your real-work case:

  1. Actually apply the response technique.
    (Spike, prototype, diagramming, etc.)

  2. Record whether the risk was reduced, or
    whether new risks were discovered.

  3. Add "risk response result" to Worksheet B.

Preview of next session:
Seunghyun’s map — verifying the solution against the original problem
and integrating everything (final session)

(Continue to next session)

8. Seunghyun’s Map — Validating and Integrating the Solution

Core Question: A solution that looks plausible is different from one that actually works

Core Concepts: Problem-Solution Fit · Pre-mortem · Integration Retrospective

8.1. Worksheet A-8 | TeamOrder Case: Problem-Solution Fit + Pre-mortem

Worksheet A-8 | Session 8 / TeamOrder Case

Name: ________________________
Date: ________________________

TeamOrder final solution (conclusions from Sessions 1–7):

  • Regular task assignment → FCM app push (with acknowledgement)

  • Night shift urgent → SMS fallback (automatic switch if unacknowledged)

  • Notification channel interface abstraction

  • Demo scope: the three items above

  • Scalability design: deferred until after demo

PART 1. Problem-Solution Fit Check (10 minutes)

Compare the problem definition from Sessions 1–4 with the current solution.

From the problem definition Addressed in the solution? How it was addressed

Team members miss tasks causing line stoppage

* [ ] Addressed * [ ] Partially * [ ] Not addressed

Separate message required after assignment

* [ ] Addressed * [ ] Partially * [ ] Not addressed

Night shift urgent assignment case

* [ ] Addressed * [ ] Partially * [ ] Not addressed

Team lead doesn’t know if member received it

* [ ] Addressed * [ ] Partially * [ ] Not addressed

Mobile/tablet environment

* [ ] Addressed * [ ] Partially * [ ] Not addressed

Among the things "not built" — items to revisit later:
(items deferred in Session 7 PART 4)

Item Expected review point

1.

2.

3.

PART 2. Pre-mortem (12 minutes)

"We showed the TeamOrder notification feature in the demo
and deployed it to production.
Three months passed. It failed."

What might the reasons be? Write as many as you can. (3 minutes individual work)

Top 3 failure reasons that came up most in the small group:

From these, what can be addressed proactively right now:

Failure reason Response approach

PART 3. Compare Session 1 to Now (8 minutes)

Do you remember the "things you thought of within 30 seconds" in Session 1?
(Or look back at Session 1 Worksheet A-1 Part 1)

What you thought of in 30 seconds back then:

Comparing with the solution now:

The same:

What changed (added, removed, or modified):

As a result of understanding the problem more deeply:

  • The solution became simpler

  • The solution became more complex

  • There are things that no longer need to be built

  • Some of what I first thought was wrong

  • Other:

The single biggest thing that changed in me during this workshop:

Small Group Share (8 minutes)

Key comparison point for this session ──────────────────────────────────────── "Did anyone check 'there are things that no longer need to be built' 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 go?"

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

"Among Pre-mortem failure reasons,
are there things that could have been caught by Session 2–4 tools?" → If that connection is visible, the workshop’s learning has been integrated.

8.2. 4. Real-Work Case Slot — Final Integration (25 minutes)

Session 8’s real-work case slot is different from usual. This is the time to pull out Worksheets B-1 through B-7 and assemble one completed analysis of the case.

8.2.1. Worksheet B-8 | My Real-Work Case: Final Integration Canvas

Worksheet B-8 | Session 8 / My Real-Work Case — Completed

Name: ________________________

Case title:

Original requirement (from Session 1):

Problem Understanding (Problem Space exploration results)

FAC Summary (Session 2):
  Functions:
  Attributes (key):
  Constraints (key):

Resolution layer (Session 4):
  * [ ] Symptom   * [ ] Problem   * [ ] Root Cause     Reason for choice:

Domain Model key elements (Session 4):
  Key States:
  Key Rules:

Key ambiguities and how they were handled (Session 5):
  Resolved as Resolvable:
  Spiked as Essential:
  Deferred:

Problem-type reduction (Session 6):

Solution (Solution Space exploration results)

Top 3 Engineering Risks (Session 7):

What will be built now:

What will be built later + review point:

What was decided not to build + reason:

Problem-Solution Fit Check (Session 8):

Is the core of the problem reflected in the solution?   * [ ] Yes   * [ ] Partially   * [ ] No

Is there anything among the things not built that is actually needed right now?

Retrospective:

Compared to when you first received this case,
how did understanding the problem change the solution?

What became simpler:

What disappeared (things you came to know didn’t need to be built):

What became clearer:

Presentation (optional, 10 minutes)

Volunteers present their completed case in about 5 minutes.

Suggested structure:

  1. What was the original requirement

  2. The biggest thing that changed as you understood the problem

  3. What you decided to build and what you decided not to build

  4. One thing you learned from this case

8.3. 6. Workshop Closing (5 minutes)

Assignment Card #8 — This one isn’t an assignment

Final Card

No assignment.

Instead, take this one thing with you.

The next time you receive a requirement,
before crossing into the Solution Space,
pause just once and ask:

"What do I know right now?
 And what do I still not know?"

That question is this entire workshop.

9. Appendix: My Real-Work Case — 8-Session Cumulative Record

Worksheet B deepens the same case progressively across 8 sessions. This page is a space to organize key discoveries from each session at a glance.

9.1. After Session 1 — Discovery Notes

Tools applied: Problem Space vs Solution Space · Einstellung Effect · Presumptive Architecture

What I discovered:

What changed (problem understanding, solution direction):

9.2. After Session 2 — Discovery Notes

Tools applied: Functions / Attributes / Constraints (FAC) · Three Sources of Ambiguity

What I discovered:

What changed (problem understanding, solution direction):

9.3. After Session 3 — Discovery Notes

Tools applied: Context-Free Questions · Black Box Test · Jobs-to-be-Done

What I discovered:

What changed (problem understanding, solution direction):

9.4. After Session 4 — Discovery Notes

Tools applied: Symptom-Problem-Root Cause layers · Problem Framing · Domain Model

What I discovered:

What changed (problem understanding, solution direction):

9.5. After Session 5 — Discovery Notes

Tools applied: Resolvable vs Essential Ambiguity · Spike Solution · Technical Debt

What I discovered:

What changed (problem understanding, solution direction):

9.6. After Session 6 — Discovery Notes

Tools applied: Analogical Reasoning · Problem-Type Reduction · Trade-off Research

What I discovered:

What changed (problem understanding, solution direction):

9.7. After Session 7 — Discovery Notes

Tools applied: Quality Attributes · Engineering Risk · Risk-Driven Model

What I discovered:

What changed (problem understanding, solution direction):

9.8. After Session 8 — Discovery Notes

Tools applied: Problem-Solution Fit · Pre-mortem · Integration Retrospective

What I discovered:

What changed (problem understanding, solution direction):