: MVP 프로젝트 이전에 해야하는 작업 목록에 대한 인사이트를 많이 얻었다!
요약
사고 정리
1. 기능 명세서는 최대한 자세하게 써야하며, 어드민의 요구사항서가 될 수 있다.
2. 숏폼같은 단순한 화면에서도 PM이 여러명이 있을 때가 있으며 그래서 협업이 더 중요할 수 있다
3. 지난 주 웹개발때 동작을 잘 안하는 툴이 있어서 지인에게 도움을 요청할 때, 문제만 요청했다가 혼났었다.. 늘 '어떤 것을 기대하고 있는가?'를 먼저 적을 것!
4. 협업의 가장 중요한 것은 "애디튜드"이다!
요약
네 개의 아티클은 공통적으로 데이터를 ‘정답’이 아니라 문제를 구체화하고 가설의 범위를 좁히는 도구로 다루며, 지표 설계의 출발점은 수집 가능한 수치가 아니라 서비스 맥락과 사용자 행동이라는 점을 강조한다. 특히 AARRR와 같은 프레임은 지표를 분류하는 목적이 아니라, 각 단계에서 PM이 어떤 선택을 해야 하는지를 구조화하기 위한 사고 도구로 제시된다.
관점 전환
1. 지표를 정의하는 일은 분석 작업이 아니라, 어떤 문제를 풀 것인지에 대한 기획 행위로 인식하게 되었다.
2. 하나의 화면 변화는 단일 지표가 아니라 인접한 여러 단계의 지표에 연쇄적으로 영향을 준다는 관점이 필요하다고 느꼈다.
3. 데이터 분석의 완성은 수치 해석이 아니라, 그 결과가 실제 화면·기능·팀의 다음 행동으로 이어질 때라는 기준으로 보게 되었다.
질문: 유저 플로우 기준으로 정리한 내 분석 문서에서, 타인이 이해 가능하도록 하기 위해 반드시 풀어 써야 할 최소한의 형식·전제·설명은 무엇인지 ?
이유: 개인 과제에서 사고는 있으나 설명이 과도하게 축약돼 있다는 피드백을 반복적으로 받아, 이를 개선해 다음 개인 과제에 적용하기 위함이었다.
탐색 결과 : 튜터님께 슬랙으로 질문 후, ZEP을 통해 답변을 들었다.
1. 부모님이나 초등학생도 이해할 수 있는 정도의 글로 기획서 작성하기를 연습할 것
2. 책 추천 : 50년 하버드 글쓰기 비법
3. 전달자에게 맞는 도구, 범례를 설정하여 전달하자
[Chapter.5-1] 데이터 드리븐 프로덕트 기획 주차
데이터 드리븐 기획에 필요한 역량들을 총정리하며 마무리 하는 과정
| 일시 | 작업 | 느낀 점 |
|---|---|---|
| 01/30 | 3강까지 수강 | 궁금할 때, 만약 그게 현업에서의 사례가 필요하다면 꼭 튜터님께 물어보자! |
| 02/02 | 완강하기 | 끝의 용어 관련은 대부분 아는 거라서, 튜터님의 인생 이야기가 더 기억남.. |
| 02/02 | 관련 아티클 선정 및 읽기 | 내가 낸 개인 과제가 얼마나 연계성이 없는지 알게 되었다.. |
| 02/02 | 강의 관련 숙제하기 | 지난번 한 화면설계 관련에 대하여 피드백 신청해서 숙제 실행까지만 OK |
| 02/04 | 과제 발제 확인하기 | OOO |