프로덕트 매니저는 무슨 일을 하고 있을까 - 독후감
때는 2023년 4월, 친구를 통해 친구네 회사의 선임 PM분을 만나서 대화를 나눌 수 있는 기회가 있었습니다.
선임 PM님께서 아래의 책을 선물로 주셨는데, PM으로 직무전환을 하고 성장을 해나가야 하는 제게 딱 맞는 책인 듯 싶었습니다.
독후감으로 책의 내용을 간략하게 기록하고 PM으로서의 길을 다져나가는 과정의 거름으로 삼고자 합니다 :)
책의 앞 부분에서는, PM으로서 본인이 어떤 능력치를 가지고 있는 지를 평가하도록 요구합니다.
PM 능력치 평가
아래의 평가 지표는 라비 메타라는 연구원이 만든 PM 측정 기준 표인데, PM의 12가지 능력치를 기준으로 자신이 어떤 형태를 한 PM인지를 평가할 수 있습니다.
해당 측정 지표에서 말하는 PM의 12가지 능력치는 아래와 같습니다.
- Fluency with Data (데이터 친화정도)
- Voice of the Customer (사용자 목소리에 귀를 기울이는지)
- User Experience Design (사용자 경험을 중시하는 디자인)
- Business Outcome Ownership (비즈니스 결과물에 대한 주인의식)
- Product Vision & Roadmapping (제품 비전 & 로드맵)
- Strategic Impact (전략적 영향력)
- Stakeholder Management (이해관계자 관리 능력)
- Team Leadership (팀 리더십)
- Managing Up (매니징)
- Feature Specification (제품의 기능 기술에 대하여)
- Product Delivery (제품 전달력)
- Quality Assurance (퀄리티 보장)
(정말 많네요 :) )
위의 그래프에 자신이 어느정도인지 스스로 평가해보면 어떤 유형의 PM인지 알 수 있습니다.
- 우측의 요소들의 점수가 높은 경우: '제품 설계'를 잘하는 PM
- 좌측의 요소들이 점수가 높을 경우: '제품 구현'을 잘 하는 PM
- 아래 요소들의 점수가 높을 경우: '제품 리더'에 가까운 PM 유형
- 위의 요소들이 점수가 높을 경우 '제품 매니저'에 가까운 PM 유형이다.
저는 아래와 같은 형태가 그려졌습니다. 즉, 제품 매니저에 가까운 타입이네요. 점점 더 리더십을 길러나가야겠죠 ㅎㅎ 커뮤니케이션 자체가 부족하지만 누군가를 이끌어나가는 능력은 아직 보완이 많이 필요하다고 생각해요.
PM의 커뮤니케이션 능력
프로젝트 진행 시 유관부서와의 논의
구현 방향을 잡고 작업을 진행하고 있을 때 ,이를 번복하면 비용이 비싸지기 때문에 제반 사항에 대한 결정을 마치고 진행하는 것이 좋습니다. 그렇기 때문에 서비스 특성마다 추가되는 유관부서까지의 공유를 먼저 진행해야 합니다.
예를 들어, 커머스 PM이 주문 프로세스 관련하여 프로젝트를 진행할 경우 서비스운영팀과 사전 논의를 한 후, 의견이 합치되어야겠죠. 생각해보면 저도 처음에 PM으로 일하게 되었을 때 유관부서와의 논의를 사전에 진행하지 않아서 고객응대 시 문제를 겪었던 적이 있는 듯합니다.
개인적으로는 만약 본인이 이직을 하게되어 새로운 제품의 PM이 되었다면, 유관부서의 실무담당자분들이 PM의 동아줄 역할을 해주신 다고 생각해요. 특히 히스토리가 잘 기록되어 있지 않은 기업일 수록...:)
요구사항 정의서(PRD)
요구사항 정의서(PRD) 작성팁
아래의 사항들은 이 책에서 말해준 요구사항 정의서를 작성할 때 포함하면 좋을 내용들입니다.
- 시각적인 보조수단을 적극 활용할 것 (ex. 다이어그램, 플로우 차트, 표)
- 설명하고자 하는 순서대로 문서를 작성할 것
- 1) 설명하고자 하는 내용과 2) 상세한 설명을 구분하여 제공할 것
- 문서 목차와 문서 변경 이력을 함께 제공할 것
- 관련 참고 문서에 대한 링크를 모두 제공할 것
기획서 문서는 처음 읽는 사람의 인지의 흐름에 따라 작성하면 되는데, 상세 내용 보다 기능 또는 제품의 목적과 목표, 배경에 대해 설명한 후 가설을 적고, 가설 검증을 위해 어떤 기능을 만들지 과정을 생각하며 순서대로 작성하는 게 좋다고 설명합니다.
기획서를 업데이트할 때마다 이전의 문서와 구분할 수 있도록 파일명에 버전명이나 업데이트일을 명시하여 버전 관리를 하는 것은 기본입니다. 그리고 문서 첫장에는 버전별로 어떤 내용이 변경되었는지, 변경된 부분은 문서의 몇 페이지에 해당하는지를 나열한 목록을 항상 첨부하도록 합니다.
요구사항 정의서(PRD) 구성요소
| 항목 | 상세 |
| 요약 | 개괄적인 내용을 파악(기획서의 압축본)하기 위함으로 두괄식으로 최대 5문장으로 요약하여 제공 |
| 업무 요청 체크 리스트 | 담당자 이름과 함께 요청할 문서를 문서 상단에 명확하게 작성 |
| 목표/목적 | 1. 무엇이 문제이고 그 문제가 왜 중요한지 (정량/정성적 데이터와 함께) 2. 문제를 해결함으로써 이루고 싶은 바와 그것을 이루었는지 여부를 확인할 수 있는 결과물 서술 |
| 주 사용자 | 주 사용자와 함께 이를 통해 구체적으로 어떤 가치를 얻을 수 있는지 → 사용자에게 가치를 전달하기 위함이기 때문에 사용자가 왜 중요한지와 사용자 단위의 목표로 한 이유가 포함되어야 함(왜 이 사용자 단위를 목표로 했는지도) |
| 주요 사용자 여정 | 요구사항이 정의하는 바에 따라 사용자에게 기능 또는 제품이 어떻게 제공되는지 서술 (사용자가 각 단계에서 느낄 수 있는 가치와 그 가치를 전달하기 위해 집중해야 하는 사항 또한 작성) |
| 기능 요구사항 | 어떤 사용자에게, 무엇을 제공하며, 목표를 달성할 수 있을지 |
| 시장 진입 전략 | 기능 또는 제품을 어떻게 타깃 사용자에게 도달하게 할 지에 대한 계획 → 서비스 내부에서 사용자 알림을 포함한 다양한 기술적인 방법 OR 유료 마케팅 툴을 활용한 홍보 |
| 지표 | 어떤 지표를 확인해야 이 기능 또는 제품의 성공 또는 실패를 판가름할 수 있는지 |
프로덕트 지표(Metric)
기능 또는 제품의 전반에서 활용하는 대표적인 지표로는 활성사용자 (Active users), 이탈률 (Churn rate), 고객생애가치 (Customer life time value), 재방문율 (Retention rate), 전환율 (Conversion rate)이 있습니다.
DAU(Daily active user), MAU(Monthly active user)는 명시적으로 어떠한 내용을 전달하기보다는 제품의 규모를 가늠하기 위해서 사용하기도 합니다 제품에 대한 사용자의 관심도는 DAU를 MAU로 나눈 고착도(Stickiness)로 확인합니다.
이탈률은 웹을 기준으로 단일 페이지 세션 수를 총 세션 수로 나눈 비율입니다. 이 지표로는 사용자가 제품에 관심을 보이지 않고 떠나는 비율을 단편적으로 확인할 수 있습니다.
QA (Quality Assuarance)
QA 조직에 테스트를 요청할 경우 테스트를 진행해야 하는 제품에 대한 대략적인 사전 정보는 아래와 같습니다.
- 제품 개요
- 신규 제품인지, 기존 제품인지
- 웹 서비스: PC 웹인지, Mobile 웹인지, 반응형 웹인지
- 앱 서비스: 안드로이드, iOS, 둘 다
- 테스트 환경: 디바이스, OS, 브라우저 등
- 테스트 페이즈: dev / sandbox / cbt / production
모든 케이스를 촘촘하게 검수하기 어려울 수 있으니, 그럴 때는 가장 사용자의 인입이 많을 시나리오에 따라서 테스트하는 것도 방법입니다.
(예를 들어, 이벤트 홍보 페이지이고 카카오톡으로 공유될 가능성이 높다면, 카카오톡의 인앱브라우저 테스트를 먼저하는 것)
테스트 케이스 주요 요소
배포 전 진행 항목 확인
- 앱 심사 요청 (앱인 경우)
- 제품 공지사항
- 보도자료
- CS 노트 작성 및 전달
배포 완료 후 진행 항목 확인
- 제품 공지사항 공개와 보도자료 배포처럼 미리 준비했던 항목 중 배포 직후에 진행해야 할 것 진행
- 제품팀 외부에 추가적으로 배포 완료를 공유해야 할 대상이 있는지 검토한다.
- 가장 중요한 것은 막 오픈한 제품 안에서 기능들이 제대로 동작하고 있는지, 사용자가 순조롭게 인입되고 있는지, 특별한 이상 징후는 없는지 모니터링
- 배포 후 어느 정도 시일이 경과하면 주요 온라인 커뮤니티 등에서 제품에 대한 사용자 반응 확인
지표 유형에 따른 사전 정의 대상
화면단 발생 지표와 DB 데이터 관련 지표로 나누어 볼 수 있습니다
| 화면단 발생 지표 | DB 데이터 관련 지표 | |
| 항목(예시) | 클릭 수, PV 등 | 회원 수, 결제금액, 구매 건수 등 |
| 필요한 사전 작업 | 지표 카운트를 위한 로그 심기 | 지표 추출을 고려한 DB구조 설계 |
| 정의 필요 항목 | 지표 집계 대상 화면 & 클릭 요소 | 지표 집계 대상 데이터 항목 |
| 정의 방식(예시) | 지표 집계 대상 페이지, 요소를 화면 단위로 구분하여 명시 | 집계 대상 지표 항목을 어떤 방식으로 추출해서 볼 것인지 표, 차트 형태 예시로 작성 |
서비스기획 시 참고할 수 있는 법률 사항
기획할 때는 법령에 대한 정보도 찾아가며 진행해야 합니다.
이럴 때 찾아보면 좋을 정보로는, 국가법령정보센터 사이트에서 법령의 명칭 및 주요 키워드로 검색하여 전체 법문 내용을 확인할 수 있습니다. 추가로, 찾기 쉬운 생활법령정보 사이트에서는 개인정보보호 등 정보통신/기술 분야의 기본적인 법적 개념의 핵심 내용을 간추려 제공하고 있습니다.
CS 대응 가이드
- 예상 문의/불만사항 항목과 그에 대한 답변 스크립트
- 예상 항목 이외의 내용이 인입되었을 경우 대처 가이드 (ex. 고객센터 담당자가 프로덕트 매니저에게 문의내용 이관)
- 강성 항의에 대한 대응 가이드 (ex. TO DO, NOT TO DO, 모범 답변 스크립트 등)
- 고객센터에서 제품팀으로 필수 공유가 필요한 대상 정의 (ex. 서비스 오류 제보, 고객에게 피해 발생 사례 등)
- 답변 처리 기간 기준 (ex. 인입 후 영업일 기준 5일 이내 답변 처리)
장애 발생 후 플로우
- 장애 발생 감지
- 장애 등급 판단
- 등급별 전파 대상 그룹에 장애 사실 전파
- 장애 처리 & 필요시 대내외 커뮤니케이션 진행
- 장애 처리 완료 (장애 현상 해소)
- 장애일지 정리 및 유관부서 공유
- 장애 후처리 - 장애 회고 및 재발방지대책 마련, 대외 커뮤니케이션, CS 응대, 피해 고객 보상 진행 등
오류 대응 중 개발 건이 생길 경우
- 이 작업에 대략 며칠 정도가 소요될 것인가
- 현재 진행 중인 과제와 함께 작업하는 것이 가능한가
- 함께 작업할 경우 각각의 작업기간이 어느 정도 추가되는가
- 현재 진행 중이거나 이미 예정된 과제들 중 우선순위를 조정할 수 있는 대상이 있는가