내일배움캠프 TIL: "풀 수 있는 문제"와 "중요한 문제"는 다르다

 

오늘은 팀 프로젝트에서 문제 정의부터 가설 설정까지 전 과정을 처음으로 팀원들과 함께 해봤습니다.

솔직히 말하면, 생각보다 훨씬 어려웠습니다.

 

마케터로 일할 때는 "이 캠페인이 왜 안 되는가"를 분석하는 건 익숙했는데,

"어떤 문제를 풀 것인가"를 정의하는 건 완전히 다른 근육을 쓰는 일이더라고요.

 

그리고 팀원 6명이 각자 다른 프레임으로 문제를 보고 있다는 걸 오늘 처음으로 체감했습니다.

---

오늘 한 것: 배민 퀵커머스 문제 정의 → 가설 설정

풀었던 문제

배달의민족 앱을 자주 쓰는 음식 배달 중심 사용자가

퀵커머스(B마트·장보기)를 이용하지 않는 이유가 뭔가를 팀이 함께 정의했습니다.

 

최종 문제 정의는 이렇게 확정됐습니다.

배민을 음식 배달 중심으로 인식하는 사용자는 음식 주문 탐색~완료 과정에서 장보기·쇼핑 니즈가 발생할 수 있지만, 해당 니즈를 퀵커머스 구매 맥락으로 자연스럽게 연결해주는 장치가 부재하여 첫 구매 전환으로 이어지지 못하고 거래액 확대의 기회를 놓치고 있다.

---

오늘 가장 크게 배운 것

1. 문제 정의에도 레이어가 있다

오늘 팀에서 나온 문제 정의 후보가 크게 세 가지였습니다.

 

문제 정의	레이어	특징
비마트의 차별성이 부재하다	근본 원인	포지셔닝·전략 문제. 임팩트 크지만 PM이 단독으로 건드리기 어려움
음식 주문 맥락에서 퀵커머스로 연결되는 UX 장치가 없다	현상/구조	앱 기능·UX로 개입 가능. 솔루션이 보임
정보 위계가 약해 탐색과 선택으로 이어지지 않는다	현상/증상	가장 구체적이지만 범위가 좁음

투

표 프레임워크(Impact / Evidence / Controllability / Strategic Fit / Problem Clarity)로 점수를 매겼더니 UX 문제가 1위가 됐습니다.

 

근데 여기서 중요한 건.. 그 프레임워크는 "중요한 문제"를 고르는 게 아니라 "풀기 좋은 문제"를 고르는 구조였던것 같아요.

Controllability 비중이 높다 보니 자연스럽게 앱 UX 문제가 올라올 수밖에 없었고,

5일이라는 제약으로 인해서 더 조급해졌던 것 같습니다.

 

근본 원인(차별성 부재)을 건너뛰고 현상(UX 진입 약함)을 문제로 잡은 거라.. 

 

하지만 여기서 더 중요한건,

그렇다고 이게 나쁜 선택은 아니라는 것도 깨달았습니다.

부트캠프 프로젝트에서 솔루션까지 그려야 하는 상황에서는 오히려 현실적인 판단이었고,

중요한 건 그 선택의 한계를 인식하고 있다는 걸 아는 것이었습니다.

근본 원인은 비마트의 차별성 부재이나, 본 프로젝트에서는 앱 기능·UX 범위 내에서 개입 가능한 문제에 집중한다.

 

 

---

2. 가설은 "~를 강화한다"가 아니라 "[개입]하면 [지표]가 변할 것이다"

팀에서 처음 나온 가설이 이런 형태였습니다.

첫 화면에서 복잡한 정보 위계를 우선순위별로 정리하여 집중적으로 강화한다

 

이건 가설이 아니라 솔루션 서술입니다.

검증할 수가 없다고 생각했어요,.

그래서 아래 구조로 바꿨습니다.

 

[사용자 상황] + [개입] + [기대 결과(KPI)]

 

예를 들면:

홈 화면에서 3곳에 분산된 퀵커머스 진입점의 정보 위계를 정리하면, 퀵커머스를 인식하지 못했던 사용자의 첫 진입률이 높아질 것이다. (KPI: 홈 화면 내 퀵커머스 첫 진입률, A/B테스트)

 

마케터로 일할 때 "이 소재가 더 잘 될 것 같다"는 감을 A/B테스트로 검증했던 것처럼,

PM도 가설을 검증 가능한 형태로 설계해야 한다는 게 같은 맥락이더라고요.

---

3. 유저 플로우를 기준으로 가설을 나누면 솔루션이 안 겹친다

오늘 가설 3개가 처음에는 경계가 흐릿했는데, 유저 플로우 단계로 나누니까 명확해졌습니다.

앱 진입
  └→ 가설 1: 홈 화면 정보 위계 정리 → 퀵커머스 첫 진입률 제고

음식 배달 탐색·주문 중
  └→ 가설 2: 주문 완료 직후 맥락 기반 퀵커머스 노출

배달 탐색 이탈 또는 배달 대기 중
  └→ 가설 3: 이탈 후 재진입 시 퀵커머스 추천 / 배달 대기 중 추가 구매 유도

 

같은 사용자가 앱 안에서 이동하는 흐름을 단계별로 커버하는 구조라서, 가설이 겹치지 않고 각자 역할이 생겼습니다.

---

4. 솔루션에도 리스크 검토가 필요하다

오늘 팀에서 나온 해결방안 중 몇 가지가 현실적으로 성립이 안 된다는 걸 발견했습니다.

• "최소주문금액 없이 주문하기"로 B마트 유도 → B마트도 최소주문금액 15,000원으로 동일. 논리 모순
• 음식 배달 탐색 중 퀵커머스 노출 → 입점 사장님 매출 충돌 리스크

PM이 솔루션을 제안할 때 비즈니스 이해관계자(여기선 입점 사장님)와

기술적 구현 가능성을 동시에 고려해야 한다는 걸 팀 토론에서 자연스럽게 배웠습니다. 

---

5. 페르소나는 목적에 따라 다르게 쓴다

오늘 페르소나를 두 가지 형태로 정리했는데, 쓰임새가 달랐습니다.

유형	형태	용도
공통 속성 추상화 페르소나	Demographics / Psychographics / App Usage / Shopping Behavior	문제 정의·가설 설명용
구체적 인물 페르소나	이름·나이·직업·페인포인트·니즈·행동 패턴	솔루션 설계·타겟 집중용

 

문제 정의할 때는 넓게, 솔루션 설계할 때는 좁게 !

단계에 따라 페르소나의 구체성이 달라져야 한다는 게 오늘 가장 실용적인 배움이었습니다.

---

오늘 가장 크게 배운 것

 

프레임워크는 좋은 문제를 보장하지 않는다. 선택의 이유와 한계를 인식하고 명시하는 것이 프레임워크보다 중요하다.. ㅠ

 

내일은 오늘 확정한 가설을 바탕으로 솔루션을 구체화하는 작업을 이어갈 예정입니다.

가설별 KPI를 어떻게 실제 PRD에 녹일지, 그리고 타겟 페르소나를 솔루션 설계에 어떻게 연결할지가 다음 과제입니다...