로드맵 수립, 그거 어떻게 하는 건데요?
PO의 핵심 역량 : 제품/서비스 전략부터 로드맵 수립까지 A to Z
PO이거나, PO였거나, PO로 이직/취업 예정인 사람들은 '로드맵 수립'이라는 용어가 굉장히 익숙할 것이라고 생각한다. 회사마다 불리는 용어는 '로드맵', '플래닝' 등으로 약간의 차이가 있을 수 있고, 수립하고 리뷰하는 주기도 다를 수 있다. 보통은 1년에 한 번 연말에 다음 해 로드맵을 수립하고 회사에 따라 분기 또는 반기별로 수립하는 종종 곳도 있다. 다들 알겠지만 로드맵/플래닝에 대한 사전적 의미를 정확히 짚고 넘어가는 게 좋을 것 같아 네이버 지식백과에 정의된 용어의 뜻을 보자.
로드맵
기업 · 국가 · 국제 사회 등에서 어떤 일을 계획하거나 추진할 때 사용하며, 앞으로의 계획이나 전략 등이 담긴 구상도 · 청사진 등을 의미한다.
플래닝
토목 용어로 조사 · 설계 · 시공 · 완성까지의 절차 계획을 작성하는 것이지만 일반적으로는 공사의 착공에서 완성까지 각 작업이 순조로운 페이스로 진행할 경우의 표준 소요 일수를 산출하는 작업.
의미를 읽어보면 로드맵/플래닝이 의미하는 바가 동일한 맥락이라는 것을 알 수 있다. 이 글에선 '로드맵'이라는 용어로 통일하여 글을 전개해 갈 예정이고 유니콘 스타트업에서의 로드맵 수립 과정과 이를 통해 느꼈던 점을 공유하고자 한다. 이 글을 읽기 전 PO의 역할에 대한 글을 읽고 오면 이해가 더 쉬울지도! PO는 모든 의사결정을 할 수 있는 사람 아닌가요?
제품의 전략
어떤 제품을 담당하고 있나요?
특정 제품의 PO를 담당하게 되었다면 그 '제품'에 대한 이해, 그리고 그 제품을 '어떤 고객'이 사용하는지에 대한 고객에 대한 이해가 필요하다. 전략이라고 하면 우리가 생각하고 있는 목표에 도달하기 위한 방법을 생각해내는 것인데 우리의 정확한 목표를 잡기 위해선 1) 제품과 2) 고객에 대한 이해가 너무나도 기본적이고 필수이기 때문이다.
내가 유니콘 스타트업에서 처음으로 담당하게 된 도메인은 지역홈이라는 도메인이었다. 많은 사람들에게 생소할 수 있는 도메인인데 여행 플랫폼에서는 자주 볼 수 있는 도메인이다. 이 도메인은 국내/해외 '지역명'으로 구성되어 있었고 각각의 지역은 그 지역에 해당하는 상품과 콘텐츠만 구성되어있었다.
나는 이 도메인을 이해하기 위해 첫 번째로 도메인의 히스토리를 파악하기 시작했다. 이 도메인이 만들어지기까지 기존에 작성되어 있던 문서를 봤고, 작성된 문서가 없다면 기존 담당자 또는 히스토리를 아는 누군가를 찾아다니며 물어봤었다. 또, 타사에 동일한 지면이 있을 경우 타사에서는 어떻게 제공하고 있는지 보고 자사 앱 내 제품과 어떤 차이가 있는지 등을 분석했다. 기존에 정리된 문서와 히스토리를 아는 여러 담당자를 통해 얻은 정보, 타사 앱을 통해 얻은 많은 정보들을 수집하며 읽고 듣다 보니 어느새 제품에 대한 이해도가 한층 높아져있었다.
그다음은 이 제품을 사용하는 '고객'에 대한 이해가 필요했다. 기존에 작성된 데스크 리서치, UT, 사용자 Research 자료, 고객 데이터를 보며 이 제품을 어떤 고객이 주로 사용하고 어떤 목적으로 방문하는지 등에 대해 고민하고 이해도를 높여갔다. 또, 추가로 궁금한 점이 있으면 간단하게 가설을 세워서 도메인 내에서 2주 단위로 테스트해보고 내가 생각했던 가설이 맞는지 검증을 해가면서 고객의 행동 패턴을 살폈다.
이렇게 몇 주간 제품과 고객에 대한 이해도를 향상하고 그다음 '고객을 만족시킬 수 있는 우리 제품의 전략'이 무엇인지에 대해 고민했다. 생각의 흐름은 대체로 아래와 같이 이어졌던 것으로 기억한다.
1) Mission : 이 제품은 우리 앱에서 어떤 역할을 하기 위해 존재하는 것일까?
2) Metrics : 이 제품의 Key Metrics(주요 지표)/Success Metrics(성공 지표)는 무엇일까?
3) Customer Jobs: 이 제품을 사용하는 고객이 원하는 것과 얻고자 하는 가치는 무엇일까?
4) 서비스 영향도 : 이 제품이 우리 서비스 전체의 고객과 지표에 어떤 영향을 미칠까?
위 4개 질문에 대한 답을 할 수 있다면 이제 어떤 고객에게 어떤 가치를 제공해야 하는지 명확한 방향이 보이기 시작할 것이다. 방향이 보이기 시작하면 그 방향으로 갈 수 있는 여러 방법이 떠오르게 될 것이고 그중 최선의 방법을 택하면 그것이 그 제품의 대한 전략이다. 자 여기까지 왔다면 이제 드디어 로드맵을 짤 수 있는 단계까지 온 것이다.
로드맵 수립 과정
요구사항 취합부터 리뷰까지! 로드맵 A to Z
전략에 대한 고민을 마쳤다면 드디어 로드맵을 수립하는 단계로 들어왔다. 내가 경험한 바에 의하면 로드맵은 보통 아래와 같은 단계를 거쳐 수립된다.
1. 요구사항 취합
각 부서의 요구사항을 취합하여 로드맵에 고려하는 단계인데, 요구사항을 받기 전 포맷을 만들어 둔 후 요구사항을 받는 게 좋다. 나는 보통 아래의 내용이 포함된 포맷으로 달라고 요청했었다.
우선순위
요청사항
배경
목적
정량/정성적 기대효과
희망 반영일
위와 같이 요청받고자 하는 포맷을 만들어놓지 않은 경우 대체로 '본인들도 왜 해야 하는지 곰곰이 생각해보지 않은 과제'들로 가득 채워져 있거나, '있으면 좋은데 없어도 되는 과제'들이 많이 포함되어있었다.
위 항목 모두 중요한데 나는 여러 부서에서 요청이 온 경우, 이 과제를 '왜' 요청했는지 그리고 얼마나 중요한지를 판단할 수 있는 '우선순위, 기대효과'를 보고 로드맵 반영 여부를 결정한다.
2. 로드맵 작성 및 유관부서 협업 요청
취합된 요구사항과 그동안 백로그에 있던 여러 개의 과제들 중 내가 담당하는 제품의 미션과 목표를 달성하기 위해 적합한 과제를 선정한다. 선정할 때 고민하는 부분은 아래와 같다.
제품의 미션과 싱크가 되는지
이 과제를 통해 목표를 달성할 수 있는지
개발 리소스가 얼마나 드는지
사업에서 얼마나 필요로 하는지(우선순위)
임팩트의 크기
디펜던시/선결조건 확인
위 부분들을 고민하고 해당 분기/반기/연간 로드맵을 이렇게 잡게 된 배경, 지난 분기/반기/연간 성과(잘한 점, 개선할 점), OKR, 진행 과제, 라이브 타깃 등을 포함하여 기재한다. 과제를 기재할 때도 과제별로 우선순위, 배경, 목적, 기대효과, 디펜던시(타 팀 영향도)/선결조건, 미진행 시 리스크 등 필요한 항목에 대해 정리하여 기재한다.
작성된 로드맵 내 진행과제 중 타 팀 디펜던시가 있는 과제가 있을 경우, 정리하여 해당 부서에 공유한다. 사전에 문서를 통해 디펜던시 과제 검토를 요청할 수도 있고 로드맵 리뷰를 하며 유관부서에 공유하기도 하는데 회사에 따라 프로세스가 다르므로 회사 정책에 따른다. 중요한 건 우리 팀에서만 해결할 수 없는 과제는 반드시 로드맵 진행단계에 '타 팀 공유'가 필요하다는 것이다. 여기까지 마쳤으면 이제 우선순위 재조정 단계로 넘어간다.
3. 기술 검토 및 우선순위 Align
2단계 로드맵을 작성하면서 내가 생각하는 제품의 방향성과 맞고, 우선순위가 높은 과제 위주로 1차 정리를 했다면 이제 내가 생각하는 과제 진행 여부와 우선순위에 대해 테크 리더 또는 Makers와 논의할 차례다.
우선순위가 높은 순으로 정렬한 과제들을 리뷰하고, 각 과제에 대한 기술 검토를 요청한다.
우선순위와 임팩트의 사이즈가 동일한 과제가 있다면 당연히 리소스가 적게 드는 과제의 우선순위가 더 높아진다.
기술검토가 다 끝났으면 투입되는 개발 리소스, 개발 난이도에 따라 우선순위를 Align 하는 과정을 거치며 한번 더 정리한다.
4. 로드맵 리뷰 및 보완
3단계까지 완료했다면 이제 대망의 로드맵 리뷰! 바로 전사 리뷰를 진행하는 것보단 팀 또는 부문 내 선 공유를 하여 팀원들이나 Makers들의 의견을 듣고 반영하여 Sync-up을 하는 것도 매우 중요하다.
내가 생각한 방향이나 과제의 우선순위가 완벽한 정답은 아니고, 예상치 못했던 케이스가 있거나 더 좋은 방향으로 갈 수 있는 아이디어나 의견이 나올 수 있기 때문이다.
완성된 로드맵 전체의 문서와 각 진행과제 별 배경, 목적, 기대효과, 디펜던시 여부 등을 포함하여 리뷰한다. PO의 경우 서로의 로드맵을 보고 과제 진행 여부, 우선순위, 라이브 타깃의 변동이 있을 수 있고 디펜던시가 있을 경우 예상치 못한 과제가 추가될 수 있다. Makers의 경우 로드맵 리뷰를 들으며 앞으로 어떤 과제들을, 왜 하게 될지에 대한 전체적인 흐름을 이해할 수 있다. 결국 로드맵은 '우리 팀/제품의 방향성'과 '앞으로 해야 할 과제'들을 한 판에 볼 수 있게 정리하고 동일한 방향으로 나아가게 하기 위한 수단일 뿐이다.
로드맵 리뷰 후 변경사항이 있을 경우 한번 더 로드맵을 보완하고, 변경사항이 없을 경우 다음 단계로 넘어간다.
5. 최종 로드맵 공유
이미지가 첨부된 표 또는 리스트 표 형태로 공유하면 언제, 어떤 과제를 하는지 한 눈에 보기에 좋다.요청부서 및 유관부서 전체에 작성된 로드맵을 공유한다.
로드맵 작성 후 추가로 요청되는 과제는 기존 로드맵 과제로 우선순위가 밀릴 수 있음을 안내하고, Jira를 통한 티켓 발행 또는 백로그 업데이트를 요청한다. 만약, 탑다운 과제이거나 중요도가 매우 높은 과제일 경우 기존 로드맵에 작성된 과제 중 일부를 미루고 먼저 진행해야 하는지에 대한 여부도 검토한다.
로드맵은 한 번 잡았다고 해서 무조건 그 분기/반기/연간 로드맵대로 따르는 것이 아니고 진행 상황이나 과제의 중요도에 따라 재조정되어 변경될 수 있음을 인지해야 한다. (세상은 내 뜻대로 되는 게 하나도 없다는 것을 다시 한번 상기시키며...)
다음은 PO가 가져야 하는 가장 중요한 역량인 '커뮤니케이션'에 대한 이야기를 하려고 한다.
10년이 넘게 회사생활을 하면서 다양한 사람을 만났고, 프로젝트를 할 때 만났던 사람들과 그들을 대했던 나의 커뮤니케이션 방법을 공유한다. 그럼 다음 글도 많관부!
커뮤니케이션
- PO의 커뮤니케이션 방법, 어떻게 소통을 해야 하는지
성과분석
- 과제 진행 후 성과분석은 어떻게 해야 하는지, 분석 이후의 액션은 무엇인지
공유의 중요성
- 제품, 과제에 대한 공유는 누구에게 어떻게 해야 하는지
회고 및 피드백
- 프로젝트 진행 후 회고, 피드백을 주고받는 올바른 방향에 대하여
