brunch

브런치북 오늘 프로덕트 매니저가 되었다 03화

라이킷 14 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by YB Mar 15. 2021

프로덕트 매니저는 제품 조직에서 어떤 일을 하는걸까?

5 단계로 나누어 살펴보는 프로덕트 매니저의 업무

-

프로덕트 매니저의 업무 범위

앞서서 프로덕트 매니저를 문제를 수집, 원인을 파악, 우선순위를 결정, 제품화를 기획하는 사람이라고 했다. 그만큼 포괄하는 업무의 범위가 넓다. 또한 하나가 아니라 여러 문제를 동시에 다룬다. 다양한 경로에서 담당 제품과 연관된 문제들이 발견되기 때문이다. 하루에도 여러 문제를 관리하는 경우가 많고, 각각의 진행상황도 다르다. 데일리 업무 리스트를 예로 들면 아래와 같다.

· 문제 A의 원인 파악을 위해 데이터 분석팀에게 요청할 사항 작성

· 문제 B의 배포 일정에 맞춰 담당자별 task 진행 현황 파악

· 문제 C의 제품화 요구사항을 앱 개발팀에게 공유

· 마케팅 조직에서 요청한 문제 D의 상세 내용 파악을 위한 미팅

따라서 제너럴리스트(Generalist)로서 멀티 태스킹이 가능해야 한다. 함께 일하는 시니어 PM은 이렇게 말했다. '스타크래프트의 멀티를 컨트롤하는 기분'이라고. 참 적절한 표현이다. 이러한 부분에 많은 프로덕트 매니저들이 초기에 어려움을 겪는다. 업무가 익숙지 않다 보니 병목현상이 발생하고, 함께 일하는 디자이너/엔지니어에게도 영향을 주기 때문이다. 그래서 진행했던 업무에 대한 회고가 필요하며, 효과적/효율적으로 처리할 방안이 무엇일지 고민하는 게 필요하다.

그렇다. 멀티(문제)를 잘 관리해야 우리 종족(제품)이 승리한다

-

01. 제품 문제 탐색

프로덕트 매니저의 업무를 5단계로 나누어 설명하려 한다. 첫 번째는 제품 문제 탐색이다. 고객에게 더 나은 경험을 제공해 제품을 성장시키려면 무엇을 개선해야 할지 살펴야 한다. 문제를 탐색하는 경로는 크게 4가지로 나뉜다.

1. VOC(Voice of Customer): 고객들이 직접 요청하는 사항이다. 앱스토어/플레이스토어 리뷰, 고객센터 문의, 포털사이트/소셜미디어 리뷰 등이 해당된다.

2. 구성원, 이해관계자의 요청사항: 부서별로 추진하는 로드맵에서 제품화가 필요한 사항, 원활한 업무를 위한 개선 사항 등이 해당된다.

3. 담당 제품 지표의 이상 징후: 대게 담당한 제품 지표를 일/주/월 단위로 측정한다. 특정 기간에 크게 하락하거나 상승했다면 원인을 파악해야 한다.

4. 제품 로드맵: 조직은 분기/연간으로 제품의 목표와 방향성을 수립한다. 이를 달성하기 위한 과업도 하나의 문제로 접근할 수 있다.

-

02. 문제 파악과 우선순위 결정

문제를 발견했다면 어떤 상황인지를 명확히 짚어야 한다. 그에 따라 적합한 해결책과 우선순위를 판단할 수 있기 때문이다. 예를 들어 데이터의 이상 징후가 발견되었다면 어떤 경로에서 발생했는지, 원인이 무엇이며, 관련된 VOC가 있었는지를 살펴야 한다. 다른 부서의 요청사항이 들어왔다면 제품화가 필요한 이유가 무엇인지, 어떻게 해결하고 싶은지를 명확히 짚어야 한다.

이후 문제 해결의 우선순위를 결정한다. 한정적인 구성원들의 리소스를 효율적으로 활용하려면 우선순위를 제대로 결정해야 한다. 프로덕트 매니저를 이를 제대로 수행하지 못하면 디자이너, 엔지니어들이 무엇을 해야 할지 방황할 수 있다. 또는 중요하지 않는 문제에 매몰되거나, 과도한 업무량에 번아웃을 느낄 수 있다.

