[내일배움캠프 PM 4기] 11일차 - 문제 정의부터 가설 검증까지, 논리적인 해결 프로세스 🚀

안녕하세요! 오늘은 프로덕트 매니저(PM)의 가장 중요한 일, 바로 '문제 정의 및 해결'에 대한 논리적인 프레임워크를 배웠어요. 단순히 기능을 만드는 게 아니라, '왜 이걸 해야 하는지'를 명확히 하고 진짜 문제를 해결해야 프로덕트와 비즈니스 가치가 올라가죠.

PM이라면 꼭 알아야 할 '목표 수립 - 문제 정의 - 가설 수립 & 검증'의 3단계 프레임워크를 실무에서 써먹을 수 있는 팁과 함께 정리해봤습니다!

---

1. 문제 해결의 큰 그림: '목표 - 문제 - 가설' 프레임워크

PM은 감에 의존하지 않고, 검증 가능한 가설 기반의 사고로 일해야 합니다. 이 3단계 프레임워크가 바로 그 논리적인 길잡이가 되어줍니다.

단계	핵심 내용	왜 중요할까요?
1. 목표 수립	상위 비전 OKR과 연계하여 달성해야 할 핵심 지표(KPI)를 설정.	문제 해결의 방향성과 성공 여부 판단의 기준을 제시해요.
2. 문제 정의	수많은 현상 중 핵심 문제를 짚어내고, 근본 원인을 분석.	증상(현상)이 아닌 원인을 해결해야 진짜 변화가 일어나죠.
3. 가설 수립 & 검증	문제 해결을 위한 예상 답(가설)을 세우고, A/B 테스트 등으로 검증하며 개선을 반복	작게 시작해서 빠르게 실패하고, 성공 확률 높은 방향으로 점진적 개선(애자일 원칙).

---

2. 1단계: 목표 수립 — 나침반과 기준점 만들기

모든 일에는 목표가 있어야 해요. 그래야 팀이 가장 중요한 문제에 집중하고, 해결의 성공 여부를 객관적으로 판단할 수 있습니다. 목표는 프로덕트 비전 → OKR→KPI 순으로 폭포처럼 내려와야 합니다.

💡 OKR vs. KPI: 뭐가 다를까요?

항목	OKR (Objective and Key Results)	KPI (Key Performance Indicator)
초점	"무엇을 달성할 것인가" (도전적 목표)	"어떻게 성과를 측정할 것인가" (일상적 지표)
성격	비전을 향한 도전적, 단기적 목표 (70~80% 달성률 적절)	비즈니스 성공을 측정하는 정량적/정성적 지표
관계	OKR 목표 달성을 위해 $\text{KPI}$가 핵심 성과 지표로 쓰이기도 함.	비즈니스 전반의 성과를 지속적으로 추적.

 

📌 목표 수립 시 가장 중요한 주의점: 균형!

PM은 사용자 가치와 비즈니스 가치 사이의 균형을 맞추어야 해요. 사용자에게 아무리 편리해도 비즈니스에 마이너스가 되면 지속 가능하지 않고, 회사만 이익을 봐도 사용자가 떠나면 프로덕트는 망가지죠. (카카오톡 생일 알림 기능처럼 둘 다 잡은 사례가 좋은 예!)

---

3. 2단계: 문제 정의 — '현상'이 아닌 '원인' 찾기

문제 정의는 현재 상태(AS IS)와 바람직한 상태(TO BE)의 차이를 명확히 설명하는 과정입니다.

🔍 문제 정의 3단계 프로세스

1. 현상 발견: OKR이나 KPI달성을 방해하는 징예(이탈률 증가, 특정 기능 비사용)를 정량/정성 데이터로 발견합니다.
2. 문제 정의: 발견된 현상으로 인한 부정적 영향(결과)을 분석하고, 이 현상을 일으킨 근본 원인을 파악합니다.
   • 현상/영향/원인을 반드시 구분해서 생각해야 피상적인 해결책을 피할 수 있어요.
   • 5 Whys나 로직트리 같은 프레임워크를 활용하면 원인을 쪼개서 찾는 데 도움이 됩니다. (특히 MECE 원칙을 지켜 중복 없이 누락 없이 쪼개야 정확해요!)
3. 핵심 문제 정의: 여러 원인 중 Impact vs. Effort Matrix를 활용해 우선순위를 매겨 가장 해결할 가치가 높은 핵심 원인을 선택합니다.

⚠️ 문제 정의 시 가장 많이 하는 실수

문제 정의를 제대로 하기도 전에 '해결 방안'을 미리 정해두는 거! (예: "고객이 글씨가 작다고 하니 글씨 크기를 키우자!") → 이렇게 하면 문제 정의가 왜곡되고 근본적인 해결책을 놓칠 수 있어요. 있는 그대로의 현상을 해석하고, 그 원인을 파고드는 게 중요합니다.

---

4. 3단계: 가설 수립 & 검증 — 예측하고 실험하라

핵심 문제가 정의되면, 이제 그 문제를 해결할 '예상 답' 즉, 가설을 세우고 검증할 차례입니다.

📝 좋은 가설을 세우는 법

가설은 "만약 ~하면, ~할 것이다" 형태의 인과 관계를 설명하는 문장이어야 하며, 반드시 검증 가능해야 합니다.

• 변수와 결과 포함: "만약 카테고리 필터를 추가하면, 사용자의 메뉴 검색 시간이 20% 감소할 것이다."
• 정량적 결과 포함: 사용자 만족도 같은 정성적 결과 외에, 주문 취소율, 클릭률 등 검증이 쉬운 정량적 지표를 함께 포함하는 게 좋습니다.

🧪 가설을 검증하는 방법

방법	핵심	장점	사용하기 좋은 상황
A/B 테스트	두 가지 버전을 비교해 더 나은 옵션 확인.	데이터로 명확한 비교 가능.	두 가지 해결책 중 어떤 게 더 효과적인지 알고 싶을 때.
사용자 인터뷰	사용자와 직접 대화해 숨겨진 니즈 파악.	문제의 맥락 파악, 초기 아이디어 검증.	왜 사용자가 특정 행동을 하는지 이유를 깊이 파고들 때.
유저 테스트	사용자가 제품을 직접 쓰는 모습 관찰 및 피드백.	실제 사용 과정에서 발생하는 구체적 문제점 발견.	새로운 기능이나 UX의 사용성 개선점을 찾을 때.
오픈 후 데이터 분석	기능 출시 후 사용자 데이터로 성과 확인.	빠르고 효율적.	초기 가설 검증 후 성과를 빠르게 확인하고 싶을 때.

💡 검증 후 실패해도 괜찮아요! 결과가 예상과 다르더라도, 실패를 통해 얻은 인사이트를 기반으로 가설을 수정하고 다시 검증하면 됩니다. 진정한 실패는 가설 검증 자체가 불가능해서 아무 인사이트도 얻지 못한 경우예요. PM은 이 과정을 반복하며 점진적으로 프로덕트를 개선해 나가는 역할을 합니다.

오늘 배운 프레임워크를 바탕으로 여러분이 관심 있는 프로덕트에 적용해보는 연습을 꼭 해보세요! 목표 → 문제 → 가설 순서대로 생각의 근육을 키우는 게 PM 성장의 핵심이니까요. 💪