brunch

You can make anything
by writing

C.S.Lewis

by 키릴 kiril Sep 26. 2021

PO린이를 위한 로드맵(Rodamap) 개론


프로덕트 오너(Product owner)를 위한 로드맵 어쩌구 저쩌구로 시작하면 이번글 망할 것 같습니다.

그래서 저의 어린 시절부터 자라온 성장과정부터 말씀드리려합니다. 


PO린이들을 위해 오늘도 역시 깊이는 없습니다.

(사실은 제가 포린이일지도...)




0. 성장 과정 


저는 K-반도에서 태어났습니다.

부모님의 사랑아래 단군이래 가장 평범한 아이 1위로 자랐습니다. 

포브스지 선정, '매우 평범하게 자란 child' 순위 2위에 오르기도 했습니다. 



7살엔 남들 가는 유치원을 갔고,

8살엔 초등학교를 입학했습니다.

14살엔 중학교에 입학했고, 

17살엔 고등학교에 갔습니다.



그리고 21살 즈음엔,,,대학교를 갔고,

(재수를 했거든요) 

술만 왕창 먹다 군대를 갔고
복학 후엔 
대학교를 졸업하곤 취업을 했습니다. 




1. 학교 교육


초중고에 가보니 수업 시간표가 존재했습니다.

월요일 1교시는 국어, 2교시는 수학, 3교시는 사회 이런식으로 말이죠.


그런 시간표 중에 저는 수학을 무척 좋아했었습니다.

수학에서 한 문제 이상 틀리는걸 이해하지 못하던 재수없던 아이였죠. 

(수능 수리 가형 등급은 공개 할 수 없습니다....)


초등학교 수학 교과서를 살펴보았습니다. 

처음엔 덧셈을 배우고, 뺄셈을 배우고, 마지막으로 곱셈 나눗셈에 대한 내용이 있었습니다. 


중학교를 가니 집합과 기울기를 가르쳐주더군요. 

초등학교에서 사칙연산을 배우지 않았다면 이해가 어려웠을 거란 생각이 들었습니다.  


그리고 고등학교에선 미분과 적분을 가르쳐주었습니다. 

중학교에서 기울기에 대한 개념을 배우지 않았다면 이해가 어려웠을 것이란 생각이 들었습니다. 


대학교에서도 마찬가지였습니다. 


제가 듣고 싶은 수리 과목이 있었습니다.

그 수업은 '일반 통계학'을 먼저 들어야 수강 신청을 할 수 있었습니다. 

그래서 어쩔 수 없이 일반 통계학을 먼저 수강한 후에 듣고 싶던 과목을 들을 수 있었습니다. 


수업을 들어보니 알겠더군요.

왜 선수 과목으로 '일반통계학'이 지정되었던 이유를요.

저같은 평범한 아이는 '일반통계학을' 먼저 듣지 않았다면 이해 할 수 없던 내용이었습니다.




2. 정규교육에서의 로드맵 



사실 여러분은 저의 학창시절을 보기 위해 들어온 것이 아님을 알고 있습니다.

프로덕트 오너(Product Owner)가 말하는 '로드맵'이 무엇인지 알고 싶어서 들어온 것일테죠.


파악 하셨을지 모르겠지만, 저는 여러분께 저의 학창시절 '로드맵'을 말씀드렸습니다.


정규교육 로드맵은, '초등학교 > 중학교 > 고등학교 > 대학교' 인것이고, 
수학의 로드맵은 '사칙연산 > 집합 > 기울기 > 미분 > 적분 > 일반통계학' 인것이죠.


이렇게 말이죠.

(서울대를 못나왔지만, 서울대의 과목 로드맵을 갖고왔습니다!!!!!)



3. 프로덕트 로드맵


로드맵은 '길 + 지도'의 합성어로, 길이 그려저있는 지도라는 의미입니다.

그럼  지도는 무엇인가요? 

목적지를 향해 도착하기 위해, 먼저 지나가야 하는 길이 나와있는 것입니다.


즉, 로드맵은 'A'라는 목표를 달성하기 위해, 

우선순위에 따라 순차적으로 진행해야하는 '액션'들의 모음인 것입니다.


프로덕트(Product) 관점에서 보자면 

프로덕트의 비전과 목표를 달성하기 위해 우선순위에 따라 순차적으로 해야할 일들을 의미합니다. 



로드맵은 '프로덕트 오너 / 프로덕트 매니저'에게 상당히 중요한 존재입니다.

한 3가지 정도로 정리해볼까요?

i) 프로덕트(Product)의 비전을 구체화 할 수 있으며
ii) 로드맵 단계별로 어떤 것들을 먼저 개발할지 우선순위에 따른 계획을 설정할 수 있으며
iii) 구성원과의 합의를 가능하게 하기 때문입니다. 


왓챠를 예를 들어보겠습니다. 


지금에야 왓챠에서 영화에 별점도 주고, 영상 컨텐츠도 볼 수있지만 왓챠의 오픈 초기는 아주 단순했습니다. 

진짜 단순했죠. 마치 제 머릿속 같았습니다.  


이렇게 왓챠의 어린시절을 강제로 되돌아보며 왓챠의 로드맵을 3단계로 구분해보겠습니다. 

(생각대로 적는 것이니 디테일은 기대하지마세요.)



1단계