우선순위를 판단할 때 3가지를 고민해보면 좋다. 첫째, 고객 경험 개선에 중요한가? 둘째, 우리 조직의 목표에 부합한가? 셋째, 이 문제를 해결하는데 필요한 기획/디자인/개발 리소스는 어느 정도인가? 이를 종합적으로 감안하면 올바른 우선순위를 매길 수 있다.

제품 우선순위 결정기준 2x2 priority matrix

-

03. 딥 다이브와 요구사항 작성

해결할 문제의 우선순위를 결정했다면 본격적으로 핵심 원인을 찾아야 한다. 마치 깊은 바다를 탐험하는 과정과도 비슷해 딥 다이브(Deep-dive)라고도 부른다. 이 문제가 왜, 어떻게 발생했는지 핵심 원인을 분석하는 것이다. 문제 상황을 여러 기준으로 잘게 나누어 분석할 수 있다. 또는 사용자 인터뷰를 통해 고객에게 직접 확인하는 것도 방법이다.

문제 핵심 원인을 접근할 때 도요타의 5 why 기법을 활용하면 좋다. 하나의 현상에 대해 왜 그러한지 질문과 답변을 5번 반복하는 것이다. 여러 문제를 동시에 관리하는 프로덕트 매니저에게 쉽지 않지만, 문제를 본질적으로 분석할 수 있다는 점에서 매우 유용하다.

핵심 원인을 파악했다면 어떠한 방식으로 해결할 것인지 가설을 수립한다. 가설은 구체적이고 검증 가능하게 수립하는 게 중요하다. 이후 가설을 제품화하기 위한 요구사항을 작성한다. 주로 아래 항목을 포함하며 제품화 수준, 조직 시스템에 따라 다를 수 있다.

· 문제 해결의 목표와 배경

· 문제 해결 가설과 측정 지표

· 제품화 이후 개선된 사용자 스토리

· 제품 개발 목록 및 구현 단계

· 제품의 실행 로직을 설명하는 플로우 차트

· 와이어프레임 및 동작 방식 설명

-

04. 제품화 테스크 관리

요구사항 작성을 마쳤다면 디자이너, 엔지니어에게 리뷰를 진행한다. 목적/배경/구현방향을 명확히 전달하고 피드백을 받는다. 이 과정에서 디자이너는 더 좋은 사용성을 고민하고, 엔지니어는 제품을 효율적으로 개발할 방법이나 새로운 Use Case를 찾아주기도 한다. 요구사항을 완성했다면 배포 일정 및 각 담당자들이 진행할 테스크를 할당해준다.

요구사항을 완료하기 전에 연관된 담당자에게도 관련 사항을 공유해야 한다. 이들이 업무를 진행하는 데 있어 참고를 해야 하며, 제품이 어떻게 개선될지 고객/파트너에게 설명할 수 있어야 하기 때문이다. 예를 들어 검색 기능을 개편했다고 하자. 새로운 기능에 고객 문의가 들어올 것이고, 고객센터에 적절한 안내를 할 수 있어야 한다. 이벤트 페이지를 개편했다고 하자. 여러 이벤트를 운영하는 마케터들이 새로운 기능을 어떻게 사용해야 할지 알고 있어야 한다. 실무자로서 이들의 피드백도 요구사항에 반영해두어야 완성도 높은 제품을 선보일 수 있다.

-

05. 배포 이후 모니터링 및 인사이트 도출

제품을 만들었다고 프로덕트 매니저의 역할이 끝난 게 아니다. 핵심 지표를 기준으로 본인의 가설을 검증하고, 고객 문제가 제대로 해결되었는지 파악해야 한다. 따라서 연관된 데이터와 VOC를 모니터링해야 한다. 예상보다 성과가 낮다면 왜 그러하며, 어떻게 개선할지를 도출해야 한다. 성과가 높다면 이를 확장시킬 방안이 무엇일지 고민해야 한다. VOC에서 치명적인 제품 결함이 발견되면 기존 제품으로의 롤백(Rollback)도 과감히 결정해야 한다. 이외에도 예측하지 못한 Use Case도 있는지 확인한다.