PO린이를 위한, '프로덕트 개선 프로세스'
키릴이 알려주는, 프로덕트 오너의 제품 개선 업무 과정은?
PO/PM(프로덕트 오너, 프로덕트 매니저)는 프로덕트의 성장을 위해 미션과 로드맵에 따라 지속적으로 제품을 개선합니다. 제품의 개선 과정은 회사 또는 담당 프로덕트의 성격에 따라 다를 수 있습니다. 그러나 어느 수준까지는 '정형화된 프로세스'가 존재하며, 차이가 있더라도 많이 다르지 않을 것입니다. 그래서 오늘은 프로덕트 오너의 제품 개선 프로세스를 알아보겠습니다.
제품 개선 프로세스(by 키릴)
1. 문제를 도출한다.
2. 문제 정의 및 가설을 도출한다.
3. 문제 해결의 우선순위를 판단한다.
4. 과제를 진행한다.
5. 결과물을 배포한다.
6. 모니터링을 한다
7. 성과 측정을 한다.
8. 다음 과제를 진행한다.
1. 문제 도출
프로덕트 오너는 담당하는 프로덕트의 상태를 데이터를 기준으로 모니터링합니다.주요 지표에 한해서는 최소한 하루에 한번씩은 보려고하는데요, 보통 출근 후 가장 먼저 지표를 확인합니다. 첫 업무로 주요 지표를 모니터링하는 이유는 가장 최근일 기준으로 '프로덕트의 현황'을 파악하며, 해결해야 할 문제가 있는지 파악하기 위함입니다.
저는 프로덕트의 상태를 확인하기 위해 정량적 데이터와 정성적 데이터를 확인합니다. 정량적 데이터는 사내에 구축된 대시보드나 쿼리를 활용해 모니터링합니다. 어제 얼마나 들어왔는지, 구매 전환율이 전주 대비 어떤지, 전년대비 funnel 전환율이 어떤지 봅니다. 정성적 데이터는 정기적으론 확인하기 어려워, 특정 이슈가 있을 때 비정기적으로 체크를합니다. UT라고 불리는 고객 사용성 테스트 진행을 통해 기능의 불편함을 발견하기도하고, 앱스토어를 포함한 다양한 채널을 통해 유입되는 VOC를 탐색합니다.
정량적 데이터를 모니터링하다보면 패턴을 벗어난 추세가 보일 때가 있습니다. (진짜 보입니다. 매일 보다보면) 전년과 다른 유입 추세를 보이거나, 특정 요일과 다른 추세를 보이는 데이터와 같은 것들 말이죠.
가령 전주대비 회원가입율이 감소했다면 '회원가입 과정'에 어떠한 문제가 있다고 유추 할 수 있고, '주문전환율'이 감소했다면 내외부적 환경 변화가 발생했기 때문에 체크 해봐야할 이슈로 올릴 수 있습니다. 아니면 '앱스토어 리뷰'를 통해, 고객이 직접적으로 개선을 원하는 '문제'를 발견할 수도 있죠.
2. 문제 정의 및 가설 도출
문제를 발견했다면, 깊숙히 숨어있는 진짜 문제가 무엇인지 판단하기 위해 '문제 정의'를합니다. 정말 해결해야하 문제가 맞는지, 문제가 맞다면 그 원인이 무엇인지 찾아야 하기 때문이죠. 피상적으로 드러난 문제를 보고 '진짜 문제'로 정의한다면, 해결책도 피상적으로 밖에 나오지 않고 정작 해결해야할 문제를 벗어날 수도 있거든요.
잘 기억은 나지 않지만 예전에 일 잘하는 것으로 한창 언론에 나왔던 모 유명인이 이런 말을 했습니다.
'질문을 잘 하는 것이 가장 중요하다.'
문제 정의도 마찬가지입니다. 해결해야할 '문제'가 무엇인지 시장환경, 데이터를 참고하여 명확하게 정의하는 것이 중요합니다. 문제 정의는 주로 PO가 진행하지만, 상황과 조직에 따라서 함께하는 동료 구성원들과 함께 논의를 진행하기도합니다. 중요한 점은 문제 정의가 정확하고 명확하게 되어야 한다는 것입니다. 그렇지않다면 가설과 요구사항정의서가 전혀 다른 방향으로 만들어집니다. 프로덕트 개선을 위해 문제를 정의하는 것인데 '문제 해결'이 되지 않게 되는거죠.
문제를 정의했다면 그 다음엔 '가설 도출' 과정을 거칩니다. 명확하게 정의한 문제를 어떻게 개선하면 해결 될 것인지 솔루션에 대한 방향성을 도출하는 것입니다. 가령 문제를 '결제 단계에서의 이탈율이 지속 증가하고있다.'로 정의한다면, 가설은 '결제 프로세스를 단순화하고 UI를 개선하면, 결제 이탈율이 개선될 것이다.'라고 세울 수 있겠죠.
3. 문제 해결의 우선순위를 판단한다.
문제 정의와 가설 도출까지 무사히 완료했나요? 정말 축하드립니다. 축하를 해야하는건 맞는데 새로운 난관이 존재합니다. 바로 '리소스'죠. 해결해야 할 문제는 많은데, 구성원의 리소스는 한정되어있습니다. 유저 수가 증가하고, 운영 기간이 길어질 수록 문제는 지수 함수로 증가하지만, 프로덕트 구성원의 수는 언제나 부족합니다. 이런 상황에서 프로덕트 오너가 해야할 일은 '가장 먼저 해결해야 할 문제'가 무엇인지 우선순위를 판단하는 것입니다. 한정된 리소스 내에서 최대의 임팩트를 내야하기 때문입니다.
임팩트를 내기 위해선 어떤 지표를 개선 시켜야할까요? 프로덕트마다 집중하고 있는 '지표'는 다릅니다. 거래액 개선율일수도 있고, funnel 전환율일수도 있습니다. 정량적 관점에서의 사용자 경험이 될 수도 있습니다. 구체적으로 조직에서 설정한 'OKR'의 달성을 임팩트의 기준으로도 볼 수 있죠. 각 조직 그리고 이 제품이 집중하고 있는 것에 따라 중요한 임팩트의 기준은 달라질 것입니다.
임팩트에 기반하여 과제들의 우선순위를 판단할 수 있는 방법은 다양합니다. BRICS와 같은 우선순위 판단 방법론을 사용할 수도 있고, 중요도/시급성을 기준으로 할 수도 있습니다. a 문제는 중요도가 높고 시급성도 높은 반면에, b문제는 중요도와 시급성이 낮다면 a문제를 먼저 해결하는 것이죠.
그러나 이런 방법론만을 사용해서 우선순위를 판단하는것은 지극히 위험합니다. 비즈니스 관점 목표도 고려해야하고, 유관부서와의 일정, 그리고 프로덕트들간 의존성도 고려해야합니다. 또한 임팩트엔 큰 영향은 없지만 고객들에게 심한 불편함을 발생시키는 이슈의 경우 그대로 놔두면 곪기 마련입니다.
그렇기 때문에 과제의 우선순위를 정하는 능력은 능력은, 프로덕트 오너에게 가장 중요한 역량 중 하나로 꼽히고 있습니다.
4. 과제를 진행한다.
과제의 우선순위도 정했고, 이 시점에 진행해야 할 과제가 정해졌다면 과제를 진행하게됩니다. 제품 개선 프로세스와 같이, 과제의 상세 진행에도 어느 정도 정형화된 프로세스가 존재합니다.
a. 프리뷰(Preview, 또는 브리핑)
과제 착수 전 메이커스(개발자, 디자이너) 및 유관부서와 과제의 방향성을 공유하는 자리입니다. 과제에 대해 구성원들과 공감대를 이루며 같은 방향을 바라보기 위한 목적입니다. 과제에 대해 같은 생각을 공유하지않으면 과제가 산으로가고, 결과물의 퀄리티도 좋지 않거든요. 프리뷰는 프로덕트 오너가 사전에 작성한 '요구사항정의서(PRD : Product Requirement Documention)'를 활용하여 진행합니다. 이 문서는 PRD 또는 브리핑(briefing) 문서라고 불리기도하며 다음 내용을 포함합니다.
목적 및 배경
해결해야 할 문제
가설
가설 기반 솔루션
타겟 유저
유저스토리
성공 지표
기능 상세 정책서
마일스톤(일정)
F&Q
b. 정책서 작성 및 리뷰
'기능 정책서'는 그래서 문제 해결을 위해서 프로덕트를 구체적으로 어떻게 개선할건데?에 대한 내용에 집중합니다. 솔루션에 대한 상세 정책 문서로 어느 위치에 어떤 feature가 어떤 역할을 어떤 모양으로 해야하는지 정의합니다. k반도의 기획자들에게 가장 익숙한 정책서 유형은 '와이어프레임'입니다. 프로덕트가 어떻게 개선되는지 목업을 통해 직관적으로 볼 수 있으며, 디스크립션(영역별 정책)도 서술해 놓을 수 있기 때문입니다.
다만 조직과 프로덕트 오너의 성향에 따라 다른 유형의 기능 정책서를 사용하기도합니다. 바로 'AC(Acceptance Criteria)'인데요. 이미 쿠팡과 야놀자를 비롯하여 PO체계가 도입된 조직에서 사용하는 문서 유형입니다. 와이어프레임과 몇 가지 차이점이 존재하는데요. AC에선 화면의 프레임이 어떻게 구성되는지보다는, 내러티브한 서술을 하며 기능에 대한 상위정책과 하위 정책을 정의합니다. 그렇기 때문에 발생하는 가장 큰 차이는 'UI/UX 구현'에 대한 롤입니다. 와이어프레임에선 기획자(문서 작성자)가 UIUX를 모두 작성, 디자이너는 작성된 문서를 보고 그대로 디자인을합니다. 그러나 AC의 경우는 프로덕트 오너가 '기능의 구현에 꼭 필요한 정책'을 네러티브로 작성할 뿐, UI/UX는 프로덕트 디자이너가 담당합니다. 디자이너 입장에선 구현의 자유도가 증가한 것이죠.
정책서가 작성됐다면 메이커스, 유관부서와 리뷰를 진행합니다.메이커 관점 뿐만 아니라 비즈니스 관점도 모두 포함하며 논의가 진행되며, 좋은 피드백이 있다면 문제해결을 위해 최적의 방향으로 정책서가 개선됩니다.
물론 과제 프리뷰를 진행할 때 '정책서'를 함께 리뷰하기도 하며 그렇지 않기도합니다. 프로덕트 오너의 성향과 과제 사전 준비 시간 리소스에 따라 다릅니다.
c. 디자인 및 개발 진행
구성원들과 방향성, 제품요구사항에 대한 합을 맞추었다면, 메이커스의 본격적인 업무가 시작됩니다. 디자이너는 프로덕트 오너가 작성한 AC를 기준으로 UI/UX 디자인을 진행합니다. 디자인이 업데이트 될때마다 프로덕트 오너와 논의를 거치며 디자인 완성도를 높입니다. 개발자는 정책서를 기준으로 먼저 개발을 시작할 수 있는 영역이 있는지 판단합니다. 백엔드 API는 프로덕트 디자인 영향을 상대적으로 받지 않기 때문에 정책서를 기준으로 먼저 개발 착수를합니다. 디자인 최종안이 확정되고 디자인 정책인 디자인 가이드가 도출되면, 신규 feature에 대한 UI/UX 가 확정된 것이기 때문에, 클라이언트 영역의 개발이 시작됩니다.
d. 스크럼
스크럼 하면 가장 먼저 떠오르는 단어가 '데일리 스크럼'일텐데요. 프로젝트에 함께 참가하는 메이커들끼리 업무 진행 내용을 공유하는 자리입니다. 주로 이전 스크럼 이후에 진행한 일, 오늘 스크럼 이후에 해야 할 일을 이야기하며 개발 진행현황을 공유합니다. 진행 속도를 맞추고 이슈를 공유하는 것에 목적입니다.
스크럼 진행 여부와 주기는 과제와 프로덕트 오너의 성격에 따라 다릅니다. 간단한 과제의 경우는 스크럼을 하지 않기도합니다. 논의 할 만큼의 어려운 주제가 이니기 때문이죠. 그러나 로드맵 과제이거나 중요하다고 판단된 과제(또는 리소스 또는 기간이 많이 투입되는)는 주기적으로 스크럼을 진행합니다. 데일리 스크럼, 바이 데일리, 위클리 스크럼이 대표적이죠.
e. QA(Quality Assurance)
개발이 완료 됐다고해서 고객들이 사용하는 서비스에 결과물을 바로 배포 하지않습니다. 요구사항정의서 대로 구현이 잘 됐는지 검증이 필요하기때문이죠. 때로는 정책서를 수정해야 할 필요도 있구요. 이 검증 과정을 QA라고 부릅니다.
QA는 QA전문가가 신규 기능를 먼저 사용해보며 각 기능이 잘 작동하는지, 요구사항정의서대로 진행이 잘됐는지 하나하나 검증을해줍니다. 가령, 특정 영역에 있는 텍스트를 누르면 '사전에 정의한 페이지'로 이동해야한다는 정책이 있다면, 실제 이동이 되는지 확인합니다. 이동이 되지 않는다면 QA 이슈 리스트에 추가를합니다. Makers는 QA 이슈리스트에 추가가 된 항목들에 대해 수정을 진행합니다. 이런 QA 과정을 통해서 제품 퀄리티를 체크하고, 완성도가 떨어지는 제품을 보완 할 수 있게됩니다.
5. 과제(프로젝트) 결과물을 배포한다.
QA를 끝냈다면 결과물을 배포합니다. 결과물 배포 전 특히 주의 할 점이 2가지가 있는데요.
첫 째는 배포 전에 유관 부서를 비롯한 고객 상담 조직에 프로덕트 개선 사항을 공유해야합니다. 그래야 어떤 기능이 바뀌었고 신규로 출시되었는지 사전에 알 수 있으며, 배포 이후 발생할지 모르는 VOC에 대해 사전에 응대 준비를 할 수 있기 때문입니다.
둘 째로 플랫폼(eg. 웹, 앱)간의 배포 적용 시간을 고려해야합니다. 웹의 경우 개발자가 '배포'를 진행하면, 그 내용이 즉시 고객들에게 반여됩니다. 그러나 앱의 경우 '검수 프로세스'가 존재하기 때문에 바로 반영되지 않습니다. 물론 검수는 애플과 구글에서 진행하며, 앱이 각 사의 정책에 맞게 구현이 됐는지 검토를 합니다.보통 구글은 반나절, 애플은 2~3일의 시간이 소요됩니다. 앱스토어에 신규 앱이 출시되거나, 기존 앱의 '업데이트' 항목은, 이런 검수 과정을 거친 후에야 노출이 되는 것입니다.
그렇기 때문에 웹과 앱에 동시에 배포되어야하는 기능이라면 앱의 검토 일자도 함께 고려해야한다는 점은 꼭 기억해야합니다.
6. 모니터링을 한다.
신규 기능이 배포 되었다면, 모니터링을합니다. 고객 배포 전 QA를 진행하긴 했지만 요구사항정의서대로 잘 개발이 되었는지 Live 환경에서 다시 한번 체크를 하는 것입니다.
과정은 어렵지 않습니다. 우리가 실제 고객인 것처럼, 프로덕트에 접속해서 신규 기능을 하나하나씩 따라해보는 것이죠. 모니터링을 하다보면 배포 전에는 눈에 보이지 않던 수정사항이 보이거나 새롭게 개선해야할 아이템이 보이곤 하는데요. 만약 수정이 필요한 부분을 발견했다면, 이슈의 시급성을 판단합니다. 크리티컬한 영역인지 아닌지 말이죠. 만약 바로 개선이 필요한 크리티컬한 영역이면 핫픽스를 통해 빠르게 수정 반영을합니다. 마이너한 이슈라면 다음 버전에 포함하여 수정 배포를 진행합니다.
또 한가지 확인을 해야하는 부분은 '고객 행동 로그가 잘 쌓이고 있는지' 확인하는 것입니다. '로그'는 말 그대로, 고객 행동 데이터를 수집하는 것인데요. 로그를 통해서 프로덕트에 고객이 얼마나 방문하고, 어떤 기능을 이용하고, 어떤 버튼을 누르고, 어떤 상품을 구매하는지 알 수 있기 때문입니다. 어느 서비스의 MAU가 ㅇㅇ만명이더라, 예상 거래액이 ㅇㅇ억원이더라 하는 모든 소리가 '로그'가 존재하기 때문에 추적을 할 수 있는 것입니다.
이를 위해 프로덕트에선 특정 이벤트가 발생할 때마다 모두 기록을 합니다.
이런식으로 말이죠.
고객 한명 방문 : MAU 1
고객 또 한명 방문 : MAU 2
그렇기 때문에 라이브 모니터링을 진행하며 고객이 제품을 이용하는 행태들이 로그에 잘 남고있는지 확인하는 과정이 필요합니다. 이와 같은 내용들을 포함하여 프로덕트 오너는 배포 이후 일정 기간 동안은 신규로 배포한 기능과 지표들을 모니터링해야하는 과정이 필요합니다.
7. 성과 측정을 한다.
신규 기능의 성과를 파악하는 것은 중요한 프로세스입니다. '문제로 정의했던 이슈'가 해결 됐는지, 신규 서비스의 임팩트가 어느 수준인지 알 수 있기 때문입니다. 만약 해결되지 않았더라도 왜 해소가 되지 않았는지 어떤 점을 추가로 개선해야하는지 힌트를 얻을 수도 있죠.
성과분석은 보통 2가지 과정을 거칩니다.
1) 소프트 분석
배포 첫날을 포함하여, 하루/1주/2주를 기준으로 주요 지표의 모니터링 및 분석을 합니다. 깊이있는 분석보다는 신규 기능의 이용률 추세가 어떻게 되는지 가볍게 파악합니다.
2) 하드 분석
배포 이후 일정 기간이 지났다고 판단됐을 경우, 신규 프로덕트(또는 기능, 또는 서비스)가 어떠한 임팩트를 만들었는지 깊이있게 분석합니다. 프로덕트 전체 유입부터 funnel별 전환율, 그리고 기여 거래액까지 분석을 통해 임팩트 기반의 분석을 진행합니다. 이 분석을 통해 해결하고 싶던 이슈와 문제가 해결되었는지, 어떤 긍정/부정적인 효과가 발생했는지 알 수 있죠.
성과분석에서 중요한 점은 소프트 분석이든 장기 분석이든 분석한 내용을 프로젝트와 회사 구성원들과 공유해야 한다는 것입니다. 결과 공유는 프로젝트 구성원들에게 성취감과 오너쉽을 줄 수 있습니다. 자신이 참여한 과제의 임팩트를 보았으니까요. 또한 회사에선 비즈니스 목표 달성에 여러분이 담당하는 프로덕트의 기여도를 알게됩니다. 더불어 기여도와 임팩트가 크다면 그 프로덕트의 중요성은 자연스레 증가하겠죠.
결국 임팩트 있는 분석결과 공유를 통해 프로덕트 오너는 구성원들의 신뢰를 얻을 수 있고, 회사에서의 중요도가 올라가며, 로드맵 관점에서 신규 과제를 발굴할 수 있는 긍정의 결과를 만들 수 있습니다.
8. 다음 과제를 진행한다.
배포도 잘 됐고, 모니터링에서도 큰 이슈가 없다면 다음 과제에 착수합니다. 혹자는 1개 프로젝트가 끝나면 좀 쉬는기간이 있는 것이 아니냐고하지만 꺼억 소리나는 배부론 소리입니다. 해야할 과제들이 줄을 서서 기다리고 있거든요. 쌓여만 가는 백로그, 날짜까지 정해진 로드맵을 보다보면 어쩔 수 없이 바로 일을 해야한다는 마음이 생갑니다.
아무튼 새로운 과제를 착수한다면 '어떤 과제' 또는 '어떤 프로젝트'를 진행할지 판단해야합니다. 이미 일정이 다가온 로드맵급의 프로젝트 일수도있고, 제공되는 서비스의 오류를 개선하는 라이브 케어일수도있으며 그것도 아니면 지표 모니터링을 통해 해결해야할 이슈로 도출되어 문제 해결이 필요한 아이템일 수도 있죠.
사실 한 타이밍에 한 번에 1개 프로젝트만 진행하진 않습니다. 보통 로드맵 과제는 계속 진행하는 동시에 병렬로 작은 사이즈의 과제를 함께 진행합니다. PO / PM의 채용 공고에 '다양한 프로젝트를 동시에 진행 시킬 수 있는 분'이 빠지지 않고 써있는 이유입니다. 쉴 새 없이 뽑아먹겠다는거죠.
결국 다음 과제로 어떤 것을 진행할 것인지는, 그 타이밍의 '비즈니스의 방향성 + 로드맵 + 시급히 해결해야한 이슈'들의 복잡한 역학관계를 고려하여 선합됩니다. 그렇기 때문에 매번 우선순위를 판단하는 과정이 필요합니다.
과제를 선택했다면, '4.과제를 진행한다.'로 돌아가 다시 제품 개선 프로세스를 진행하게됩니다. 물론 1~3번은 수시로 해야하는 항목이죠^^
프로덕트 오너, 또는 PM의 제품 개선 프로세스를 알아보았습니다. 아주 간단한 사이클인데요, 현실도 이러면 좋겠지만 우리만의 바램이죠. 현실은 이 프로세스를 돌아리면서 새로운 문제도 발굴하고 로드맵도 업데이트하고 데이터 분석도 하고 유관부서(비즈니스/마케팅)들과 논의도 하는 등의 모든 업무가 전주비빔밥처럼 일어납니다.
그 과정에서 모든 영역들의 일정과 업무를 잘 조율하고 서로 원하는 것을 얻어가며 회사와 프로덕트의 방향을 align 시키는 것이 가장 이상적인 프로덕트 오너, 프로덕트 매니저의 모습이라고 생각합니다.
