오늘 배운 내용 중 가장 크게 남은 것은 PM의 설득은 감이나 주장으로 이루어지는 것이 아니라, 데이터와 검증 설계로 이루어진다는 점이다.
PM은 “이 기능이 필요합니다”라고 말하는 사람이 아니라,
왜 이 문제가 중요한지, 어떤 데이터로 확인했는지, 누구에게 먼저 적용해야 하는지, 어떤 지표로 성과를 판단할 것인지까지 설명할 수 있어야 한다.
즉 PM에게 중요한 질문은 다음과 같다.
누구에게 먼저 보여줄 것인가?
어디에 배치해야 효과가 클 것인가?
어떤 데이터로 성과를 검증할 것인가?
⸻
PM으로서 중요한 것은 단순히 좋은 의견을 내는 것이 아니라, 상대방을 어떻게 설득할 것인지, 그리고 그 설득을 어떤 데이터로 뒷받침할 것인지를 고민하는 것이다.
문제를 해결할 때도 직관에만 기대면 안 된다.
“이게 좋아 보인다”, “사용자가 원할 것 같다”는 생각만으로는 설득력이 약하다.
문제 해결은 다음 흐름을 따라야 한다.

이 흐름이 있어야 PM의 주장이 단순한 의견이 아니라, 설득 가능한 판단이 된다.
오늘 배운 데이터 분석 방법론 중 특히 기억에 남은 것은 퍼널 분석, AARRR 프레임워크, A/B 테스트였다.
퍼널 분석은 유저가 최종 목표에 도달하기까지의 여정을 단계별로 나누어 보는 방법이다.
예를 들어 결제를 목표로 한다면,
상품 상세 페이지 → 장바구니 → 결제 페이지 → 결제 완료
처럼 단계를 나누고, 어느 구간에서 유저가 가장 많이 이탈하는지 확인한다.
이를 통해 막연히 “전환율이 낮다”고 말하는 것이 아니라, 정확히 어느 단계가 병목인지를 찾을 수 있다.
⸻
AARRR은 유저 행동을 5단계로 나누어 프로덕트의 건강 상태를 보는 프레임워크다.

다만 중요한 것은 프레임워크를 그대로 가져다 쓰는 것이 아니다.
우리 서비스의 문제와 목표에 맞게 어떤 지표를 볼 것인지 정해야 한다.
즉 AARRR은 정답표가 아니라, 프로덕트를 구조적으로 이해하기 위한 도구다.
⸻
A/B 테스트는 두 가지 이상의 버전을 실제 유저에게 보여주고, 어떤 버전이 더 좋은 성과를 내는지 데이터로 검증하는 방법이다.
예를 들어 버튼 문구, 화면 배치, 추천 영역 노출 방식 등을 다르게 보여주고 클릭률이나 전환율을 비교할 수 있다.
이 방법의 핵심은 “내 생각에는 A가 더 좋아 보인다”가 아니라, 실제 유저 행동으로 검증한다는 점이다.
⸻
오늘 특히 인상 깊었던 것은, 기능을 구현했다고 해서 PM의 일이 끝나는 것이 아니라는 점이었다.
기능을 만들었다면 그다음에는 반드시 이런 질문을 해야 한다.
이 기능을 누구에게 먼저 보여줄 것인가?
화면 어디에 배치해야 가장 효과적인가?
어떤 지표로 성공 여부를 판단할 것인가?
예를 들어 리디북스의 AI 도서 추천 섹션 사례가 기억에 남았다.
리디북스는 AI 도서 추천 기능을 무작정 전면에 내세운 것이 아니라, 알고리즘 효과가 좋은 일반/만화 장르 독자를 우선 타깃으로 삼았다.
또한 첫 진입 경로라 트래픽은 높지만 구매 비중은 낮은 장르 홈 화면에 해당 기능을 배치했다.
즉 많은 유저가 들어오지만 구매로 이어지는 힘이 약한 지점에 추천 기능을 넣어 전환율을 높이려 한 것이다.
성과 측정도 세분화했다.

이 사례를 통해 기능 기획은 단순히 “무엇을 만들까?”에서 끝나지 않는다는 것을 배웠다.
PM은 기능의 대상, 위치, 검증 방식을 함께 설계해야 한다.
⸻
오늘 내용을 바탕으로 다시 정리하면, PM은 단순히 기능을 제안하는 사람이 아니다.
PM은 아래 질문에 답해야 하는 사람이다.

결국 PM은 사용자 문제를 정의하고, 데이터로 판단하며, 기능이 실제 성과로 이어지도록 설계하는 사람이다.
⸻
PM의 일은 기능을 만드는 것에서 끝나지 않는다.
누구에게, 어디에서, 어떤 지표로 검증할 것인지까지 설계해야 진짜 기획이 된다.
⸻
앞으로 과제나 프로젝트에서 기능을 제안할 때는 아래 질문을 반드시 함께 적어야겠다.