⭐ 인사이트 + 생각 정리 (QNA)

🔔 데이터와 지표

구분	한 줄 정의
데이터	의미 없는 사실 정보
지표	판단을 위한 요약된 수치
로그	사용자·시스템 행동 기록
분석 목적	문제 발견 → 개선

PM의 역할은 모든 데이터를 보는 것이 아니라,
의사결정에 필요한 지표를 정의하는 것이다.

🔹 PM 관점 포인트

• 감이 아니라 근거로 말하기
• “왜 이 데이터를 봐야 하는가?”를 먼저 정의

🔔 구글 애널리틱스(GA)

질문	GA에서 보는 것
얼마나 왔나	사용자 수, 세션
무엇을 했나	이벤트
어디서 나갔나	이탈, 전환
어떤 페이지가 문제인가	페이지/방문 페이지

🔹 PM 관점 포인트

• 숫자 자체보다 “이탈이 많은 지점”에 주목
• UX 문제는 대부분 결제·가입 직전에 숨어 있음

🔔 리디북스 사례

: “데이터로 어떻게 결정했는가”
모든 사용자에게 기능을 바로 적용하지 않고, 효과가 클 가능성이 높은 그룹부터 실험했다.
노출 위치·대상·KPI를 먼저 정의하고, 지표로 성공 여부를 판단했다.
🔹 PM 관점 포인트

• “좋은 기능”보다 “검증 가능한 기능”
• 데이터는 결정 이후를 설명하는 도구가 아니라, 결정 이전의 기준

🔁 3강 통합 한 줄 구조
데이터=재료 → 지표=기준 → GA=관찰 도구 → 사례=PM의 결정 방식

💡 내 생각의 확장 QNA

“지금 내가 만들고 싶은 기능의 성공을 한 줄 지표로 말할 수 있는가?”

• 음, 우당탕 기획서 기준으로 말하자면 "얼마나 많은 사람들이 이것을 사용하는가 = 이벤트, 리텐션"이 될 것 같습니다.

“이 지표가 좋아졌을 때, 정말 사용자 경험도 좋아졌다고 말할 수 있을까?”

• 사용자가 반복하여 사용했다는 점에서 학습 기능에 대한 인증이 될 것이라 생각합니다.

🔔 시작-공유-회고

🔹 킥오프 (Kick-off)
프로젝트의 공식적인 출발 선언이자 정렬의 순간 → 혼란을 미리 제거하는 장치

핵심 요소	초압축 의미
목표	무엇을 성공이라 부를 것인가
범위	할 일 / 하지 않을 일
일정	언제까지 무엇을 할 것인가
역할	누가 무엇을 책임지는가
커뮤니케이션	어떻게 공유하고 결정하는가
리스크	무엇이 문제 될 수 있는가
기대	이해관계자가 원하는 결과

🔹 공유 (Share)
정보 전달이 아니라 정렬을 위한 행위 → 공유가 잘 되면 문제는 빨리 드러나고, 결정은 빨라진다.

관점	초압축 요지
왜 중요한가	리스크 조기 발견
무엇을 공유하나	의사결정에 필요한 정보
어떻게 공유하나	채널·주기·대상 명확화
주의점	모든 정보 ≠ 좋은 공유

🔹 회고 (Retrospective)
결과 평가가 아니라 다음 프로젝트를 위한 학습 → 실수를 재사용하지 않기 위한 장치

단계	핵심 질문
돌아보기	무엇이 잘 / 안 되었나
원인 분석	왜 그런 결과가 나왔나
개선 도출	다음엔 무엇을 바꿀 것인가
공유	배운 것을 팀의 자산으로

💡 내 생각의 확장 QNA

“킥오프에서 정리하지 않으면, 프로젝트 중반에 가장 많이 흔들리는 요소는 무엇일까?”

• 오늘 읽은 지표 관련에서 북극성 지표라는 것이 나왔는데, 북극성이라는 것은 옛날에도 지금에도 결국 '누군가를 이끄는 것'쯤으로 해석이 된다고 생각합니다. 킥오프는 일종의 북극성을 청사진에 찍어두는 것이라고 생각하고 이를 하지 않으면 수많은 사공이 있을 수 밖에 없는 애자일 프로덕트에서는 산으로 가려다가 잠수함을 만드는 경우가 생길거라 생각하니다.

“공유와 회고가 형식적으로만 운영될 때, 팀의 의사결정은 어떻게 왜곡될까?”

• 누군가 어디까지 무엇을 어떻게 했는지 정확한 파악이 어려울거라 봅니다. 이 질문 듣고 생각난 짤이 하나가 있는데, 대답을 대신 할 것 같습니다 :)