안녕하세요, 솜솜입니다.
저는 사회 혁신가들의 기술 장벽을 허무는 소셜 벤처에서 프로덕트 매니저로 일했는데요. 처음 해당 직무로 일하게 되었을 때 멋있으면서도 솔직히 잘 알지는 못하였습니다. 그래서 프로젝트 매니저와는 어떤 차이가 있을지, 어떤 방식으로 일하면 될지 궁금하기도 했습니다.
시간이 지난 지금 저는 직접 찾아보며, 또 일해보며 나만의 정의를 내리게 되었지만 다른 프로덕트 매니저는 어떻게 일하는지 또 어떻게 일하면 좋을지에 대한 고민은 항상 존재하는데요, 좋은 기회로 프로덕트 매니저라는 직업을 소개하는 책을 읽게 되어 후기를 작성해 보려고 합니다. (10년 차 프로덕트 매니저 실무자가 직접 알려주는 실전 프로덕트 매니저 이야기라고 합니다.)
목차
1. <프로덕트 매니저는 무슨 일을 하고 있을까 : 일 잘하는 PM이 되기 위한 실무 밀착 가이드> 책 소개
1-1. 프로덕트 매니저란? (feat. 프로덕트 오너, 서비스 기획자와 무엇이 다른가?)
1-2. 그들의 일
1-3. 커뮤니케이션
1-4. 역량 개발
2. 느낀 점
1. <프로덕트 매니저는 무슨 일을 하고 있을까 : 일 잘하는 PM이 되기 위한 실무 밀착 가이드> 책 소개
“프로덕트 매니저”라는 직무에 대한 책 자체가 귀한 현시점에서 원론적인 내용부터 실무에 적용할 내용까지, A to Z를 알려주는 정말 귀한 가이드와 같은 책이라고 말할 수 있겠습니다. 개정판이 나온다면 더 다양한 사례와 케이스별 사례가 추가되면 더욱 좋겠습니다.
1-1. 프로덕트 매니저란? (feat. 프로덕트 오너, 서비스 기획자와 무엇이 다른가?)
이 책에서 프로덕트 매니저(Product Manager)란 제품 관리를 하는 직무의 통칭으로 표현하며, “제품이 사업 목표를 달성할 수 있도록 기술적인 해법을 구상하는 사람”이라면 모두 주어질 수 있는 직무로 표현합니다. 조직에 따라 업무의 범위는 얼마든지 달라질 수 있습니다.
기획 또는 제품 관리 업무를 다루는 서비스 기획자, 프로덕트 오너와는 어떤 차이가 있을까요? 한국에서 관련 직무를 통칭하는 간단한 역사에 대한 이해가 필요합니다. 왜냐하면 인터넷이 상용화된 지 30년이 되지 않았고 개인이 스마트폰을 보유하게 된 것도 15년이 되지 않았기 때문에 상대적으로 신생 직업에 속하므로 학술적으로 연구된 내용이 적기 때문입니다.
<한국에서 시간의 흐름에 따른 기획자의 역할 및 위상 변화>
2013년 : “기획자는 필요 없다.” , 기획자는 요구자와 구현자의 중간 역할 및 일정 조율, 직접 디자인 역할 수행
2015년 : 웹 기획자 → 서비스 기획자 명칭 변경, 스마트폰 사용이 늘어나면서 앱이라는 새로운 매개체 등장 및 여러 단말에서 안정적으로 동작하는 서비스의 필요성, IT 서비스의 생활 필수화
2018년 : 프로덕트 매니저의 보편화, 2013년쯤부터 영미권에서 사용되었으나 한국에서도 적극 사용, 데이터 기반으로 사용자의 잠재 니즈 파악(그로스 해커의 역할), 팀 운영에 대한 업무
2020년 : 프로덕트 오너로 진화, 제품뿐 아닌 비즈니스 전체를 총괄하고 성과를 내고 책임지는 역할이 주어짐
결론적으로, IT 서비스에서 기획자의 역할은 기술 기반 도구에서 사용자 경험, 스스로 수익을 창출하는 경험의 총체까지 전 범위를 아우르는 역할을 담당하게 되었으며 조직에 따라 유연한 업무 범위를 가지게 되었다고 볼 수 있습니다. 따라서 현시점에서 기획 관련 직무의 명확한 정의와 구분을 나누는 것은 무의미하다고 볼 수 있습니다.
1-2. 그들의 일
마티 케이건은 <인스파이어드>(제이펍, 2018)에서 프로덕트 매니저 = 미니 CEO라고 정의합니다.
프로덕트 매니저는 조직에 맞게 비즈니스, 기술, 사용자 경험을 유기적으로 연결하고 비어 있는 지점을 성공적으로 채워 지속 가능하고 안정적이며 효율적으로 사업을 목표 달성으로 이끄는 것입니다. 따라서 프로덕트 매니저에게는 개별적인 역량과 더불어 각 역량을 유기적으로 연결하는 역량이 요구됩니다.
조직과 산업군, 프로덕트가 다른 만큼 각각의 프로덕트 매니저에게 요구되는 역량도 차이가 있을 수밖에 없습니다. 하지만 프로덕트 매니저의 커리어 패스로 참고할 만한 단계가 있습니다.
프로덕트 매니저에게 결국 중요한 것은 내 손을 거친 “프로덕트”를 생산하는 일입니다. 이를 위해서 프로덕트와 그 사용자, 그것이 속한 사회 분야에 대한 도메인 지식과 기본적인 관련 법률, 비즈니스, 제품팀 구성 멤버들과의 전반적인 협업 및 리딩, 그 모든 것에 걸친 전문적인 역량을 요구받습니다.
일반적으로 프로덕트 매니저는 제품이 탄생하는 과정에서의 모든 합의와 의사결정을 담은 기획서를 작성합니다. 요구사항 정의서와 화면 설계서, 유저 스토리 등의 산출물로 정의 됩니다. 좋은 기획서는 전달하는 바가 명확하고 간결해야 하며 모든 사람이 이해할 수 있고 가능하다면 수정도 가능한 기획서입니다. (다이어그램, 플로우 차트 등의 시각적인 보조 수단을 활용하면 좋으며, 일의 순서대로 작성하되 목차와 변경 이력도 함께 작성하면 좋습니다. 참고 문서가 있다면 링크를 함께 제공하는 것이 좋습니다.)
요구사항 정의서에는 일을 하는 이유, 접근 방향성에 대한 고찰이 들어가야 합니다. 문서는 빠른 작성을 통해 피드백을 빨리 받을수록 좋으며, 가독성이 좋고 토론의 여지를 남기는 것이 좋습니다. (이때 어떤 지점부터 토론을 시작할 지 주도권을 가지는 것이 중요합니다.) 작성-논의-수정 과정을 무수히 반복하는 것이 필요합니다. 책에서는 대표적인 데이터 분석 벤치마크 지표인 활성사용자, 이탈률 등에 대해서도 설명하고 있습니다. 이 부분은 제가 회사에서 작성했던 아티클에 쉽게 설명하고 있으니 궁금하신 분들을 참고해 보셔도 좋을 것 같습니다.
유저 스토리는 사용자 관점에서 기능 또는 제품에 대한 요구사항을 명시하는 방법론입니다. 애자일 개발 방법론(프로세스와 도구가 아닌 개인 간의 커뮤니케이션, 사용자 기반 소프트웨어 중심의 사고, 사용자 중심, 실행 중심의 프로젝트 진행)의 하위 개념이라고 볼 수 있습니다. 여러 개의 스토리가 묶여 에픽이 되며, 에픽이 묶여 하나의 이니셔티브가 됩니다. 각각이 사용자 중심의 요구사항이자 일의 단위가 된다고 볼 수 있습니다. 유저 스토리를 갑작스럽게 업무에 적용하게 되면 즉각적인 변화를 기대하기는 어려울 수 있으나, 공급자 중심이 아닌 사용자 중심의 언어로 제품을 설명하기에 용이합니다.
💡 유저 스토리 : "나는 [사용자 역할]로서, [기능/요구사항]을 원한다. 그래서 [가치/이점]을 얻을 수 있다."
예시: "나는 온라인 쇼핑몰 고객으로서, 상품을 카테고리별로 필터링하여 볼 수 있기를 원한다. 그래서 내가 원하는 상품을 더 빨리 찾을 수 있다."
화면 설계서(스토리보드)는 요구사항 정의서에 대한 조직 내 공감대가 이루어지고 무슨 일을 어떻게 할 것인지 합의가 되었을 때 작업을 시작합니다. 이해관계자의 눈높이를 문서로 맞추는 작업이라고 볼 수 있겠습니다. 사용자의 과업, IA/화면 흐름, 화면에 대한 상세 내용을 기술합니다.
마찬가지로 조직에 따라 차이가 있을 수 있지만 일반적으로 1차적으로 기획이 완료된 뒤 디자인, 마크업(퍼블리싱), 프론트엔드개발, 백엔드(서버)개발, 테스트 및 QA, 배포의 과정을 거쳐 제품이 개발됩니다. 프로덕트 매니저는 스프린트 내에서 이루어지는 백로그 관리 작업을 통해 진행 과정을 팔로업하는 과정을 담당합니다. 백로그에는 유형, 요약, 담당자, 우선순위, 상태가 포함되며, 이슈작성, 백로그 정제, 이슈 할당(스프린트 계획), 스프린트 진행의 과정을 거쳐 진행됩니다. 이 과정에서 일정이나 이슈 사항(기획서 내용 변경)등 변경 사항에 대한 대처도 중요합니다.
테스트 및 QA를 위해 테스트 리소스 및 일정 협의, 테스트 시나리오에 대한 작성 및 팔로업도 필요하고 제품 스펙 및 요구 스펙, 테스트 환경에 대한 검토(dev, sandbox, cbt, production 등), 테스트 케이스에 대한 설계도 필요합니다. 배포에 있어서 시점, 순서, 배포 후 문제가 발생했을 때 이전 상태로 되돌리는 롤백(rollback)에 대한 부분도 고렬하여 진행합니다.
이후 전체 과정에 대한 회고와 보고를 진행하여 프로젝트 론칭 과정을 마무리합니다.
배포가 완료된 서비스에 대해서는 운영이 필요합니다. MM(Man Month)등으로 월간 인력 업무량, 운영 인입량, 월간 근무일, 운영자 휴가 일수 등을 계산하고, 가이드 및 품질 관리, 운영 도구 관리 등을 고려해 플래닝합니다. 서비스에 대한 이슈 관리나 법무 검토, CS 대응 프로세스 구축 및 장애 발생 대응 프로세스의 구축도 필요합니다. 이 과정에서 협업과 리소스 관리도 필수적입니다.
1-3. 커뮤니케이션
프로덕트 매니저는 직무를 수행하기 위해 높은 커뮤니케이션 스킬과 리더의 역량이 요구됩니다. 회의, 기획서 등의 언어적 커뮤니케이션, 표정, 몸짓, 자세 등의 비언어적 커뮤니케이션, 보고 및 발표 자료, 광고 소재 이미지, 기업 로고 등의 시각적 커뮤니케이션에 있어 모두 높은 수준이 요구됩니다. 소속된 조직의 문화와 결과물의 완성도를 고려하여, 각자가 가진 커뮤니케이션의 차이를 이해하고 조직적 합의를 이끌어 내는 효과적인 커뮤니케이션을 통해 해소할 수 있습니다.
액션 아이템으로, 할 것(DO)과 하지 않을 것(DON’T), 정기적인 트러블슈팅, 원온원 미팅, 주기적 회고, 아이스 브레이킹을 위한 시간 할애 등을 제안할 수 있습니다. 리모트 근무를 할 경우에는 최대한 비디오를 켜고 회의에 참여하고 회의를 시작하기 전 명확한 목적을 공유하고 참여하며, 그리기 도구 등의 다양한 방법을 활용하는 것도 좋겠습니다.
1-4. 역량 개발
프로덕트 매니저는 직무 자체로 리더의 역할을 수행합니다. 조직마다 다 다른 리더의 유형이 있듯이 정답은 없지만, 문제 해결, 설득과 협업, 습득, 완성에 있어서 키맨 역할을 할 수 있는 것이 중요합니다. 조직이 프로덕트 매니저에게 기대하는 역할은 채용 공고에 잘 나와 있습니다. 역시 조직별로 차이가 있지만, 공통으로 도메인 지식, 프로젝트 리딩 경험, 커뮤니케이션 능력이 필요합니다.
역량 개발에 있어서는 개발, 데이터 분석, 제품 디자인 파트별 액션 아이템이 존재합니다. 먼저 개발에 있어서는 MOOC 강좌를 통한 컴퓨터 공학 기본 수업을 듣는 것을 추천합니다. DB 종류 무관, SQL 언어를 학습하는 것도 권장되며 Excel과 같은 스프레드시트 프로그램의 사용법을 익히는 것 역시 추천됩니다. 구조와 기본적인 개념에 대한 이해를 통해 기초적인 개발 역량을 키울 수 있습니다.
데이터 분석에 있어서는 퍼포먼스 마케팅 또는 그로스 해킹에서 쓰이는 용어에 대한 나만의 용어 사전을 만들 것을 권장합니다. 구글 애널리틱스 아카데미를 활용할 것 역시 권장되며, 유료 제품 분석 툴을 전문으로 다루는 회사의 콘텐츠를 확인하는 것 역시 권장됩니다.
제품 디자인에 있어서는 구글 material design guide, 애플 Human interface guideline를 통한 UI 컴포넌트 기본 지식 학습, 레퍼런트 사이트 확인, 경쟁/유사 서비스에 대한 역기획, 경쟁 서비스 모니터링을 권장합니다.
이렇게 액션 아이템을 기반으로 필요한 기초적인 역량을 습득할 수 있습니다.
“모두가 뛰어난 프로덕트 매니저와 그렇지 않은 프로덕트 매니저를 구분한다.
프로덕트 매니저는 자신의 모자란 점을 집요하게 찾아내고 개선하고 인정받기 위해 혈안이 되어 있다.
이런 자기검열을 하는 직무는 프로덕트 매니저뿐일 것이다.”
한 프로덕트 매니저가 SNS에 올린 글이라고 합니다. 자신이 속한 조직과 담당하고 있는 제품이 지금 당장 필요로 하는 프로덕트 매니저가 최고의 프로덕트 매니저로, 완벽을 쫓지 말고 조직과 제품이 필요로 하는 역량과 역할을 찾아서 수행해야 하겠습니다.
또한 리더와 관리자는 차이가 있습니다.
<리더와 관리자의 차이>
리더
- 동기부여
- 창의성
- 멘토링
- 문제해결
- 위험 감수
관리자
- 피드백
- 전문성 개발
- 위임
- 체계적인 정리 및 계획
- 문제해결
- 팀 단합
반드시 리더가 관리자일 필요는 없으며 반대로 모든 관리자가 리더는 아닙니다. 주니어 프로덕트 매니저의 경우 관리자로서 일할 기회보다는 리더가 될 수 있는 기회가 많습니다. 리더로서의 역량을 중심으로 생각해 봅시다. 리더십도 조직별로 매우 다르며, 정답은 없습니다. 지시적 행동과 지지적 행동을 기준으로 한 허쉬와 블랜챠드의 상황별 리더십 유형을 살펴보면, 지시형(지시, 명령), 코치형(설득, 설명), 지지형(참여, 촉진), 위임형(위임, 관찰) 유형의 리더십이 있는데, 나와 조직의 성향을 분석하여 상황에 맞는 리더십을 발휘할 수 있도록 하여야겠습니다.
2. 느낀 점
책을 한 장 한 장 넘기면서 첫 회사에 다니면서 기획부터, 개발, 테스트, QA, 배포, 운영까지 너무너무 힘들게 부딪혀가며 진행했던 기억들이 새록새록 떠올랐습니다. QA 팀까지 따로 있는 어느 정도 큰 규모의 회사가 아니라면, 해당 과업들을 인원 한 명이 일당백으로 진행하거나 다른 방향(외주, 협업, 자동화 솔루션 이용 등)으로 해소할 수 있기도 하다 보니 더 그랬던 것 같습니다.
다만 아쉬웠던 점은 보안 관련 내용에 대해 프로덕트 매니저가 어떤 식으로 업무를 진행하면 좋을지에 대한 내용이 추가되었으면 하는 것입니다. 보안 관련 이슈가 업무를 진행하면서 생각보다 크고 작게 많이 발생하는데, 해당 부분은 따로 파트를 빼서 설명되어도 좋을 것 같습니다. 또 개정판이 나온다면 도메인 별이나 실제 사례별 케이스도 추가된다면 더욱 좋을 것 같다는 생각을 했습니다.
그렇지만 IT 기획 직군에 대한 콘텐츠가 다른 직군에 비해 상대적으로 적다 보니(책에 언급된 것처럼 신생 직군이기도 하고, 시시각각 변하며, 업무 범위가 천차만별인 데다가, 상대적으로 주니어의 진입장벽이 높은 편이고, 일정 규모 이상 회사에서 수요가 필요한 직군인 것 때문인 것 같기도 합니다.) 정말 주니어 IT 기획 직군 종사자에게는 단비 같은 가이드라는 생각이 많이 들었습니다.특히 역량 개발과 관련된 액션 아이템에 많은 공감이 되어 당장 적용해 봐야겠다는 생각이 들었습니다.
주변에 IT 기획 직군 지망생이나 주니어가 있으신가요? 이 책을 선물해 보시기를 추천합니다.
※ 해당 리뷰는 한빛미디어의 후원으로 책을 제공받아 작성된 서평입니다.