<프로덕트 매니지먼트> 김영욱 저/ 챕터 1
1. 프로덕트 매니지먼트란 무엇인가?
책의 내용을 토대로 본인이 소화한대로 정리 + 본인의 프로덕트 운영경험을 덧대어 작성하였습니다.
1. 프로덕트 매니지먼트란 무엇인가?
해당 챕터에서는 프로덕트와 컴포넌트를 정의하고, PM과 PO의 차이와 역할, B2B와 B2C를 구분한다. 기초적인 지식에 해당하는 내용이라 쉽게 간과할 수 있지만, 나의 경우 소수의 팀원으로 직접 프로덕트의 기획과 사업화 그리고 잡다한 씨에스와 세금처리까지 방대한 역할을 소화하고 있기 때문에 본질에 집중해 ‘역할’을 상기시키는 게 중요했다.
1) 프로덕트의 정의
일반적으로 설계 -> 개발 -> 테스트 -> 릴리스 의 사이클을 거쳐 나온 제품 자체를 프로덕트라고 한다.
그리고 프로덕드를 구성하는 요소, 즉 부품에 해당하는 부분이 컴포넌트다.
컴포넌트끼리 조합하여 컴포넌트 세트를 만들 수 있고, 이를 인스턴스 라고도 하며 프로덕트로 릴리스가 가능한 상태이다. 릴리스 가능한 상태인 것과 릴리스 된 것 사이에는 큰 벽이 있다. 시장이 원하는 형태로 패키징 되어야 한다는 게 그 벽이다.
오노브를 할 때는 정말 필요한 기능 (플리마켓 모집 게시물을 보여주고 신청할 수 있도록 하는 기능)만 갖춘 상태로 바로 릴리스를 해 사람들이 사용하게 하고 여기에 기능을 추가하거나(한 번에 여러 플리마켓 모집을 열 수 있게 리스트 페이지 추가) 내용을 업데이트(새로운 마켓 모집 오픈, 지난 오노브 매거진)하는 식으로 나아갔다. 컴포넌트 세트를 만들며 동시에 패키징을 했다고 볼 수 있겠다.
우리의 컴포넌트 중에는 관리자 페이지도 빼놓을 수 없다. 셀러 신청을 할 수 있는 모바일 페이지와, 이를 기획자가 확인하고 수락/거절/보류/메일 발송을 할 수 있는 관리자 페이지가 각각 오노브의 컴포넌트라고 할 수 있을 것 같다.
2) PM 의 정의와 역할
책에서는 PM의 역할이 아닌 여섯가지를 먼저 소개한다. 물론 나는 기획자이자 대표이기 때문에 역할 구분 없이 개발자, 디자이너의 역할이 아닌 모든 것을 한다. 그래도 책에서 소개된 ‘역할이 아닌 것’ 중 내게도 유용한 정보가 있어 그 부분을 추렸다.
* 역할이 아닌 것
-상사가 아님. 강요하거나 지시하지 않음.
-대신 ‘왜’를 명료하게 이해시키고 협업을 이끌어내야 함
-개발자가 아님. 기술적인 전문성보다는 소통에 필요한 최소한의 기술만을 알아도 충분함.
-프로덕트 오너가 아님. PO 로 칭해지는 프로덕트 오너는 프로덕트 백로그를 생성하고 스프린트로 옮기는 과정에서 우선순위를 정하고 전체 일정을 관리하는데, 이 역할은 나보다 현재 팀원 중 프론트 개발자분이 더 가깝게 하고 있으시고, 잘하신다. 역할을 명문화한적은 없는데 언급하고 넘어가면 좋을 것 같다.
그외 마케터, 데이터 분석가, 사용자 리서처는 PM의 역할이 아니라고 책에서 설명하는데 나에겐 해당되진 않는다.
*역할인 것
-커뮤니케이션의 허브. 매주 하는 정기 회의에서도 안건을 이끌어나가고 팀원들의 의견을 이끌어내는 역할, 고객과 소통하는 역할은 내가 하고 있다.
-우선순위 조정 역할. 이를 위해선 균형감, 합리성, 설득능력이 중요하다.
-치어리더 역할.
3) B2B 와 B2C
오노브는 둘 다인 것 같다. 오프라인 행사를 열기 위해 해당 공간에 미팅을 가고 서비스를 소개해 사업을 따내는 것은 B2B에 가깝다.
셀러 개인을 Consumer 라고 보면 셀러에게 제공하고 있고 (플리마켓 신청) 제공하려는 (플리마켓 참여 중 사용할 기능)을 제공하려는 건 B2C 이다.
때문에 B2B 서비스로서 공간에 사업을 따러 갈 때는 일관되고 명확한 시장 이점을 어필하고, 고객과의 신뢰 구축을 통해 프로젝트에 착수한다. 이때 사용 결정권자(공간)와 실제 사용자(마켓 참가자와 방문자)가 다르다. 오노브는 일년 간 고객과의 꾸준한 소통을 통해 올바른 과정과 성과를 거치고 신뢰를 구축하는 일에는, 평균적으로 괜찮은 성과를 냈다.
마켓 참가자들에게 B2C 서비스로 다가갈때는 조금 다르게 과정을 거쳐야 한다. 아이디어 검증 단게에서는 시도하고 배우기 접근법과, 시장 적합성을 찾기 위한 지속적인 실험이 필요하다. 이때 A B 테스트를 거치거나 사용자 조사, 설문조사, 인터뷰가 사용될 수 있다. 최근 우리 셀러들을 대상으로 설문조사를 진행했고 이번달 말에 인터뷰를 앞두고 있다.
빠르고 잦은 릴리즈를 목표로 해야하며 설문조사와 인터뷰는 초기 디스커버리 단계 뿐 아니라 새로운 기능을 추가하기 전에 잦은 주기로 진행해야 할 것이다. 이경우 사용 결정권자 (셀러)와 사용자(셀러)가 동일하다.
4) 프로덕트 매니저의 주요 역할
-비지니스 목표치 정의
-고객 요청을 수렴한 솔루션 제공
-고객 요청을 우선순위로 정리해 프로덕트 라이프 사이클 정의
-경쟁 프로덕트와 비교해 프로덕트의 지속 가능한 장점 구축
2. 프로덕트 리더십
1) 프로덕트 방향을 결정하기
중요한건 모든 구성원이 이해할 수 있도록 해야하는 것이다.
첫째, 비전을 수립한다. 서비스가 고객에게 장기간 지속적으로 어떤 가치를 전달하는 지 기술한다.
둘째, 전략을 수립한다. 위닝 플랜, 차별화 지점을 만든다.
-프로덕트 가치를 어떻게 고객에게 전달할것인가?
-경쟁 프로덕트와 차별화 지점은 무엇인가?
-타깃층은 누구이며 시간이 지나면 어떻게 확장되는가?
셋째, 로드맵을 만든다. 서비스 테마의 우선순위를 정하고 출시 시기를 정한다. 테마는 전략을 담은 큰 목표성 테마여야 한다.
네번째, 목표치를 설정한다. OKR objective and key results, KPI key performance indicator
마지막, 결정사항을 투명하고 명확하게, 일관성있게 전달한다.
2) 출시 프로세스 만들기
리서치-> 디스커버리->디자인->개발/테스팅->릴리스
각 단계에서 게이트 키퍼 ( 어떤 기준치로 통과할 지 결정) 마련해야 한다.
소수의 팀원으로 운영되는 오노브의 경우 게이트키퍼는 해당 백로그의 담당자가 결정하게 된다. 디자인의 경우에는 개발팀으로 넘기기 전에 기획자에게 컨펌을 요청해주시고, 플로우에 이상이 없으면 개발팀이 개발을 시작한다. 개발/테스팅 부분은 거의 개발자분들이 통과 여부를 판단하신다. 하지만 배포 이후에 사용자에게 직접 오류가 발생했음을 듣고 수정하기도 한다.
3) 소프트웨어 프로덕트 구체화 과정
1단계: 미션
-해당 프로덕트가 존재하는 이유, ‘왜’에 답한다. 오노브는 왜 존재하는가? 정확히는, 오노브가 개발하려고 하는 모바일 서비스는 왜 존재해야 하는가? 셀러로부터 데이터를 수집하는 동시에 유용한 기능으로 편의를 제공해 플리마켓에서의 최대 가치 창출. 이지만, 이때의 유용한 기능이 얼마나 수요가 있을지는 디스커버리(설문조사와 인터뷰) 뿐 아니라 베타테스트(이후 사용자에게 피드백 받기까지)를 요하는 부분이다.
2단계: 비전
프로덕트를 사용할 때 고객이 어떤 혜택을 볼지 기술한다. 해당 내용이 구체화 되어야 프로덕트 로드맵을 작성할 수 있다. PM의 역할이다.
3단계: 전략
시장을 분석하고 테마 기능별 우선순위를 정한다. 프로덕트의 성공 기준에 대한 실제적이고 구체적인 지표를 설정한다. 유저의 수나, 액티브 유저의 리텐션, 얼마나 잦은 빈도로 사용하는지에 대한 기준이 될 수 있겠다.
4단계: 전술
실제 프로덕트를 만드는 과정이다. 프로덕트를 완성하기 위한 백로그 아이템을 만들고 기능별 릴리스 플래닝을 세워 진행한다. PO가 담당한다.
4) PO란?
PM 과 구분되는 PO의 역할에 대해 좀 더 알아보자. PO는프로덕트의 딜리버리를 책임진다. 작은 조직이라면 PM이 직접 백로그를 만들지만, 위에서 말했듯이 이 작업은 나보다 프론트 개발자분이 더 잘 아시고 잘 하신다. 기능과 릴리스 플래닝을 작성하는 것은 1차적으로 기획자인 내가 하고, 이를 개발자가 소통 가능한 명확한 명칭과 순서로 정리하는 일은 개발자분이 해주셨다.
대부분의 기업에서 PO는 개발 팀이나 디자인 팀에 속해 본인이 맡은 기능이나 프로덕트의 릴리스를 책임지게 된다고 책에서는 기술한다. 릴리스의 타임라인을 관리하는 일이라면, 오노브의 경우 기획자와 위에 언급한 프론트 개발자가 논의 해 큰 틀을 만든다. 세부적으로 개별 백로그를 스프린트로 옮겨오는 우선 순위를 정하고, 작업하는 타임라인을 정하는 것은 개발자가 하는게 이상적인 그림일 것 같다.