- 목표 : '영화에 별점을 줄 수 있는' 기능만 있는 MVP 출시 
- 목적 : 고객들이 어떤 영화를 좋아하고 싫어하는지 유형을 구분하고 데이터 수집을 위해 
- 필요 액션 : 회원 가입 기능 개발, 영화 리스팅 페이지 개발, 별점 체크 기능 개발, 별점에 따른 영화 추천 기능 개발



2단계


- 목표 : 왓챠 OTT 구독 서비스 출시 
- 목적 : 1단계에서 수집한 데이터를 활용하여, 고객이 영화 왓챠에서 시청 할 수 있게 
- 필요 액션 : 구독 기능 개발, 구독 유형에 따른 영상 제공 기능 개발, 시청 기록 기반한 영상 추천 서비스 개발, 영상 검색 서비스 개발, 컨셉에 맞는 영상 노출 위젯들 개발, 재방문 푸시 기능 개발



3단계


- 목표 : 왓챠 구독 가입자 확대 
- 목적 : 단순 구독 서비스 제공이 아닌, 글/영상등의 자체 콘텐츠 생성을 통한 가입 유도 
- 필요 액션 : 왓챠피디아 컨셉 개발, 왓챠피디아 노출 영역 개발, 왓챠피디아 + 영상 연동 기능 개발, 외부 사이트 컨텐츠 연동 기능 개발, SNS에 컨텐츠 공유하기 기능 개발, 한 달 무료 이용 기능 개발 



이런 식으로 말입니다.



각 프로덕트 별로 왓챠처럼 앞으로 어떤 것을 개발해야하고 

어떤 포인트에 집중해야하는지 로드맵을 작성하여 구성원들과 공유한다면, 

분명히 구성원들의 이해는 높아질 것입니다.


또한 모든 업무가 로드맵을 기준으로 진행되니 어설프고 비효율적이지 않으며,

비전을 어떻게 구현화 할 것인지 눈으로 확인 할 수 있고,

미래에 어떤 방향으로 프로덕트가 발전할 지 모두가 한 번에 이해할 수 있죠. 



4. 로드맵 작성 시 주의할 점 



로드맵은 프로덕트 구성원에게 바이블과 같습니다.

네비게이션이라고 표현 할 수도 있죠.

그렇기 때문에 로드맵에도 주의할 점이 존재합니다.


 i) 지속적인 리뷰를 통해 구성원들과 공감을 이룬다. 


로드맵을 작성하고 관리하는 것은 프로덕트 오너의 업무입니다. 

그러나 구성원들과 로드맵에 대한 내용에 대한 공감이 필요합니다.

프로덕트는 오너 한명이 담당하는 영역이 아니며 개발자, 디자이너 모두 오너쉽이 있는 영역이기 때문입니다. 


그렇기 때문에 비전을 현실화 하기 위해 작성된 로드맵은 언제나, 

꼭 구성원들과 리뷰를하며 공감을 이루어야합니다. 

구성원의 공감을 얻지 못하면 로드맵은 실현 불가합니다. 

방향성 설정은 프로덕트 오너가 할 수 있지만 디자인과 개발을 위해선 구성원이 꼭 필요하기 때문입니다. 


ii) 디펜던시(dependency)를 고려한다.


프로덕트엔 디펜던시(dependency)가 있습니다. 

디펜던시(dependency)란 '연관되어있는 기능'들이라는 의미입니다. 


하나의 앱을 기준으로 추천, 로켓 배송, 검색, 회원 관리 기능들이 모두 연관되어있단 이말입니다. 

앱은 고객입장에서 하나의 단일 앱으로 보이지만 그 안에는 다양한 프로덕트로 구성되어있습니다. 

큰 프로덕트 일수록 디펜던시 영역이 넓습니다. 

디펜던시가 넓을 수록 다른 부서들과 로드맵에 대한 사전 공유가 받으시 필요합니다


내년도 1분기에 우리 앱에 적용되어있는 '검색기능 고도화'를 진행할 예정입니다. 

그러나 막상 검색팀에서 이 내용을 모르고 있다면 그 일은 불가능합니다. 

그렇기때문에 사전에 계획한 로드맵은 연관되어있는 부서들과 내용 공유를 해야합니다.


iii) 선결조건을 고려한다.


이 센텐스에 대한 설명을 위해 상황극을 보기로하죠.

음,,,,저는 PO로서 A라는 서비스를 개발하고 싶습니다.


"나 : 개발자님 개발자님, 나 A 개발해야해요." 
"개발자 : 안되요 안되요." 
"나 : 아 왜요? 해줘요, 해주면 안되요?" 
"개발자 : B라는 기능이 있어야 A를 개발할 수 있어요. B를 먼저 개발하는게 필요해요."


서비스에 따라 B라는 기능을 개발하기 위해선 

그 전에 반드시 A라는 기능이 먼저 개발되어야하는 것들이 존재합니다. 

그래서 A의 개발이 필요한 것이고, 이때 A를 B의 선결 조건(선결 개발 사항)이라고 표현합니다.


따라서 선결 조건이 있는 과제들은, 

반드시 선결 과제들을 먼저 개발해야합니다. 


그렇지 않으면 개발 일정에 전체적으로 이슈가 생겨버립니다. 

그렇기 때문에 로드맵을 작성했다면 구성원들, 유관부서와 공유가 꼭 필요합니다. 




학교다닌 이야기 하다가 내용 다 채웠습니다.

이젠 저도 잘 모르겠습니다.

오늘도 멍청함을 느낍니다 ㅜㅜ


다음 글은 언제 올릴 수 있을까요?

        

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari