오늘 한 것
오늘은 네이버플러스 스토어 PM 과제를 진행했다.
주요 작업은 앱 리뷰 57건을 분석하고, 이를 바탕으로 문제를 정의한 뒤 가설을 수립하는 것이었다.
처음에는 리뷰를 카테고리별로 잘 나누는 것이 핵심이라고 생각했다. 하지만 작업을 하면서 더 중요한 것은 리뷰를 많이 분류하는 것이 아니라, 분류된 내용을 몇 개의 핵심 문제로 수렴시키는 과정이라는 것을 알게 되었다.
1. 리뷰 분석은 “분류”가 아니라 “수렴”이다
리뷰 57건을 10개 카테고리로 나누는 것은 시작일 뿐이었다.
진짜 중요한 것은 그 10개의 카테고리를 다시 2~3개의 문제 축으로 좁히는 과정이었다.
이때 필요한 것은 단순히 리뷰 건수가 많은 순서로 정렬하는 것이 아니라, 문제의 성격이 같은 것끼리 묶는 기준이었다.
예를 들어 서로 다른 표현의 리뷰라도 결국 같은 문제를 말하고 있다면 하나의 문제 축으로 묶을 수 있다. 반대로 같은 카테고리처럼 보여도 원인이 다르면 분리해야 한다.
오늘 배운 것은 리뷰 분석에서 중요한 질문이 다음이라는 점이다.
왜 이것들은 같은 문제로 묶을 수 있는가?
왜 이것은 제외하거나 다른 축으로 봐야 하는가?
즉 리뷰 분석은 단순 분류가 아니라, 사용자 불만을 해석해 핵심 문제로 수렴시키는 작업이다.
2. “기능 부재”와 “전달 실패”는 완전히 다른 문제다
리뷰를 보면서 특히 중요하게 느낀 것은, 같은 기능에 대해 만족과 불만족이 동시에 존재할 수 있다는 점이었다.
이 경우 기능 자체가 반드시 나쁜 것은 아닐 수 있다.
문제는 사용자가 그 기능을 발견하고, 이해하고, 활용하는 과정에서 차이가 생긴 것일 수 있다.
예를 들어 어떤 사용자는 혜택을 잘 활용해 만족하지만, 다른 사용자는 같은 혜택을 알아보지 못해 불만을 느낀다. 이때 문제를 “혜택 기능이 부족하다”로 정의하면 해결안이 완전히 달라진다.
하지만 실제 문제는 기능 부재가 아니라 전달 실패일 수 있다.
이 구분이 문제 정의의 날카로움을 결정한다.
3. 전략적 의도와 사용자 불만이 충돌할 때, PM은 대체 가치를 설계해야 한다
네이버플러스 스토어 과제를 하면서 흥미로웠던 지점은, 기업의 전략적 의도와 사용자 불만이 충돌할 수 있다는 점이었다.
예를 들어 네이버가 가격비교 기능을 의도적으로 약화하거나 제외했다면, 사용자의 “가격 비교가 불편하다”는 불만을 그대로 받아들여 단순히 기능을 복원하자고 말하기는 어렵다.
이때 PM은 “사용자가 불편하다고 했으니 기능을 다시 넣자”에서 멈추면 안 된다.
대신 이렇게 질문해야 한다.
기업이 가격비교를 줄이려는 전략적 이유가 있다면, 사용자가 구매를 결정할 수 있는 다른 근거는 무엇인가?
가격비교가 약해진다면, 사용자가 앱 안에서 구매를 결정할 수 있는 근거는 혜택, 멤버십, 적립, 배송, 신뢰 같은 대체 가치가 되어야 한다.
그런데 그 대체 가치가 충분히 전달되지 않는다면, 사용자는 “굳이 이 앱에서 살 이유”를 느끼지 못한다.
즉 이 문제는 단순히 가격비교 기능의 부재가 아니라, 가격비교를 대체할 구매 이유가 충분히 전달되지 않는 문제로 볼 수 있다.
이 연결이 PM다운 사고라고 느꼈다.
4. 문서 안에서 데이터 분석과 문제 정의의 역할을 분리해야 한다
오늘 문서를 작성하면서 가장 헷갈렸던 부분은 데이터 분석과 문제 정의를 구분하는 것이었다.
데이터 분석 파트에서는 리뷰에서 보이는 사실만 말해야 한다.
이런 불만이 반복적으로 나타났다.
이런 카테고리의 리뷰가 많았다.
이런 표현이 자주 등장했다.
반면 문제 정의 파트에서는 그 사실을 바탕으로 왜 이런 문제가 생겼는지 해석해야 한다.
이 문제는 단순 기능 부족이 아니라, 사용자가 앱의 핵심 가치를 이해하지 못한 데서 발생한다.
기업의 전략적 방향과 사용자 기대 사이에 간극이 있다.
개인 의견이나 앱을 직접 써본 감상은 문서에 바로 쓰기보다, 리뷰를 더 정확하게 해석하기 위한 보조 도구로 활용해야 한다.
이 구분을 지키지 않으면 문서는 리뷰 기반 분석이 아니라, 내 감상문처럼 보일 수 있다.
5. 5 Whys는 “왜 불편한가”가 아니라 “왜 반복되는가”를 묻는 도구다
처음에는 5 Whys를 단순히 “왜 불편하지?”를 여러 번 묻는 도구로 생각했다.
하지만 오늘 느낀 것은 조금 달랐다.
표면적인 불만에서 멈추면 해결안은 쉽게 “UI를 고치자”로 끝난다.
하지만 같은 불만이 반복된다면, 그 아래에는 더 구조적인 원인이 있을 수 있다.
예를 들어 사용자가 혜택을 잘 이해하지 못한다는 문제가 반복된다면, 단순히 문구 하나를 고치는 문제일 수도 있지만, 더 깊게는 서비스가 사업 단위 기준으로 설계되어 사용자 관점에서는 통합된 가치로 보이지 않는 문제일 수도 있다.
즉 5 Whys는 “왜 불편한가”를 넘어서, 왜 이 문제가 반복되는가를 묻는 도구다.
이 질문까지 내려갔을 때 PM다운 문제 정의가 가능해진다.
- PM 문서는 이력서와 비슷하다
오늘 문서를 고치면서 PM 문서는 이력서와 비슷하다고 느꼈다.
이력서에서 “열심히 했습니다”가 설득력이 없듯이, PM 문서에서도 “사용자가 불편합니다”만으로는 충분하지 않다.
읽는 사람이 빠르게 납득할 수 있도록 구조화해서 전달해야 한다.
좋은 문서는 다음 흐름을 가진다.
어떤 상황에서
무엇을 발견했고
그 발견을 어떻게 해석했으며
그래서 어떤 판단을 내렸는가
즉 PM 문서는 내 고민의 양을 보여주는 문서가 아니라, 내 판단의 흐름을 이해시키는 문서여야 한다.
- 가설은 기능 제안이 아니다
오늘 가장 많이 헷갈렸던 것 중 하나는 가설과 해결안을 구분하는 것이었다.
예를 들어 “필터를 개선한다”는 말은 가설이 아니라 해결책이다.
가설은 원인 분석과 연결되어야 한다.
가설은 이런 구조에 가까워야 한다.
만약 A를 개선하면, B 지표가 좋아질 것이다.
왜냐하면 현재 문제의 원인이 C에 있기 때문이다.
즉 가설은 “무엇을 만들겠다”가 아니라, 어떤 원인을 바꾸면 어떤 행동 변화가 일어날 것인가에 대한 문장이다.
이 구분을 해야 해결안도 더 논리적으로 이어질 수 있다.
⸻
PM으로서 사고방식
요즘 개발자에서 PM으로 사고방식을 전환하는 중이다.
개발자는 보통 앞에서 뒤로 생각한다.
요구사항 → 설계 → 구현 → 테스트
하지만 PM은 때로 뒤에서 앞으로 생각해야 한다.
이 문서를 읽은 사람이 무엇을 느껴야 하지?
그걸 느끼게 하려면 어떤 논리가 필요하지?
그 논리를 만들려면 어떤 분석이 필요하지?
그 분석을 하려면 지금 무엇부터 해야 하지?
이번 과제로 치면, 멘토가 내 문서를 읽고 이렇게 느끼는 것이 목표였다.
이 사람은 데이터를 보고 문제를 논리적으로 좁혀나갈 줄 아는 사람이구나.
그렇다면 역으로 문서에는 다음이 있어야 한다.
- 데이터를 단순 나열하지 않고 문제 축으로 수렴시킨 흔적
- 왜 이 페르소나를 선택했는지에 대한 기준
- 기능 부재와 전달 실패를 구분한 문제 정의
- 기업 전략과 사용자 불만을 함께 고려한 판단
- 해결안이 아니라 가설로 먼저 설명하는 논리 구조
이렇게 생각하니, PM 문서는 단순히 과제 제출물이 아니라 내 사고방식을 보여주는 결과물이라는 생각이 들었다.
