프로젝트 성과 분석, 어떻게 해야 하나요?
성과분석에 어려움을 겪는 PO에게 알려주는 성과분석 A to Z
프로덕트를 담당하고 있는 PO라면 프로덕트의 성장을 위해 다양한 프로젝트를 진행하게 된다.
우선순위에 따라 프로젝트 진행 여부가 결정되면 PRD(*Product Requirments Document)를 작성하게 되고 여기엔 프로젝트의 배경, 목적, 가설, Success Metrics, 구현원칙, 기능정의, 유저스토리, 정책 등을 작성한다. 많은 PO들이 이 부분에 가장 많은 시간을 쓰게 된다. 프로젝트 설계가 끝났다면 다음으로는 디자인, 개발을 진행하고 배포한다. PO라면 프로젝트를 배포했다고 하더라도 '여기서 끝!'하고 마무리하면 안 된다. 프로젝트 관련 주요 지표를 볼 수 있는 대시보드를 만들고 매일 수치를 모니터링하며 우리가 생각한 방향으로 순항하고 있는지 확인해야 한다.
배포 후 2주에서 4주 정도의 시간이 지나면 우리는 '프로젝트의 성공여부'를 확인하기 위해 성과분석을 진행하게 된다. 오늘은 '프로젝트 성과분석 하는 법'에 대해 공유하려고 한다.
그동안의 경험을 토대로 '내가 성과분석 하는 방법'을 공유할 예정이므로 오늘 공유하는 내용이 정답이라고 생각하진 않았으면 좋겠다. PO 스타일에 따라 성과 분석하는 시기, 방법이 다르기 때문이다. 이 글을 읽고 본인이 성과분석 하는 것과 다른 지점이 있거나 추가하면 좋을 내용이 있다면 댓글을 통해 공유해 주시면 감사할 것 같다.
성과분석, 왜 해야 하나요?
여러 PO와 같이 프로젝트를 하다 보면 배포한 프로젝트를 꼼꼼하게 들여다보며 모니터링하는 PO도 있고, 배포했으니 '끝'이라고 생각하고 모니터링, 성과분석조차 하지 않는 PO도 볼 수 있다. 후자와 같은 PO는 연차가 아무리 쌓여도 성장하는데 한계가 있고 결국 PO로의 능력을 인정받기는 어렵다고 생각한다. 프로젝트 배포 후 성과분석을 하는 것은 '프로젝트의 방향성을 잘 잡았는지, 그래서 지표를 달성했는지를 확인' 할 수 있는 너무 중요한 일이기 때문이다. 그럼 아래에서 성과분석이 왜 중요한지에 대해 자세히 설명하겠다.
1. 프로젝트의 성공/실패를 알 수 있다.
PRD를 작성할 때 성공지표(Success Metrics)를 기입하는데 이 지표를 기입하는 목적은 프로젝트 배포 후 '프로젝트의 성공 여부를 판단하기 위함'이다. PRD에 아래와 같이 정의해 놨다고 가정해 보자.
Success Metrics : 이탈률 2%p 개선
성과분석 시 위에 정의해 둔 Success Metric을 달성했는지를 파악하여 프로젝트의 성공 여부를 확인할 수 있다. 위와 같이 정의해 두었다면 아마 이 프로젝트의 목적은 이탈률 개선이었을 것이고 이를 달성하기 위한 실행 방안은 이탈률 개선에 도움이 될 만한 액션을 수행했을 것이다.
지표를 보며 결과를 확인해 보면 설정한 목적에 맞게 프로젝트가 잘 진행되었는지, 설정한 목표를 달성했는지 정확하게 판단할 수 있고 지표를 달성했다면 목적에 맞게 잘 설계된 프로젝트였다고 판단할 수 있다.
만약 달성하지 못했다면 '왜 달성하지 못했는지'에 대한 원인을 파악하고 이를 개선하여 다음 프로젝트 설계에 활용할 수 있어야 한다. 이렇게 지표를 설정해 놓으면 성공 여부를 정확한 기준으로 판단할 수 있고, 성공을 했을 땐 어떤 부분이 성공 포인트였는지, 실패를 했을 땐 왜 실패했는지를 배울 수 있다.
2. 프로젝트의 방향성을 잘 설정했는지 알 수 있다.
프로젝트 설계 시 PRD에 정의해 둔 목적에 맞게 프로젝트가 순항하고 있는지는 매일 지표를 모니터링하며 빠르게 캐치할 수 있지만 충분한 모수가 모이지 않았을 경우에는 지표를 보고 판단하기엔 정확도가 떨어질 수 있다. 이러한 부분은 충분한 모수가 확보되었다고 판단할 때 성과분석을 진행하여 최종 확인할 수 있다.
위에 들었던 예시대로 Success Metric을 잡았는데, 결과를 확인해 보니 오히려 이탈률이 증가했다면 이 프로젝트는 '실패' 했다고 판단한다. 심지어 이탈률이 유지도 아닌 증가라면 롤백도 고려해야 할 정도로 잘 못된 방향성으로 설계한 것이다. (*아웃라이어 제거, 개선전후 서비스에 영향을 미칠만한 프로모션이 없다는 전제) 이 경우 지표를 딥다이브하면서 어떤 부분이 잘 못 되었는지를 정확하게 파악해야 한다. 여기서의 레슨런으로 추후 프로젝트 설계 시 더 좋은 방향으로 설계할 수 있도록 한다.
3. 프로젝트를 같이 만들고 협업한 Makers와 Stackholders에게 동기부여를 줄 수 있다.
대부분의 프로젝트는 PO 혼자 기획하고, 개발하고 배포할 수 없다. 프로젝트 설계부터 진행까지 Makers와 Stackholders의 도움이 필요하고 '같이 만든 프로젝트' 이므로 당연히 이들에게도 프로젝트 성과를 공유해야 한다. 이탈률 개선 목적의 프로젝트를 진행했다면 데일리 모니터링을 통해 배포 후 즉시 어떤 수치 변화가 있는지를 공유하고, 배포 후 일정 기간이 지났다면 디테일한 성과분석 내용을 공유한다.
이 경우 같이 작업한 작업자들은 '내가 만든 프로젝트가 고객에게 이러한 영향을 주고 있구나'를 알 수 있고, 우리가 설정한 목적과 목표를 달성했는지 확인할 수 있어 그들이 했던 업무가 '정말 유의미한 일이었다'라는 것을 정량적인 지표를 통해 알려줄 수 있다. 프로젝트가 목표한 수치를 달성했다면 뿌듯해할 것이고, 달성하지 못하면 달성하기 위해 추가적으로 해야 할 액션이 무엇인지를 같이 고민할 수 있다. 이렇게 성과분석을 진행하고 이를 Makers와 Stackholders에게 공유하는 것이 얼마나 중요한 일인지 다시 한번 기억하고 협업자들에게 성과분석 리뷰를 진행하자.
4. 다음 프로젝트에 참고할 수 있다.
성과분석을 하면 이탈률 개선이 목적이었다고 하더라도 단순히 '이탈률'만을 보지는 않는다. 하루에 유저가 얼마나 유입되는데 이 중 몇 프로가 이탈했는지, 주로 어떤 고객(기존/신규/유입채널별.. 등)이 이탈했는지 얼마나 머물다 이탈을 했는지 어떤 영역까지 스크롤하다 이탈했는지 등등의 추가적인 데이터를 살펴본다.
데이터를 분석하다 보면 자연스레 우리 서비스 고객에 대한 이해도가 높아져 고객 특성을 보다 깊이 있게 알 수 있다. 이렇게 높아진 이해도를 토대로 다음 프로젝트 설계 시 '추가로 이해한 데이터'를 참고할 수 있다.
저번 A프로젝트에서 성과분석 했을 때 우리 고객은 보통 홈에서 많이 이탈했지?
이탈 전엔 C 컴포넌트까지 보고 이탈 했었어. 그럼 이번 신규 컴포넌트는 B에 배치해서 테스트해 볼까?
위처럼 데이터 기반의 깊이 있는 고민을 통해 다음 프로젝트 진행 시 정교한 방향성을 설계할 수 있게 된다.
성과분석, 어떻게 해야 하나요?
성과분석 시 꼭 포함해야 되는 항목, 함께 봐야 하는 것들 그리고 주의해야 할 점에 대해 알아보자.
1. 프로젝트 진행 시 설정한 가설에 대한 검증
가설 : 홈 지면에 A 컴포넌트를 제공할 경우, 홈 이탈률이 2%p 개선될 것이다
위에서 말했던 것처럼 PRD 작성 시 프로젝트의 진행 목적과 가설을 정의해 놨을 것이다. 그렇다면 성과분석 시 내가 PRD에 정의해 둔 가설의 검증이 포함되어야 한다. 위와 같이 가설을 정의해 놨다면 성과분석 시 홈의 이탈률을 확인하고 실제 A컴포넌트 제공 후 이탈률이 어떻게 변화했는지 살펴본다. 그리고 이 가설이 맞았는지, 틀렸는지를 지표를 보고 판단하고 이를 문서에 작성한다. 나는 주로 아래와 같이 작성해 놓는다.
'홈 지면에 A컴포넌트를 제공할 경우, 고객의 이탈률이 2% p 개선될 것이다'라는 가설을 확인해 본 결과 실제 홈에 A 컴포넌트를 제공하니 홈 이탈률이 2% p 개선되어 가설이 맞음을 확인했다.
2. Success Metrics에 대한 확인
프로젝트 설계 시 작성해 놓은 Success Metrics에 대한 검증은 성과분석에 꼭 포함되어야 한다.
그래야 이 프로젝트의 성공 여부를 확인할 수 있다.
Success Metrics : 이탈률 2%p 개선
성과분석 문서 내 결과는 전, 후 기간과 증감률을 포함하여 아래와 같이 업데이트한다.
이탈률 2% p 개선으로 목표 달성
분석 기간 : (전) 2023.01.01 ~ 2023.01.20 | (후) 2023.02.01 ~ 23.02.20
이탈률 : 50% -> 48%로 2% p 개선
3. 이 외 지표 확인
PRD 작성 시 Success Metrics를 정의해 놓는 경우 메인 지표와 모니터링 지표를 나눠서 정의해 놓는데 이 경우 모니터링 지표는 어떤 변화가 있었는지 포함되어야 한다.
Success Metrics
Main : 이탈률 2%p 개선, Monitoring: first click (접속 후 첫 클릭)
PRD에 위와 같이 메인지표와 모니터링 지표를 기재해 두었다면 성과분석 문서에 2개 지표 모두 확인하여 업데이트한다. 모니터링 지표를 first click으로 잡은 이유는 이탈률이 개선되었다면 고객이 제일 먼저 어떤 컴포넌트 또는 상품을 클릭했는지 확인해 보고 위해서이다. 이탈률 개선을 위해 홈 지면 내 A 컴포넌트를 추가했고 실제 이탈률이 개선되었다면 이탈하지 않은 고객이 A컴포넌트를 클릭했는지 확인하여 '이탈률 개선이 정말 A컴포넌트 추가로 인한 것인지(=목적을 달성하기 위한 실행방안이 맞았는지)'를 파악할 수 있어야 한다. 이 외에도 여러 개의 모니터링 지표를 정의해 두었다면 이 지표들의 결과도 꼭 포함해서 작성하도록 하자.
메인지표뿐만 아니라 모니터링 지표까지 성과분석 문서에 작성해 놓으면 프로젝트의 성공 여부를 보다 탄탄하게 뒷받침해주는 근거가 된다. 또, 다양한 지표를 보며 얻은 인사이트와 프로젝트의 정량적 결과는 추후 프로젝트 Success Metrics 설정 시 도움을 주기도 한다.
4. 성과분석 시 주의할 점
사실 나에게도 아직까지 어려운 부분인데, 데이터를 보다 보면 개인의 주관이 섞이게 된다. 같은 지표를 보더라도 누가 보느냐, 어떻게 해석하느냐에 따라 결과가 달라질 수 있기 때문이다. 이 경우 최대한 주관을 배제하고 여러 데이터를 크로스체크하여 보는 것이 가장 중요하다.
애매한 부분은 모두 '~하지 않을까?'라는 예측치로 기재하지 말고 무조건 추가 데이터를 확인해서 기재한다. 이렇게 성과분석 Draft 안이 작성되었다면 이후 데이터분석가, 팀원들에게 공유하여 내가 이러한 지표를 보고 이렇게 성과분석을 했는데 혹시 나의 해석과는 다르게 지표를 해석했거나 이견이 있으신 부분이 있는지 여쭈어본다. 의견을 주신다면 성과분석 문서 내 이러한 의견들을 참고하여 작성하고, 추가 데이터를 확인하여 문서를 최종 업데이트 한다. 이렇게 하면 '내가 판단하기 애매했던 부분'은 팀원들의 의견을 참고하여 정량적 수치로 한번 더 체크할 수 있고, 개인의 주관이 담긴 해석을 덜어 내 조금 더 정확한 인사이트를 기재할 수 있다.
성과분석 그 이후
1. 공유 : Stackholders에게 서면&구두 공유
프로젝트를 진행하면서 가장 중요한 건 역시나 '공유'다. 프로젝트는 '함께 만들어 가는 것' 이므로 성과분석을 하면 꼭 Makers, Stackholders에게 공유해주어야 한다. 그들의 리소스가 들어간 프로젝트이고, 아마 그들의 KPI와도 연결된 부분이므로 프로젝트의 성과는 나에게도 그들에게도 중요하다.
성과분석 문서를 작성하고 최종 보완까지 완료했다면 Summary로 서면 공유하고, 이후 성과분석 공유 미팅을 진행한다. 아마 성과분석 미팅은 프로젝트 오픈 후 4주가 지난 이후이므로 5주 차에 진행할 확률이 높은데 이 경우 5주나 지난 프로젝트의 세부내용을 기억하기는 어려우니 성과분석에는 프로젝트의 목적, 목표, Feature를 확인할 수 있게 간단하게 작성해 놓는 것이 좋다. 그리고 미팅 진행 시 이 프로젝트는 어떤 목적을 가진 프로젝트였고, 우리의 Success Metrics은 이러한 지표들이었다. 성과분석을 해보니 우리가 설정한 Success Metrics을 모두 달성하여 이 프로젝트는 성공이라고 판단했다. 자세한 지표는 아래와 같다. 하며 디테일한 지표의 항목들과 그 데이터를 보고 느낀 인사이트를 공유한다. 공유가 끝나면 지표에 대한 문의, 의견을 주고받으며 성과분석이 잘 되었는지, 추가적으로 살펴보면 좋을 데이터가 무엇인지, 다음 프로젝트 시 어떤 부분을 고려해서 설계하면 좋을지 충분히 논의한다.
2. Action item 도출
성과분석 미팅을 하며 추가적으로 살펴봐야 하는 지표들, 생각지 못했던 질문들을 받게 되는데 이 경우 Action Item 영역에 기재한다. 예를 들어, 이탈률 지표에 대한 성과분석을 진행했는데 누군가 '기존 유저와 신규 유저의 이탈률 중 어떤 유저의 이탈률이 더 높나요?'라는 질문을 했는데 이 부분의 분석이 누락되어 있다면 이것이 Action Item으로 정의될 수 있다. 또는 이탈률 2%p 개선을 목표로 잡았는데 이탈률이 목표치에 맞게 개선되지 못한 경우 '이탈률 2%p 개선을 위해 어떤 추가 시도를 해볼 수 있을지?'에 대한 다음 계획을 수립할 수 있다. Action Item은 아래와 같이 작성한다.
Action Item
각 유저 그룹(기존, 신규)의 이탈률 확인 ~due date, 담당자명
이탈률 개선을 위해 추가한 컴포넌트의 순서 변경을 통해 이탈률 개선 모니터링 ~due date, 담당자명
3.Action Item 실행
위와 같이 Action Item이 작성되었다면 Jira 티켓을 발행하여 sustain건으로 진행한다. Jira를 이용하지 않는다면 본인 기업에서 이용하고 있는 생산성 툴을 사용하여 Action Item을 건건이 작성하고 담당자와 due date를 설정해 둔다. 티켓을 할당받은 담당자가 일정에 맞게 Action Item을 완료했다면 성과분석 리뷰에 들어왔던 모든 Makers, Stackholders을 멘션 하여 공유한다. 액션아이템이 '추가적인 데이터 분석'이었다면 확인해 보니 '데이터가 이렇더라'라고 공유하면 되고 'sustain건으로 기획&개발이 필요한 건'이라면 '기획 후 기획 내용을 공유하고 개발 이후 배포일을 공유하고 배포 후 모니터링한 성과를 공유'한다. 이런 프로세스로 진행하면 프로젝트의 목적에 맞게 계속해서 고도화해 나갈 수 있다.
오늘은 성과분석을 왜 해야 하는지, 그리고 어떻게 하면 좋을지에 대한 부분을 공유했다. 중간에 프로젝트 예시를 넣어 보다 세부적으로 다룰까 하다 글이 너무 길어져 방법에 대한 핵심 내용 위주로 구성했다.
지금까지 프로젝트 배포 후 거의 대부분 성과분석을 진행했는데 워낙 자주, 많이 하다 보니 점점 성과분석 포맷도 업그레이드되고 좋은 인사이트도 많이 발굴하며 PO로도 크게 성장했다고 생각한다.
아직 성과분석을 한 번도 해보지 않았거나 성과분석에 어려움을 겪고 있다면 이 글을 참고하여 성과분석 포맷을 만들고, 진행하고, 공유해 보면 어떨까?
