IT 서비스 기획/PM, PO, 기획자

[PM/PO/기획자] 2년차 PM의 하루 분석

필문(PM) 2025. 2. 20. 09:00
반응형

RPE-VIEW

오늘의 아티클은 '2년차 PM의 하루'입니다. PM의 하루 일정을 분석하며 어떤 역할을 수행하는 지 알아보겠습니다.

 

아티클 소개

2년차 PM의 하루

 

2년차 PM의 하루

다이내믹하고 옹골차게 흘러가는 8시 | 01. PM은 어떤 일을 하나요? 지인들에게 명함을 드릴 때면 "PM은 어떤 일을 해?"라는 질문을 종종 받았습니다. 직무명 자체가 생소한 것일 수도 있고 업계나

brunch.co.kr

 

저자 정보

저자: 이성긍

이성긍의 브런치스토리

 

이성긍의 브런치스토리

기획자 | 강남언니 팀의 Product Owner로 몸과 마음이 건강한 직업인을 목표 삼아 정진하고 있습니다. GOGO LET’S GO

brunch.co.kr

 

 

핵심 내용 요약

중요 포인트

1. PM이 하는 일

- PM의 역할 범위는 업계나 회사 마다 매우 다르다. PO, Project Manager 등 비슷하지만 다른 직무도 존재한다. 그래서 PM의 일과를 바탕으로 주로 어떤 일을 하는 지를 알아보려 한다.

 

2. 오전 시간

- 오전 8시에 출근하여 프로젝트 현황을 파악하고 업무 요청에 필요한 자료를 미리 준비한다. 협업 요청이 잦은 직무 특성 상, 오전에 집중해서 자료를 파악할 수 있는 것이 업무 효율성 향상에 도움이 된다.

 

1) 데일리 타임테이블 짜기

- 구글 캘린더, 태스크 관리보드를 참고해 오늘의 미팅, QA, 배포 일정 등을 확인한다. 프로젝트 문서에 접속해 프로젝트 진행을 위한 태스크별 현황을 확인하고, 관리가 필요한 회색지대를 체크한다.

- 저자는 업무를 소통이 중요한 협업과 집중이 필요한 기획으로 나누고 모두가 출근이 가능한 코어 시간대를 기준으로 집중력이 전환될 수 있도록 하루 계획을 세운다고 한다.

 

2) 배포건 현황 분석하기

- 지난 주에 배포한 기능, 실험 데이터를 확인하고 분석함. Hackle에 접속해 AB test의 p-value 추이가 어떤지 살펴보며 최소 실험 기간 수정이 필요한지를 판단하기도 한다. 아침마다 루틴으로 현황 분석을 하는 주 목적은 배포건의 임팩트를 촘촘하게 체크하는 것이지만, 로깅 오류나 가드레일 지표의 약화 등 위험 신호를 찾아내 조기에 기능 수정 요청을 하기도 한다.

 

3) 기획서 작성하기

- 기획서는 정책 문서와 제작 요청 문서로 나뉜다. 업무 단위가 '태스크'인 경우에는 제작요청 문서부터 작성하지만 새로운 기능 도입이나 '프로젝트' 단위 업무인 경우에는 정책 문서 작성에 비중을 둔다. 관련하여 유관 부서에 슬랙으로 질문을 하기도 한다. 

- 제작 요청 문서 중 디자인 요청 문서의 경우 기획 의도를 핵심만 작성하고 기획 배경 참고자료를 첨부한다. 디자인에 대한 '제안'을 작성하되 디자이너의 주도적인 결정/조언이 필요한 부분을 언급한다. 프로덕트 디자이너의 경우 디자인의 시각적인 기능 뿐만 아니라 제품 내에서 고객 경험에 기여하는 부분까지 총괄적으로 설계를 하기 때문에, 기획서 완성 전에 조언을 구하는 것이 협업에 도움이 된다. 그래서 문서는 간결하되 구두로 논의를 더 한다.

- 개발 요청 문서의 경우 백엔드, 프론트엔드, 로그, 실험 세트로 구성된 요청 문서를 작성한다. 플로우 차트 등을 첨부하기도 한다. 기획서 작성 중 여러 유관 부서 협의나 인지가 필요한 부분이 발견되면 구글 캘린더를 보고 기획서 공유 미팅 일정을 잡는다.

 

4) 실험 세팅하기

- 스프린트 단위가 짧은 경우 단기간에 많은 건들이 배포된다. 대부분의 배포건에 대해 모두 AB test를 진행하고 실험 가설에 맞춰 Hackle에서 실험 설명 문구 작성, 지표를 선정한다. 엔지니어가 실험 세트를 연결할 수 있도록 실험 Key를 전달하고, 피드백이 필요한 경우 Business Analyst에게 실험 링크를 사전에 공유한다.

 

3. 오후 시간

1) 주간 회고 미팅

- 보통 스쿼드 단위로 구체적인 액션을 결정하되, 제품 전체의 전략에 대해 논의할 때는 스쿼드 간 지식/의견 공유가 가능하도록 스쿼드별 PM끼지 모여 미팅을 한다. 지난 액션의 영향력을 파악해 러닝을 쌓고, 그 러닝을 어떻게 확장 적용해나갈 것인지 논의하는 시간을 가진다. 

 

2) QA 및 배포 공유

- 개발이 완료면 엔지니어가 QA 요청 채널에 슬랙을 준다. 기확서를 작성하며 확인했던 Critical Path를 중심으로 Test Case 별 QA를 진행한다. 제작한 기능의 오류 여부나 의도했던 바가 구현되는지 확인하는 과정이다.

 

3) 밍글링

- 리더라면 틀린 방향이더라도 모두 한 방향을 보고 집중해서 달릴 수 있게 도와야 한다고 믿는 편입니다. 실패할 수도 있지만, 러닝이 쌓일 수 있게 모두를 합심시키도록 노력하는게 더 의미 있는 노력이라고 생각한다.

반응형