📌 한 줄로 요약하기
: MVP 프로젝트 이전에 해야하는 작업 목록에 대한 인사이트를 많이 얻었다!
💡 오늘의 인사이트
🧩 오늘 숙제에서 배운 것
요약
- 데이터 시각화는 보기 좋게 그리는 작업이 아니라, 어떤 질문에 답하려는지 먼저 정의한 뒤 그에 맞는 축과 지표를 선택하는 과정임을 학습하였다.
- 단일 지표로는 인사이트 도출이 어려운 경우가 많으며, 원인과 결과를 함께 보기 위해 복합 차트가 효과적일 수 있음을 이해하였다.
- 그래프의 X축과 Y축 배치는 임의가 아니라, 원인과 결과의 관계를 명확히 전달하기 위한 구조적 선택임을 인식하였다.
- 데이터 분석 설계에서 가장 중요한 것은 수치 자체보다도 모수 확보와 비교 기준을 먼저 세우는 것임을 배웠다.
- 정량 데이터만으로는 판단이 불완전하며, 설문·VOC·UT 등 정성 데이터를 함께 설계해야 원인을 설명할 수 있음을 이해하였다.
사고 정리
1. 데이터를 그리기 전에 “이 그래프로 무엇에 답하려는가”를 먼저 정의하지 않으면 시각화는 설명력이 떨어진다는 것을 체감하였다.
2. 체류시간·클릭·전환처럼 결과 지표만 보면 해석이 막히며, 반드시 원인이 될 수 있는 지표를 함께 배치해야 사고 흐름이 보인다는 점을 깨달았다.
3. X축과 Y축을 잡는 과정이 단순한 디자인 문제가 아니라, 내가 문제를 어떻게 구조화하고 있는지를 드러내는 사고의 문제임을 인식하였다.
4. 데이터 분석에서는 결론을 빨리 내리려 하기보다, 비교 가능한 모수와 기준을 먼저 설계하는 것이 오히려 판단 속도를 높인다는 것을 느꼈다.
5. “왜 이 데이터가 필요한가?”를 설명하기 어려웠던 이유가 결과 중심으로 사고했기 때문임을 깨달았고, 앞으로는 중간 과정과 외부 변수를 먼저 설계하려 한다.
🧠 아티클 스터디
요약:인스타 스토리 PM이 소셜앱의 본질을 말하다
이 아티클은 PM을 단순히 기능을 관리하는 사람이 아니라, 무엇을 왜 만들어야 하는지를 끝까지 책임지는 ‘영화 감독’에 비유한다. 인스타그램 스토리와 Retro의 사례를 통해, 제품의 성공은 더 많은 사용자를 모으는 데서 끝나지 않고, 사람들이 부담 없이 공유하고 관계를 지속할 수 있는 구조를 설계하는 데서 시작된다는 점을 보여준다. 특히 네이선은 소셜앱의 본질을 엔터테인먼트가 아닌 사람 간의 연결과 시간이 지나도 남는 경험으로 정의하며, PM은 지표나 기능 이전에 “이 제품이 어떤 가치를 만들고 있는가”를 먼저 질문해야 한다고 말한다. 결국 이 글은 제품 이야기처럼 보이지만, 실제로는 지금 내 인생에서 무엇을 중요하게 두고 선택하고 있는가를 되묻게 만드는 글이었다.
관점 전환
1. 소셜앱의 성공 기준에 대한 관점 전환
이전에는 소셜앱의 성공을 많은 사용자 수와 명확한 유료화 혜택으로 생각했다면, 이 아티클을 통해 소셜앱의 본질은 사람 간의 연결과, 휘발되더라도 기억으로 남는 경험을 만드는 데 있을 수 있겠다는 관점으로 바뀌었다. 스토리와 Retro는 모두 “완벽하지 않아도 공유할 수 있는 구조”를 통해 사람들이 다시 관계 안으로 들어오게 만든 사례였다.
2. PM의 역할에 대한 관점 전환
PM은 단순히 팀을 조율하거나 요구사항을 정리하는 역할이 아니라, 어떤 문제를 풀 것인지, 왜 지금 풀어야 하는지를 선언하는 사람이라는 점이 인상 깊었다. 특히 AI 시대에는 PM이 직접 손을 대는 범위보다, 어떤 일을 누구(사람 혹은 AI)에게 맡길지 판단하는 디렉터 역할이 더욱 중요해진다는 메시지가 크게 와닿았다.
3. 성장과 가치에 대한 관점 전환
이 아티클은 “지금 당장 잘되는 것”보다 오래 가는 것을 선택하는 태도를 일관되게 보여준다. 네이선은 성장 이전에 리텐션을, 매출 이전에 관계의 밀도를 먼저 본다. 이는 내가 필요로 하는 것에서 출발해, 사람들이 점점 잊고 있는 가치를 발견하고, 그들의 열망을 해소하는 것이 결국 지속 가능한 제품으로 이어진다는 관점으로 이어졌다.
"내가 진짜 만들고 싶었던 가치와 문제의식은 어디에 있었을까?"
🤔 오늘의 궁금한 점
질문: AARRR 기준으로 지표를 설계할 때, 각 지표가 어떤 화면·기능·메이커들의 작업으로 이어지는지 PM이 로드맵 관점에서 어디까지 정의하고 공유해야 하나요?
이유: 요즘 이전 과제들을 다시 살펴보면서, 어떻게 하면 더 전달력 있는 기획서가 될 수 있을지 튜터님들 피드백을 참고하고 있다. 그러다 보니 이 아티클이 특히 와닿았고, 이번 주 강의 주제가 데이터 드리븐이어서 더 연결해서 생각하게 되었다. AARRR 기준으로 지표를 나누는 것까지는 이해했지만, 각 지표가 실제로 어떤 화면이나 기능, 그리고 각 메이커들의 작업으로 어떻게 이어지는지까지는 아직 설계하기 위한 단계까지 이해하지 못하고 있는데, PM이 이야기하는 ‘이해관계자(메이커)들의 로드맵’을 지표 설계 단계에서도 함께 정의하고 공유하는 게 필요할까? 만약 필요하다면, 각 메이커에게 본인과 직접적으로 연관된 지표만 선별해서 공유하는 것이 좋은지, 아니면 각자의 관련 지표는 구분하되, 공통된 목표와 흐름은 함께 보여주는 방식이 더 좋을까?
튜터님 피드백: AARRR은 개념적으로는 유용하지만 지표 수가 방대해 실무에서 전부 다루기 어렵고, 실제로는 한 단계·한 지표만 선택해 쪼개서 다룬다. 전사 로드맵 관점에서 0→1로 방향을 정의하는 역할은 주로 그로스 PM이 담당하며, 주니어 PM은 전체 퍼널 설계보다는 특정 지표 단위의 실행과 개선에 집중한다.
팀원 질문 1: 디자이너·개발자와 협업하며 가장 힘들었던 지점과 해결 방식은 무엇이었나요?
튜터님 피드백: 개발자 협업에서는 “왜 이 프로젝트를 하는지”에 대한 당위성만 명확히 전달해도 대부분의 문제는 해결된다. 디자이너와의 갈등은 리뷰 범위(아레나)를 명확히 나누고, 개인 의견이 아닌 레퍼런스와 근거로 이야기하는 것이 중요하다. 해결이 어려울 경우에는 팀장에게 도움을 요청하되, 슬랙·노션 등 증거를 정리해 공적인 맥락으로 공유하는 것이 필요하다.
팀원 질문 2: PM이 개발 파트 간 조율이나 콘텐츠 팀 일정까지 관리해야 하나요?
튜터님 피드백: 개발자 간 갈등은 직접 중재하기보다 커뮤니케이션을 정리하고 필요 시 팀장에게 연결하는 역할에 가깝다. 개발 파트 조율은 주로 공수와 일정 분배 중심으로 이루어지며, 장기 일정에서 더 많이 발생한다. 콘텐츠가 필요한 신규 서비스의 경우, 콘텐츠 제작 일정은 반드시 개발 일정과 함께 고려해야 하며, 마케팅·재무 등 출시 이후 임팩트 관련 재무 부서와의 싱크도 중요하다.
🎯 이번주 액션
- 월요일 : 완강 목표 + 강의의 숙제
및 피드백 신청 - 화요일 : 복습 겸 숙제 + 이전 과제들 피드백 다시 보기
- 수요일 : 과제 발제 듣기 + 발제문 분석 + 과제 시작
📂 개인 과제
[Chapter.5-1] 데이터 드리븐 프로덕트 기획 주차
데이터 드리븐 기획에 필요한 역량들을 총정리하며 마무리 하는 과정
💻 수강 과정
| 일시 | 작업 | 느낀 점 |
|---|---|---|
| 01/30 | 3강까지 수강 | 궁금할 때, 만약 그게 현업에서의 사례가 필요하다면 꼭 튜터님께 물어보자! |
| 02/02 | 완강하기 | 끝의 용어 관련은 대부분 아는 거라서, 튜터님의 인생 이야기가 더 기억남.. |
| 02/02 | 관련 아티클 선정 및 읽기 | 내가 낸 개인 과제가 얼마나 연계성이 없는지 알게 되었다.. |
| 02/02 | 강의 관련 숙제하기 | 지난번 한 화면설계 관련에 대하여 피드백 신청해서 숙제 실행까지만 OK |
| 02/03 | 강의 관련 숙제하기 | 그래프 너무 어렵다, 수포자라서? 케이스 분석은 쉬웠지만 설명이 어려움 |
| 02/04 | 과제 발제 확인하기 | OOO |
🚧 과제를 위한 이전 과제들 KPT
Keep
- 현재 만족하고 있는 부분 : 문제를 기능이 아니라 목표·철학·지표에서 정의하고, 개선안 → 가설 → 실험으로 이어지는 사고 흐름을 유지하고 있다는 점
- 계속 이어갔으면 하는 부분 : 감이 아니라 데이터와 가드레일 지표를 함께 고려하며 실험을 설계하려는 태도
Problem
- 불편하게 느끼는 부분 : 머릿속 논리는 충분한데 문서에서 설명이 축약되어, 읽는 사람이 중간 맥락을 추론해야 하는 구조가 반복됨
- 개선이 필요하다고 생각되는 부분
- 근거 자료가 말하는 사실과, 그로부터 도출한 가설이 문서상에서 명확히 구분되지 않음
Try
- Problem에 대한 해결책
- 모든 핵심 판단 뒤에 왜 → 무엇을 봤고 → 그래서 어떤 결론에 도달했는지를 1~2문장으로 연결해 서술하기
- (도전) 하나의 실험에서는 반드시 하나의 변수만 변경하도록 실험을 다시 설계해보고, 기존 과제를 단일 변수 실험 로드맵으로 재작성해보기
