기획자의 문서
아이디어를 구체화하고 작업을 하기 위해서는 기획문서를 보통 작성 합니다(딜라이트룸에서는 PBI(Product Backlog Item) 로 부르고 있습니다). 이 기획문서는 다양한 내용들을 포함하고있는데요, 그 중에서 “Impact” 에 대해서 이야기 해보려고합니다.
작업의 우선순위 결정에 중요한 역할을 하는 요소중에는 이 작업의 효과의 크기가 포함되는것이 일반적입니다. 서비스 내에서 풀어야하는 다양한 문제들 중, 효과의 크기가 큰 순서대로 작업해 나가는것은 제한된 리소스를 가진 팀의 자원을 효과적으로 사용하는 업무방식임에 틀림없죠.
이를테면, 서비스내 다수인 보편적인 유저들이 영향을 받는 기능에 대한 개선은 임팩트가 큰 작업이라고 볼수 있습니다. “하루 1,000명이 보는 페이지의 UI/UX 개선” <> “10,000명이 보는 페이지의 UI/UX 개선” 두가지 중 후자를 택하는것이 보다 많은 유저들의 경험을 개선해줄수 있다는 측면에서 임팩트가 크다고 할수 있습니다.
하지만, 단순히 많은 유저들이 경험한다고 해서 항상 임팩트가 크다고 할수 없는 상황들도 있습니다. 많은 유저들이 경험하긴 하지만 사소한 문제라서 앱사용에 큰 불편함이 없는것과 너무 크리티컬해서 이탈을 결정할만한것은, 사안은 중함의 정도가 다릅니다.
- 하루 1,000명이 보는 페이지, 경험한 유저의 50% 이탈 (500명 이탈)
- 하루 10,000명이 보는 페이지, 경험한 유저의 1% 이탈 (100명 이탈)
위 예시에서는 당장 작업을 해야하는 상황이라면 전자의 작업을 먼저하는것이 임팩트 측면에서 보다 효과적일 수 있습니다.
우리는 작업에 투자되는 노력과 그에 따른 결과를 합리적으로 예측하고 싶어합니다. 실제로 열심히 공을 들였음에도 기대만큼 지표가 개선되지 않았던 사례들을 돌아보면, 임팩트를 미리 예측하지 않았거나 이를 소홀히 했던 경우가 많았습니다. 대부분은 작업의 효율이 높지 않은, 즉 투입 대비 산출이 크지 않은 과업임을 미리 계산했더라면 알 수 있었을 텐데, 그 과정을 생략해버렸던 것이지요. 이러한 경험들을 거치며 사내 구성원들은 자연스럽게 임팩트 추산의 중요성을 체득하게 되고 기획문서 내에도 중요한 부분으로 자리잡게 되었습니다.
비교 가능? 비교가능!
“임팩트 예상”의 중요성에 대해서 모두가 공감하고 있고 높은 온도를 가지고 있으나, 비교를 어떻게 해야할지 감이 잘 안잡히는것 같기도 합니다. 보통 서비스의 개발은 다양한 성격의 기획 및 작업들로 이루어지는데요 이 작업간의 성격이 너무 달라서 어떤 우선순위를 가져가야하는지 애매한 순간들이 있습니다.
1)서비스 내 존재하는 버그를 고치는 작업과 2)특정 화면내 UX/UI 를 개선하는 작업은 같은 성격의 작업이라고 보기는 어렵습니다. 하지만 그럼에도 어떤걸 선제적으로 작업할지 우선순위는 필요하죠. 보편적으로는 “리텐션” 을 통해서 작업의 임팩트를 비교해볼수 있을것 같습니다. 다음과 같은 추산이 가능하다면 비교해볼수 있겠죠?
- A버그를 수정하면 신규 유저의 리텐션이 5% 개선될것
- B화면 UX/UI를 수정하면 신규 유저의 리텐션이 3% 개선될것
문제는, 작업전에 정확한 예측이 어렵다는점 입니다. A,B 작업이 그래서 얼마나 리텐션 개선에 도움이 될지는 실제 해보지 않고서는 알수 없습니다. 실험이라도 하면 좋을텐데 실험을 하기위해서도 결국 개발은 필요하기때문에 리소스가 쓰이게 되죠. 리소스 사용전 기획단계에서 어떤 작업을 먼저할지 우선순위를 결정하는 우리에게는 실험이라는 선택지는 의미가 없습니다.
보통은 기존의 데이터 + 직관을 적당히 조합하여 추정치를 산정합니다(있어보이는 용어로 “페르미 추정” 이라고 하네요).
- A 버그를 겪는 유저들이 N명이고, 버그를 겪은 유저들과 그렇지 않은 유저들의 리텐션 차이가 K%. 따라서 A버그를 해결했을때 P% 만큼의 리텐션이 개선될것
- B 화면을 경험하는 유저들은 K명이고, 이 화면에서 이탈률이 D%. 개선된 UI/UX가 적용되면 과거 비슷 사례 기준으로 W%만큼의 이탈률의 개선이 있을것 -> B화면의 UI/UX 개선으로 E% 만큼의 리텐션이 개선될것.
간단한 예로 설명해봤지만 실제로 비슷한 형태와 구조로 예측을 하는것 같습니다. 임팩트를 비교가능한 숫자로 변환하는것 과 더해서 초기 예측과 사후 실제변화를 비교하는 loop를 만들어서 예측의 정확도를 높이려는 시도들도 중요합니다(저도 하다보니 점점 예측이 실제와 가까워지는것 같더라구요)
DAU로 나타낸 임팩트 비교
현재 서비스의 stat 을 다음과 같이 정의하겠습니다.
- 유저 유입 => 일 평균 5,000명
- 리텐션 Curve => (D0 : 100%, D1 : 50%. D2: 40%, .. D6: 16%)
우리는 N일뒤의 DAU를 예상할수 있습니다.
결국 DAU 라는것은, 일평균 유입자수 x 리텐션 커브의 AUC 로 구해지게 됩니다. 위 예시 기준으로는
- 6일 뒤 DAU : 5,000 * (D0 + D1 + D2 + D3 + D4 + D5 + D6) = 11,700명
- 30일 뒤 DAU : 5,000 (D0+D1+…+ D30)
- 90일 뒤 DAU : 5,000 (D0+D1+……. + D90)
- 365일 뒤 DAU : 5,000 (D0+D1+…………+ D365)
이제 비교 할수 있는 상황을 가정해보겠습니다.
- 현재 일평균 유저유입이 5,000 → 10,000 로 바뀐다면
- 현재 리텐션 커브가 10% 상승한다면
1)현재 일평균 유저유입이 5,000 → 10,000 로 바뀌었을때의 증분
- DAU 증분의 크기 : 10,000(D0+D1+ .. +Dn)-5,000(D0+D1+..+Dn)
2)현재 리텐션 커브가 10% 상승했을때의 증분
- DAU 증분의 크기 : 5,000(D0`+D1`+ .. +Dn`)-5,000(D0+D1+..+Dn)
증분의 크기를 서로 비교해보면 DAU 증분에 어느 레버가 더 임팩트가 클지 예상해볼수 있습니다. 그리고 어떤 전략적인 결정을 하는게 서비스 성장에 더 도움이 될지도 예측해볼수 있구요.
조직에서는 다양한 성격의 작업을 진행하고 있지만, 이들의 궁극적인 목적을 살펴보면 결국 ‘트래픽(DAU)’과 ‘매출’이라는 두 가지 최상위 목표로 귀결됩니다. 얼핏 보면 서로 상관없어 보이는 작업들도 결국 이 상위 메트릭들을 개선하는 데 기여하며, 그 결과 겉보기에 전혀 다른 두 작업조차 상위 메트릭을 기준으로 환원해 비교할 수 있게 됩니다.
리텐션을 상위 지표인 매출로 변환하여 비교한 사례도 재미있습니다. 아래 포스팅을 참고 해보셔도 좋을것 같습니다.(Retention is King ..? by 스테판)
마무리하며
작업의 임팩트를 예측하는 일은 개발과정의 중요한 요소중 하나 입니다. 물론 예측 기법을 고도화하는 것도 필요하지만, 가장 핵심은 ‘예측을 하는 것’ 그 자체입니다. 때로는 바쁘다는 핑계나 직감에 대한 과도한 확신 때문에 작업 효과를 수치화해 살펴보는 과정을 등한시하지 않았는지 돌아볼 필요가 있습니다.
저는 데이터 분석가로서 누구보다 데이터에 쉽게 접근할 수 있는 환경에 있음에도 불구하고, 이런저런 이유로 예측 과정을 소홀히 했던 적이 있습니다. 그 결과 고급 인력의 리소스를 낭비하는 상황이 벌어지기도 했습니다.
결국 예측은 습관화되고 프로세스화되어야 합니다. 분석과 인사이트 도출만큼이나 중요한 작업임을 잊어서는 안 됩니다.
⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다 🙌
