📌 쪼개고 쪼개는 "문제 정의"

🎯 "문제 정의"의 흐름

1. 현상 발견
→ 목표 달성을 방해하는 "문제 현상"을 포착

2. 문제 정의
→ 이 현상이 왜 생겼는지, 원인을 파악

3. 핵심 문제 정의
→ 여러 문제 중 가장 중요한 핵심 문제를 도출

---

🔍 1. "문제 현상"을 발견하는 방법

비즈니스 측면과 사용자 측면 모두에서 문제를 들여다본다.
이때 사용할 수 있는 방법은 다양하다.

• 사용자 피드백 수집 (설문, 인터뷰, VOC 등)

• 유저 테스트 (직접 사용하는 모습을 관찰)

• 유관 부서 인터뷰 (세일즈, 디자이너 등)

• 데이터 분석 (이탈률, 전환율, 이상 행동 패턴 등)

• 경쟁사 분석 (우리는 뭐가 부족한가?)

---

🔍 2. "문제 정의"를 하는 방법

• 문제 현상을 한 문장으로 표현
• 그로 인한 부정적 영향을 설명
• 그 원인은 무엇인지 고민

< 실무에서 자주 쓰는 두 가지 프레임워크 >

• 5 Whys : "왜?"를 다섯 번 반복해서 문제의 뿌리를 파악
• Logic Tree : 문제를 나무처럼 가지 쳐서 구조화
  ( 이때 꼭 지켜야 할 원칙 : MECE )
  -- Mutually Exclusive (겹치지 않게)
  -- Collectively Exhaustive (빠짐없이)

---

🔍 3. "핵심 문제"를 정하는 법

Impact vs. Effort Matrix로 정리한다.

🧭 Impact vs. Effort Matrix

	💪 낮은 노력 (Low Effort)	💪 높은 노력 (High Effort)
🚀 높은 임팩트 (High Impact)	✅ Quick Wins	Major Projects
🐢 낮은 임팩트 (Low Impact)	Fill-ins	Hard Slogs

→ 임팩트는 크고, 노력은 적은 Quick Win을 우선 처리한다.

---

⚠️ 문제 정의 시 주의할 점 : 해결 방안부터 정해두지 않기

• 문제 정의보다 해결책을 먼저 떠올리면 진짜 문제를 놓칠 수 있다.
• 문제를 있는 그대로 보기!
• 먼저 관찰하고, 원인을 여러 각도에서 정의해보는 게 우선이다.

---

💭 오늘의 느낀 점

문제를 정의한다는 게 생각보다 디테일한 것이라는 것을 느꼈다.
무언가 문제가 있으면 "이걸 고쳐야겠다", "이 기능이 필요하겠다"처럼 해결 방안을 먼저 떠올리곤 했는데, 그러면 안 된다는 걸 안 것 만으로도 오늘 배운 것이 많은 것 같다.

특히 5 Whys나 Logic Tree와 같은 도구(방법론?)를 통해
문제를 해부해볼 수 있단 것이 신기했다.

오늘 배운 것이 어렵게 느껴지지만, 후에 방법론을 써보고 익숙해지면 언젠가는 문제를 잘 쪼갤 수 있는 능력이 생길 것 같다.