기획자는 어떻게 『문제 정의』 를 해야할까?

기획자는 모든 발상에 Why? 가 들어가야 한다. 

모든 발상의 근원은 Why로부터 시작하고, How는 늘 다음이다.

따라서 기획자가 수많은 문제 중 핵심 문제를 정의하고, 그 원인 분석하기 위해서는

"문제 정의" 능력이 반드시 필요하다.

 

문제는 사용자의 AS-IS와 TO-BE의 차이로부터 발생한다.

여기서 AS-IS는 현재 상태, TO-BE는 바람직한 상태를 의미한다.

즉 문제를 정확히 정의하려면 현상(AS-IS)을 발견하고, 원인을 보고, 문제를 짚어내면 된다.

 

1. 현상발견: 목표 달성을 방해하는 문제 현상들을 발견 2. 문제 정의: 현상의 원인을 정의 3. 핵심 문제정의: 여러가지의 문제 중, 중요도에 따라 해결 우선순위를 설정

---

1. 현상 발견 💡

---

 

목표를 달성하는데 문제 현상들을 발견하는 단계다. 

비즈니스, 사용자 등 여러 관점에서 다양한 수단을 통해 Paint-Point를 도출하는 것이 목표이다.

 

	방법
사용자  피드백 수집	설문조사, 인터뷰, VOC 분석을 통해 사용자들이 겪는 문제를 수집
유저 테스트	실제 사용자들이 서비스를 사용하는 모습을 관찰하여 문제를 발견
유관 부서  인터뷰	고객을 자주 만나는 세일즈 팀원, UX전문가인 디자이너 등 유관 부서 팀원 인터뷰를 통해 문제 발견
데이터 분석	비정상적인 패턴이나 예기치 않은 현상 발견
경쟁사 분석	경쟁사 서비스 분석을 통해 자사의 문제점이나 개선점을 발견

우리는 VOC (Voice of Customer)나 데이터 분석, 유저테스트 등을 통해

정량적/ 정성적 데이터를 수집할 수 있다. 

이를 통해 유저의 액션을 살피며 프로덕트를 고도화 하는 것이 목표이다. 

 

 

2. 문제 정의 ❓

---

 

현상 발견 단계에서 문제를 찾아내었다면, 

이번엔 그 문제의 "근본적 원인"을 설명해야 한다.

 

그런데 말이야 쉽지, 문제를 정의하라고 해도 

근거 데이터의 분석이 없는 문제 정의는 그저

"현상 그 자체가 문제로 정의되어 버리는 실수"가 되기 십상이다. 

그리고 문제의 정의가 자판기마냥 매번 정답이 튀어나오지도 않을 것 아닌가...

 

그러던 중 서비스기획자 세계에 막 발을 들인 나로서는 매우 큰 도움이 되는

문제 정의 규칙을 찾을 수 있었다!

 

5Whys 와 로직트리란?

 

  ➡️ 5Whys : 문제의 근본 원인을 찾기 위해 "왜?"를 다섯 번 반복적으로 묻는 방법.

각 답변은 이전 질문의 원인에 해당한다.

예시 ) 문제: 사용자가 주문을 완료하지 않는다. 1차 Why ?: 사용자가 결제 페이지에서 이탈한다. 2차 Why ?: 결제 페이지가 로딩이 느리다. 3차 Why ?: 결제 서버의 성능이 부족하다. 4차 Why ?: 서버 최적화가 이루어지지 않았다. 5차 Why ?: 서버 최적화를 위한 자원 할당이 부족하다.

 

 

 

➡️ 로직트리: 나무 구조처럼 하나의 큰 문제를 여러 가지 세부적인 나뭇가지로 분리한 후, 

이를 다시 해결할 수 있는 구체적인 질문이나 하위 항목으로 나누는 방식이다.

이때, 반드시 MECE 원칙을 따르며 로직트리를 분리해야만 한다.

	상세
Mutually Exclusive (상호 배타적)	- 각 요소는 서로 겹치지 않아야 함.    - 예시: "노래"이라는 범주에서 "팝송"과 "K-POP"은 서로 겹치지 않는 분류입니다. 하나의 노래가 두 범주에 속할 수는 없다.
Collectively  Exhaustive (전체 포괄적)	- 누락없이 문제의 모든 면을 다뤄야 함. - 예시: "노래" 범주에서 "팝송"과 "K-POP"만 있으면 "J-POP"이나 "힙합"이 빠질 수 있으므로, 모든 가능한 카테고리를 포함해야 합니다.

 

5Whys 와 로직트리 모두 문제를 쪼개서 생각하는 것이 핵심이다.

문제를 쪼개다 보면 범위를 좁아져 답을 쉽게 찾을 수 있다.

 

5Whys, 로직트리 예시 

 

 

3. 핵심 문제 정의 🔢 

---

 

문제 정의가 완료되었다면, 그 중 우선순위를 고려한 핵심 문제를 뽑아내야한다.

우리의 몸뚱아리는 하나기 때문에

모든 문제를 동시에 처리할 수 없기 때문이다.

 

 

우리는 정의한 문제들을 다음과 같은 기준으로 분류해 볼 수 있을것이다.

 

높은 임팩트 / 낮은 리소스	높은 임팩트 / 높은 리소스
낮은 임팩트 / 낮은 리소스	낮은 임팩트/ 높은 리소스

 

우선순위가 가장 높은것은 단연코 "높은 임팩트 / 낮은 리소스" 안건일 것이다.

저비용으로 고효율의 기능개선이 이루어지니까.

 

반면에 "높은 임팩트 / 높은 리소스" 안건은 

프로덕트에 매우 중요하지만 그만큼 시간과 리소스가 많이 투자되어야 하므로

중 - 장기적으로 시행되는 경우가 많을 것이다.

 

 "낮은 임팩트 / 낮은 리소스" 안건은 시급도도, 중요도도 떨어지지만

저비용 안건이므로, 자투리 시간에 해결해볼 수 있다.

 

가장 후순위는 "낮은 임팩트 /  높은 리소스" 안건이다.

이 안건은 가급적 나중에 해결해야 하는 문제다.

 

 

---

 

 

이렇게 기획자가 어떤 방법을 통해 문제를 정의하는지 정리해봤다.

그리고 정리하면서 느꼈던 점 중

문제 정의시 주의할 점에 대해 짧게 남겨본다.

 

🔍 문제 정의 과정에서 가장 흔하게 하는 실수는 뭐가 있을까?

 

1. 문제 상황 자체를 문제로 정의해 버리는 것 

ex) 검색 기능 사용률이 낮다 

 

➡️ 검색 기능 사용률이 낮은것은 상황이지 원인이 아니다.

검색 정확성 저하 / 추천기능의 강도 / 검색엔진 UX 배치 등이 원인 일 수 있고,

이 또한 매우 세부적이고 자세하게 정의해야 한다.

 

2. 문제 정의를 제대로 하기 전에 미리 ‘해결 방안’을 정해두고 시작하는것

➡️ 해결 방안은 반드시 "정의된 문제"에서 시작해야 한다. 

해결 방안을 먼저 정해놓으면, 문제 정의가 왜곡될 가능성이 매우 높다.

 

---

따라서 문제를 찾았을 때는, 이것이 진짜배기 문제인지에 대해

데이터를 기반으로 검증해보는 과정이 반드시 필요하다!

 

그러므로 다음 정리는 가설 수립& 검증에 대해 해보려고 한다.