: 0으로 끝나는 디데이는 항상 막연함과 설레임을 함께 준다.
2년차 PM의 하루
읽은 이유
튜터님이 자신의 하루를 기록한 글과 비슷한 결이라고 말씀해주셔서 참고 차원에서 읽어보게 되었다. 단순 직무 설명이 아니라 실제 하루 업무 흐름을 통해 PM의 역할을 입체적으로 이해해보고 싶다는 목적도 있었다.
요약
글 속 PM의 하루는 오전과 오후의 성격이 분명히 구분되어 있었다. 오전은 미팅·QA·배포 일정을 정리하고 실험 데이터를 점검하며 기획서와 요청 문서를 준비하는 등 팀원들이 작업을 시작할 수 있도록 기반을 마련하는 ‘세팅’ 시간에 가까웠다. 반면 오후는 주간 회고, QA, 배포 공유, 유관 부서 커뮤니케이션이 중심이 되는 ‘운영·조율·공유’ 시간으로 보였다.
이를 통해 PM은 기획 문서 작성에 국한되지 않고 일정·태스크 관리, 데이터 분석과 실험 설계, 협업 조율, QA 및 배포 의사결정까지 관여하는 역할이라는 점을 다시 인식하게 되었다. 실행은 실무자가 담당하더라도 방향 설정과 검증 설계는 PM이 주도한다는 구조가 인상 깊었다.
나의 경험과 느낀점
1. 경험
일정 관리와 타임라인 설계 경험은 어린이집 교사 시절부터 반복적으로 수행해왔다. 수업, 행사, 돌봄 시간을 기본 축으로 두되 아이들 컨디션이나 날씨 변수까지 고려해야 했기 때문에 상황 대응형 일정 관리에 가까웠다. 부트캠프에서는 팀장을 맡으며 발표 일정과 과제 마감일을 역산하고 팀원 가능 시간을 취합해 작업 타임라인을 설계했다.
기획 문서 작성 경험도 과제를 거치며 변화하고 있다. 정성 데이터 과제에서는 유저 후기를 카테고리화해 플랫폼 핵심 가치를 위반하는 지점을 도출했고, 이전 정량 데이터 과제에서는 서비스 이해 부족으로 문제 정의에 어려움을 겪었다. 그러나 이번 이북 플랫폼 과제에서는 서비스 경험을 기반으로 감각적 불편에서 출발해 데이터와 논문 근거로 확장할 수 있었다.
협업 요청 역시 어린이집과 부트캠프 팀장 경험 속에서 역할 분담, 일정, 요청 배경, 결과물 기준까지 함께 정리해 전달해왔다. 단순 전달이 아니라 작업 환경을 설계하는 조율에 가까웠다.
2. 느낀 점 및 관점 전환
읽기 전에는 PM을 방향성과 기획을 제공하는 조율자로 이해했지만, 실제로는 운영 전반을 관리하는 역할이라는 점을 체감했다. 특히 데이터와 실험 기반 기획 과정을 보며 이 직무가 생각보다 훨씬 분석적이라는 점을 다시 느꼈다.
또한 감각적 문제 인식은 탐색에는 도움이 되지만 데이터로 수렴되지 않으면 설득력이 약해질 수 있다는 점도 인식하게 되었다. 감과 데이터의 균형이 중요하다는 관점을 갖게 되었다.
협업 관점에서도 돌아보게 되었다. 나는 소통 과정에서 혼자 먼저 생각을 정리하고 앞서 나가는 경우가 있었는데, 글 속 PM처럼 타임라인을 자주 설정하고 중간 공유를 촘촘히 가져가는 방식이 팀 간 속도를 맞추는 데 도움이 될 것 같다고 느꼈다.
이는 오늘 남긴 궁금한 점 팀원과의 소통 속도를 어떻게 맞출 것인가 에 대한 하나의 힌트이기도 했다. 결과 공유가 아니라 과정 단위 소통 설계가 필요하다는 방향을 잡게 되었다. 또한 이번 과제 주차 동안 문제 정의 재설계와 타깃 재설정을 반복하며 기획은 수정 과정을 통해 정교해진다는 점도 함께 체감했다.
질문: 어떻게 하면 더 다른 팀원과의 소통을 원활하게 하고, 속도를 맞출 수 있을까?
튜터님 답변
X
핵심: X
[Chapter.5-1] 데이터 드리븐 프로덕트 기획 주차
데이터 드리븐 기획에 필요한 역량들을 총정리하며 마무리 하는 과정
| 일시 | 작업 | 느낀 점 |
|---|---|---|
| 02/12 | 우선순위 작성 | 이전에 사용했던 프레임워크가 부족하다. |
| 02/12 | 사실 조금 더 길게 작성하고 싶은데 그러니까 배운 것을 쏟아낼 뿐인 문장이 되더라.. | |
| 02/12 | 트렌드 작성 | 트렌드를 따라가지 않겠다고 제시하기 위해 작성하는데 생각보다 빨리 끝났다! |
| 02/12 | 퇴고 | 퇴고 기준은 오로지 피드백과 개인의 KPT 도전 과제만 설정해서 AI 도움을 받았다. |
| 02/12 | OX랑 상중하만 알려달라고 했었는데 1개 항목 빼고는 다 완료했다 ! |