25일차[서비스 기획 숙련 강의 완강, 과제 회고]

오늘 달성한 목표

1. 아티클 카타

2. 서비스 기획 숙련 강의 완강

3. 서비스 기획 입문 과제 피드백 면담 및 회고

1.  아티클 카타 피드백 핵심 요약

1) UX 리서치 인터뷰에서 중요한 점

**“사용자의 말보다 실제 경험을 끌어내는 질문을 해야 한다”**는 점.

핵심 포인트

• 미래 행동 예측 질문보다 과거 경험 질문
  • ❌ “이 기능 있으면 쓰실 것 같나요?”
  • ✅ “비슷한 상황에서 이전에는 어떻게 하셨어요?”
• 사용자는 미래 행동을 정확히 예측하지 못하기 때문에
  실제 경험 기반 질문이 더 신뢰도 높은 인사이트를 준다.
• 질문을 미리 정답처럼 정해두고 몰아가지 않기
• 사용자가 인터뷰 의도를 눈치채지 않도록 하기

즉,

사용자의 ‘할 것 같다’는 말보다 ‘실제로 했던 경험’을 듣는 것이 중요하다.

---

2) 인터뷰 진행 시 바이어스 주의

튜터님은 특히 인터뷰어가 의도나 기능 배경을 너무 설명하면 편향이 생긴다고 강조했습니다.

주의해야 할 것

• 기능을 왜 만들었는지 먼저 설명하지 않기
• 프로젝트 배경을 너무 자세히 공유하지 않기
• 인터뷰 중 사용자의 질문에 바로 의도 설명하지 않기
• 실제 서비스 사용 환경과 비슷하게 진행하기

좋은 인터뷰는

사용자가 스스로 생각하고 행동하도록 자연스러운 환경을 만드는 것
이라는 점을 다시 강조한 피드백입니다.

 

---

3) 최종 프로젝트 커뮤니케이션 팁

두 번째 핵심은 팀 프로젝트를 위한 오버커뮤니케이션.

 

상대방도 내가 아는 만큼 알고 있을 거라고 가정하지 말 것

실무 팁

• 역할 분담은 더 세세하게 공유
• 진행 상황은 자주 업데이트
• 작은 내용도 미리 공유
• 충돌 가능성은 초기에 제거

즉,

조금 과하다 싶을 정도로 미리 공유하는 것이 팀 문제를 줄이는 가장 좋은 방법

 

 

2. 오늘 배운 내용 정리: 데이터로 문제를 찾고 PM처럼 결정하기

오늘은 단순히 데이터를 보는 법이 아니라,
**“숫자 → 문제 발견 → 우선순위 → 실행 → 회고”**까지 PM 실무의 한 사이클을 배운 느낌이었다.

특히 앱스토어 리뷰 데이터부터 퍼널, AARRR, 킥오프/회고, 공유 방식, PM 케이스 스터디까지 이어지면서
실무에서 PM이 데이터를 어떻게 해석하고 팀을 움직이는지 감이 많이 잡혔다.

---

1) 앱스토어 리뷰 데이터에서 진짜 문제 찾기

가장 먼저 배운 건 정성 데이터 활용이었다.

겉으로 보면 단순한 리뷰 모음처럼 보이지만,
실제로는 사용자 불만이 가장 빠르게 쌓이는 현실적인 VOC 데이터였다.

예시로 버스 앱 리뷰를 보면서 사용자가 반복적으로 말하는 문제를 묶어보니,

• 도착 시간 정확도 낮음
• 위젯 오류
• 업데이트 이후 UX 불편
• 지역별 정보 누락
• 앱 속도 저하

처럼 패턴이 보이는 문제군이 생겼다.
여기서 중요한 건 리뷰 하나하나가 아니라 반복되는 문제의 빈도와 맥락이었다.

오늘 느낀 건,
PM은 단순히 “불편하네요”를 읽는 사람이 아니라
여러 개의 불편을 하나의 구조적인 문제로 묶는 사람이라는 점이었다.

---

2) 퍼널 분석으로 어디서 이탈하는지 보기

다음은 퍼널 분석이었다.

퍼널은 사용자가 목표 행동까지 가는 여정을 단계별로 보는 방식인데,
오늘은 특히 어디서 많이 빠지는지 보는 시선이 중요했다.

예를 들면

유입 → 상세 → 장바구니 → 주문 → 결제 → 완료

이런 흐름에서
어느 단계에서 이탈률이 가장 높은지 보면
막연한 감이 아니라 정확한 개선 포인트를 찾을 수 있다.

오늘 배운 포인트는 크게 4가지였다.

• 목표 정의
• 단계 정의
• 이탈률 확인
• 개선 액션 도출

결국 퍼널은
“왜 구매가 안 나오지?”를 고민하는 게 아니라
“어느 단계에서 구매가 막히는지”를 구체적으로 보는 도구였다.

---

3) AARRR로 서비스 성장 흐름 이해하기

퍼널이 특정 행동 흐름을 보는 거라면,
AARRR은 서비스 전체 성장 구조를 보는 느낌이었다.

오늘 다시 정리된 개념은:

• Acquisition: 어떻게 들어왔는가
• Activation: 첫 경험이 좋았는가
• Retention: 다시 돌아오는가
• Revenue: 돈을 쓰는가
• Referral: 다른 사람에게 추천하는가

특히 PM 입장에서 중요한 건
각 단계를 단순 정의로 외우는 게 아니라
우리 서비스 행동 이벤트에 맞게 재해석하는 것이었다.

예를 들어 배달앱이라면

• 유입 = 앱 설치 / 회원가입
• 활성화 = 첫 주문
• 유지 = 주 1회 재주문
• 수익 = 결제 완료
• 추천 = 친구 초대

이렇게 서비스 맥락으로 바뀌는 게 실무 포인트였다.

---

4) 킥오프와 회고: PM의 커뮤니케이션 설계

오늘은 데이터뿐 아니라 PM의 회의 설계 방식도 배웠다.

킥오프에서 중요한 건 단순 시작 선언이 아니라

• 왜 하는지
• 목표가 뭔지
• 일정은 어떻게 가는지
• 누가 뭘 하는지
• KPI는 무엇인지

를 한 번에 맞추는 것이다.

반대로 회고에서는
결과보다 과정에서 무엇을 Keep / Problem / Try 할지 정리하는 습관이 중요했다.

---

5) PM 기본 역량: 결국 우선순위가 핵심

마지막으로 가장 PM다운 파트는 우선순위 판단 케이스였다.

특히 기억에 남은 건

앱 크래시 100% vs 결제 불가

상황에서 무엇을 먼저 해결할지였다.

처음엔 결제 불가가 더 매출에 직접적이라고 생각했는데,
앱이 아예 안 켜지면 결제 이전 단계 자체가 막히기 때문에
결국 전 사용자 영향도가 더 큰 앱 크래시가 최우선이었다.

오늘 여기서 PM 사고방식이 확실히 느껴졌다.

문제를 볼 때 단순히 심각해 보이는 게 아니라

• 영향 범위
• 매출 영향
• 복구 시급성
• 사용자 경험 단절 수준

으로 나눠 보는 방식이 실무적이었다.

---

3. 과제 회고 및 피드백 요약

1. 개인 회고

이번 과제를 다시 돌아보며 가장 크게 느낀 점은,
보는 사람의 이해 흐름보다 내가 이미 내린 결론을 빠르게 증명하려는 방식으로 문서를 작성했다는 점이다.

리뷰 데이터를 정량적으로 분류하고 리텐션 관점으로 문제를 재정의한 시도 자체는 의미 있었지만,
가설을 빠르게 도출하고 싶은 마음에 일부 데이터와 논리 단계를 충분히 설명하지 못한 채 스킵해버렸다.

특히 문제 정의에서 해결 가설로 넘어가는 과정에서
“왜 이 범위를 좁혔는가”, “왜 이 문제를 핵심으로 선택했는가”에 대한 설명이 부족해
읽는 사람 입장에서는 흐름이 끊길 수 있다는 점을 크게 배웠다.

이번 과제를 통해
좋은 PM 문서는 정답을 빨리 내는 것이 아니라, 상대가 납득할 수 있도록 사고의 과정을 끝까지 보여주는 것이라는 점을 체감했다.

---

2. 핵심 피드백 요약

① 데스크 리서치 보완 필요

• 리뷰 데이터만 보지 말고 실제 UI/UX를 직접 사용하며 데스크 리서치를 해야 함
• 서비스 구조, 정보 흐름, 홈 화면 전략을 함께 봐야 문제 원인을 더 정확히 파악 가능
• 실제 화면을 보면 기능 부족인지 구조 문제인지 구분이 쉬워짐

배운 점

VOC는 현상, 데스크 리서치는 원인을 설명하는 근거다

---

② 분석 범위는 단계별로 점진적으로 좁혀야 함

이번 과제의 가장 큰 구조적 피드백.

• 초반엔 5개 카테고리 전체 분석
• 중간엔 특정 카테고리만 분석
• 후반엔 다시 다른 항목 추가

처럼 범위가 흔들려 논리 흐름이 끊겼다.

 

개선 방향

전체 → 상위 문제군 → 핵심 문제 1개
처럼 순차적으로 좁혀지는 구조를 유지해야 함

배운 점

문서의 논리는 결론보다 범위를 줄여가는 과정에서 설득력이 생긴다

---

③ 문제 현상과 문제 원인을 구분해야 함

예:

• “추천 정확도가 낮다” = 현상
• “최근 행동 데이터 반영이 부족하다” = 원인

피드백 핵심은
사용자 관점의 불편을 적는 것에서 끝나지 말고, 운영자/서비스 구조 관점에서 왜 그런 문제가 발생했는지 근본 원인을 찾아야 한다는 점이었다.

---

④ 우선순위는 숫자 + 전략 + 비용 근거가 있어야 함

Impact/Effort를 단순 감으로 두면 안 되고 아래 3가지를 모두 고려해야 함.

 

Impact

• 리뷰 비중
• 리텐션 영향
• 비즈니스 KPI 연결성

Effort

• 개발 리소스
• 디자이너 투입
• 데이터 연동 비용
• QA 범위
• 시간 비용

전략 적합성

특히 이번에 중요한 피드백:

기업의 전략 방향을 무시하면 안 된다

예: 네이버가 가격비교를 약하게 가져가는 이유

• 외부 최저가 사이트 이탈 방지
• 플랫폼 내 브랜드 입점 확대 전략

즉 가격 비교는 불편하더라도
기업 전략상 우선순위에서 제외될 수 있다는 논리적 설명이 필요했다.

배운 점

좋은 우선순위는 사용자 문제 + 비즈니스 전략 + 현실 비용의 교집합이다

---

⑤ GPT 도움을 받더라도 스스로 검증 가능해야 함

 

AI의 도움으로 구조를 빠르게 잡을 수는 있지만,
최종적으로는 내가 왜 그렇게 분석했는지 논리적으로 직접 설명할 수 있어야 PM 문서가 된다는 피드백이 가장 크게 와닿았다.

배운 점

AI는 사고를 대신하는 도구가 아니라, 내 사고를 검증하는 보조 장치다

---

3. 다음 과제 액션 플랜

다음 과제에서는 아래 4가지를 꼭 적용해 보자.

1. UI 직접 사용 후 데스크 리서치 먼저 진행
2. 모든 단계에서 같은 범위를 유지하고 점진적으로 축소
3. 문제 현상 → 운영 구조 원인까지 5 Whys
4. 우선순위에 전략 적합성과 총 effort 근거 포함