데이터 기반 프로덕트 개발이란? (슬라이드 51장)
지난 달(2021년 9월) AB180과 함께한 '데이터 기반으로 프로덕트를 만든다는 것' 웨비나에서 발표한 내용 중 일부를 공개합니다.
이런 내용들을 다룹니다.
- 데이터 기반으로 프로덕트를 만든다는 것이란?
- 데이터 기반으로 프로덕트를 만들지 않는 팀이 보이는 모습
- 데이터 기반으로 프로덕트를 만드는 팀이 하는 일 5가지
그럼 잘 읽어 주세요. :)
데이터를 기반으로 프로덕트를 만든다는 건 무엇일까요?
크게 보면 두 가지입니다.
하나는 프로덕트를 만들기 전에, 기능을 개발하기 전에, 먼저 데이터를 분석해서 문제나 기회를 찾아내서, 그걸 갖고 프로덕트를 만드는 것입니다.
다른 하나는 프로덕트를 만들고, 기능을 개발한 뒤에, 데이터를 분석해서 우리가 프로덕트를 제대로 만들었는지 평가하고 개선하는 것입니다.
다시 말하면 프로덕트를 만들기 전과 후에 데이터를 활용하는 것이라고 할 수 있습니다.
이런 얘기를 하면, 다들 '당연히 그렇게 데이터를 기반으로 프로덕트를 만들어야지' 하고 생각할 것입니다. 너무 기본으로 들리는 것들이니까요.
하지만 제 경험에서는 그 당연한 것을 당연하게 실천하지 않는 경우도 꽤 있었습니다. 어쩌면 기본을 알고 있다고 머리로만 생각하는 것과, 그 기본을 꾸준하게 잘 지키는 습관과 규율(discipline)을 가지는 것은 다른 것 같습니다.
데이터 기반 프로덕트 개발에 대해 조금 더 부연설명하기 전에, 데이터 기반으로 프로덕트를 만들지 않는 경우는 어떤 경우가 있는지 살펴보겠습니다.
말로는 ‘우리는 데이터를 활용한다’라고 말하는 팀들 중에도 실상을 살펴 보면 이런 경우들이 일어나곤 합니다. 프로덕트를 만드는 일을 일을 하시는 분들이라면 우리 팀이 여기에 해당하지는 않는지 한번 생각해 보시면 좋겠습니다.
하나는 위에서 결정한 기능 로드맵에 따라서 프로덕트 팀이 기획과 개발을 하는 경우입니다.
언제까지 뭘 만들어야 하고, 언제까지 뭘 만들어야 하고. 일단 의사결정권자가 기획이나 개발 담당 팀에 떨어뜨려 주는 데드라인에 따라서. 그냥 바쁘게 개발하는 경우입니다.
로드맵을 정할 때도 데이터를 활용해서 문제와 기회를 발견하기보다는, '이런 기능 있어야 하지 않나?' 하고 생각해서 정합니다. 직관, 혹은 감으로 하는 거죠.
물론 직관은 프로덕트를 만드는 사람들에게 중요한 툴입니다. 창의적인 솔루션은 직관에서 나올 수밖에 없으니까요. 하지만 직관을 데이터로 검증하지 않으면 그것은 문제입니다.
로드맵을 세운 것까지는 좋다고 쳐도, 중간 중간 데이터를 점검하면서 지금 이 기능이 정말 우선순위가 높고 필요한 기능인지 판단해서 로드맵을 조정해야 하는데, 그렇게 하지 않고 '위에서 정해진 로드맵이니까. 계획을 바꾸자고 하려면 대표나 리더들을 설득해야 하고, 그러면 골치 아프니까' 그냥 정해진 대로 개발하는 경우도 있습니다.
또 다른 경우는 경쟁사가 하는 것을 따라하는 경우입니다.
경쟁사가 뭔가를 하면, 괜히 위기의식을 느끼고 우리도 따라하게 되는 건데, 이것도 회사 생활을 하다 보면 자주 있는 일이죠.
물론 프로덕트를 만드는 분들은 경쟁사가 뭔가 한다고 따라하는 걸 싫어합니다. 주로 대표님들이 '경쟁사에서는 이런 거 하는데 우리도 해야 되지 않냐' 하고 압박을 넣어서 만드는 경우가 있습니다.
프로덕트나 기능을 만들고 나서 데이터를 활용하지 않는 경우는 어떤 경우가 있을까요?
가장 대표적인 것은 기능을 만들고 나서 지표를 추적하지 않는 경우입니다.
아까 언급했던, 로드맵에 따라서 일정에 쫓겨 급하게 프로덕트를 개발하는 팀이 빠지기 쉬운 함정입니다. 일단 기능을 개발해서 배포하면 끝이고, 기획자와 개발자는 다음 기능 기획과 개발로 바쁘게 넘어가게 되는 건데, 이런 경우가 진짜 많습니다.
한 팀이 프로덕트를 전담하는 방식이 아니라, 프로젝트 단위로 기획자 디자이너 개발자가 모였다가 프로젝트가 끝나면 흩어지는 방식으로 일하는 팀에서도 이런 일이 비일비재하게 일어납니다. 보통은 기능을 개발해서 배포하는 것까지만 프로젝트의 scope으로 생각하기 때문에, 이후 몇 주 몇 달에 걸쳐서 지표를 추적하는 것까지는 하지 않는 거죠.
이와 쌍으로 따라붙는 것이 사전에 데이터 활용 계획을 세우지 않는 것입니다. 성공 지표와 가드레일 지표 등에 대해 사전에 계획하지도 추적하지도 않는 거죠.
성공 지표란 프로덕트나 기능이 목표를 달성했는지, 성공적인지 나타내는 지표입니다. 예를 들어 매출을 높이기 위한 기능을 개발한 경우 구매 전환율이 높아지는 것이 성공 지표일 것이고, 인게이지먼트를 높이기 위한 기능을 개발한 경우 사용자들이 더 많은 시간을 프로덕트에서 보내게 되는 것이 성공 지표가 될 수 있습니다.
가드레일 지표란, 기능이 의도치 않게 프로덕트나 사업에 악영향을 주지 않았는지를 파악할 수 있게 해 주는 지표입니다. 구매를 유도하는 요소를 잔뜩 넣어서 구매 전환율은 높아졌는데 사용성이 나빠져서 덜 자주 들어오게 된다든지, 재구매율이 낮아진다든지 하면 성공적이라고만 볼 수는 없겠죠. 이런 부작용을 체크하기 위해서 보는 지표가 가드레일 지표입니다.
보통은 기능을 만들고 나서, 1주일이면 1주일, 2주일이면 2주일 정도 초반 기간 동안 그 기능을 몇 명이 이용했는지, feature adoption(기능을 한 번이라도 이용하는 사람 수) 정도만 체크하고 끝나는 경우가 많습니다. 더 긴 기간 동안 사람들이 기능을 얼마나 다시 이용하는지 feature retention을 추적하지 않는 거죠.
Feature retention은 기능이 실제로 사용자들에게 가치를 주는지 여부를 보여주기 때문에 중요한 지표인데. 체크 안 하는 경우가 많습니다. 아까 말씀드린 것처럼 프로젝트 단위로 사람들이 모였다 흩어졌다 하는 팀, 또는 로드맵에 따라 바쁘게 개발해 내는 팀이 빠지기 쉬운 함정입니다.
그럼 데이터 기반으로 프로덕트를 만드는 팀은 무엇을 할까요? 크게 다섯 가지를 생각해 볼 수 있습니다.
1번. 데이터를 수집하고 저장한다.
2번. 주요 지표를 설정하고, 프로덕트 팀이 실행하는 것들이 어떻게 해서 지표에 영향을 주는지 인풋 아웃풋 관계를 이해한다.
3번. 대시보드와 시각화를 통해 팀이 항상 데이터를 본다.
4번. 실험 기반으로 프로덕트를 만든다. 실험의 임팩트를 데이터로 측정한다.
5번. 데이터를 심층 분석하고, 이를 프로덕트 전략을 세우는 데 활용한다.
물론 데이터를 활용해서 추천 알고리즘을 만든다든지, 아니면 사기 거래를 감지하는 fraud detection을 한다든지 하는 식으로 데이터 프로덕트를 만드는 것도 있지만... 이건 product analytics와는 다른 영역의 일이기도 하고, 제가 잘 아는 분야가 아니기도 해서 오늘 발표에서는 다루지 않겠습니다.
그럼 다섯 가지에 대해서 하나 하나 설명해 보겠습니다. 첫 번째는 데이터 수집과 저장입니다.
데이터 기반으로 일하는 데 있어서 가장 기본이 되는 것입니다. 특히 프로덕트를 만드는 사람들에게 중요한 것은 일반적으로 저장하는 데이터인 회원가입, 탈퇴, 구매 등의 데이터뿐 아니라, 사용자들이 우리 프로덕트 위에서 언제 어떤 행동을 하는지에 대한 데이터(사용자 행동 데이터, user behavior data)입니다.
하지만 사용자 행동 데이터를 제대로 기록하지 않는 팀도 굉장히 많습니다. 이런 팀에서는 아무리 좋은 데이터 분석가가 있다 하더라도 데이터 자체가 없으니 분석을 할 수 없습니다.
사용자들이 어떤 행동을 하는지 알아야 프로덕트의 어디를 어떻게 개선하면 좋을지 기회를 발견할 수 있고, 또 사용자들이 어떤 행동을 하는지 알아야 프로덕트를 개발하고 나서 이게 의도대로 잘 작동하는지 알 수 있기 때문에, 이벤트 데이터를 잘 수집하고 저장하는 것은 중요합니다.
이런 면에서 Amplitude나 Mixpanel과 같은 애널리틱스 툴이 도움이 될 수 있습니다. 특히 데이터 인프라가 잘 갖춰져 있지 않은 스타트업의 경우, 이벤트 데이터를 일일이 수집하고 저장해서 분석하는 환경을 갖추는 게 기술적으로 까다로울 수 있기 때문입니다.
데이터 기반으로 프로덕트를 만드는 팀이 하는 일 5가지 중 두 번째, 주요 지표를 설정하고 지표의 인풋(input)과 아웃풋(output) 관계를 파악하는 것입니다.
주요 지표를 설정한다는 것은, 프로덕트 팀이 특히 중요하게 생각해야 할 지표들을 설정해야 한다는 것입니다.
특히 데이터 기반으로 프로덕트를 개발하는 팀은 매출과 같은 사업 지표와는 별도로, 프로덕트 관점에서 꼭 봐야 하는 지표가 무엇인지 이해합니다. 프로덕트를 사용자들이 얼마만큼 활발히 이용하고 있는지 알 수 있는 인게이지먼트(engagement) 지표, 얼마나 꾸준히 이용하는지 알 수 있는 리텐션(retention) 지표, 얼마만큼 사용자들이 프로덕트에서 가치를 얻어가고 있는지 알 수 있는 지표 등을 설정하는 것입니다.
North Star Metric(NSM)이라는 개념이 있는데, 관심 있는 분들은 Amplitude에서 발행한 North Star Playbook을 공부해 보시길 추천해 드립니다. 우리의 핵심 지표를 어떻게 설정해야 하는지를 알 수 있고, 이를 위한 워크샵을 어떻게 준비하고 운영해야 하는지도 알 수 있습니다. 굉장히 잘 만든 자료입니다.
인풋(input) 아웃풋(output) 관계를 이해한다는 것은, 프로덕트 팀이 개발하는 기능이 어떻게 지표에 영향을 끼치는지를 이해하고, 그에 따라서 지표 개선을 위해 무엇을 실행해야 할지 이해한다는 뜻입니다.
추상적으로 느껴질 수 있을 같아서, 바로 예를 들어서 설명해 볼게요.
올해 제 목표가 연봉 상승이라고 해 볼게요. 연봉이 제 핵심 지표, KPI입니다. 그런데 만약 제가 의자에 앉아서 그냥 '연봉을 어떻게 늘리지?’ 하고만 생각하면 너무 막연합니다. 구체적인 개선안이 나오기 힘들죠.
그보다는 연봉에 영향을 끼치는 세부 요인을 정의하고, 그 세부 요인을 움직이는 방향으로 생각하는 것이 좋습니다.
연봉은 어떤 업계에서 일하는지에 따라서도 달라질 수 있겠죠. 같은 업계라도 어느 회사에서 일하느냐에 따라서도 달라지고, 같은 회사에서도 직무 분야에 따라 달라지고, 그 안에서 내가 얼마나 높은 수준의 기술을 보유했는지에 따라서도 달라질 것이고, 인사권자의 평가를 얼마나 잘 받는지에 따라서도 달라질 것이고, 그리고 그 안에서 얼마나 잘 협상하는지에 따라서도 달라질 수 있겠죠.
여기서 연봉은 세부 요인들이 작용해서 나타난 결과물입니다. 이런 결과물을 아웃풋이라고 하구요.
업계, 회사, 직무 분야, 기술 수준, 인사권자의 평가, 협상력 등 결과물에 영향을 끼치는 세부 요인들을 인풋이라고 부릅니다.
이렇게 아웃풋과 인풋을 정의하고 나면, 저는 연봉이라는 아웃풋을 움직이기 위해서, 어느 인풋을 어떻게 변화시킬 것인지 좀 더 구체적인 아이디어를 낼 수 있습니다. 그냥 ‘연봉을 어떻게 늘리지’ 하고 막연하게 생각할 때보다 더 구체적인 아이디어가 나올 수 있는 거죠.
프로덕트로 초점을 옮겨서 아웃풋과 인풋을 생각해 보겠습니다.
프로덕트 그로스에서 리텐션, 즉 사용자 유지는 굉장히 중요합니다. 리텐션이 받쳐주지 않고 사용자가 줄줄이 이탈하면 밑빠진 독에 물붓기처럼 성장하기가 어렵죠.
그런데, 리텐션 지표 개선에 접근할 때 막연히
- ‘리텐션은 곧 재방문, 재구매.
- 사용자들을 재방문하게 만들고 재구매하게 만들어야 되니까 푸시 메시지를 쏘자.
라는 식으로 접근할 때가 많습니다.
물론 그것도 리텐션을 조금이나마 높이는 방법이 될 수는 있지만, 우리는 충분히 이것보다 더 똑똑하게 일할 수 있습니다. 리텐션이라는 목표 결과를 아웃풋(output)으로 생각하고, 그 아웃풋에 영향을 미치는 인풋(input)들이 무엇인지 정의해 보는 거죠.
이건 그로스를 하는 사람들 사이에서 정설처럼 받아들여지는 것인데, 리텐션의 주요 인풋(input)은 activation과 engagement, 그리고 resurrection입니다.
- Activation은 활성화라는 뜻인데, 그냥 회원 가입해서 접속만 한다고 활성화가 아니고, 사용자들이 빠르게 프로덕트의 핵심 가치를 경험하고 프로덕트를 이용하는 습관을 들이는 것을 뜻합니다.
- Engagement는 그렇게 활성화된 사용자들이 꾸준히 프로덕트를 이용하는 것을 뜻하구요.
- Resurrection은 부활이라는 뜻인데, 활성화되고 인게이지 되었다가 어느 순간 이용이 잠잠해지거나 이탈해 버린 사용자들을 다시 데려오는 것을 가리킵니다.
Activation과 Engagement, Resurrection 세 가지 인풋(input)을 움직이면 아웃풋(output)인 리텐션도 변화하게 됩니다.
여기서 중요한 건, 우리는 Output인 리텐션을 직접 최적화할 수는 없다는 것입니다. 리텐션(재방문, 재구매 등) 지표를 직접적으로 최적화하려고 들면 아까 안 좋은 사례에서 예로 들었던 '푸시 메시지를 보내서 유저들이 재방문하게 만들자' 정도의 효과적이지 않은 아이디어만 나오게 됩니다.
리텐션의 인풋(input)들을 최적화해서 아웃풋(ouptut)인 리텐션에 영향을 끼쳐야 합니다.
이렇게 인풋을 정의하고 나면, 그냥 ‘리텐션을 어떻게 올리지? 사람들에게 푸시를 쏴서 재방문하게 만들자’ 하고 막연하게 생각할 때보다 훨씬 더 구체적인 액션 아이템들을 생각해 내기 좋습니다. Activation을 위해 사용자 온보딩을 개선하자든지, 초반에 이용을 습관화하기 위한 행동 보상을 설계한다든지 하는 식으로요.
물론 이렇게 아웃풋과 인풋을 나눈다고 하더라도 조금 막연할 수 있습니다. 인풋은 아직 실제로 프로덕트에서 하는 액션 아이템 수준으로 구체적인 개념은 아니니까요.
이런 아웃풋과 인풋에서 시작해서, 구체적인 액션 아이템으로 내려가는 데 있어서 유용한 접근법이 opportunity와 solution을 나눠서 생각하는 것입니다. 프로덕트 코치로 활동하고 있는 Teresa Torres가 제안하는 방법이기도 한데요.
많은 사람들이 이런 식으로, 원하는 결과가 있을 때 바로 아이디어를 내곤 합니다. Activation을 개선해야 한다는 과제가 있으면, 즉각 '온보딩 화면을 새로 만들자' 같은 아이디어를 던지는 거죠.
그런데 이렇게 바로바로 떠오르는 아이디어가 좋은 아이디어인 경우는 별로 없습니다. 이렇게 하기보다는, 조금 더 기회 영역을 세부적으로 정의하면 좋은 아이디어들을 낼 수 있습니다.
Opportunity란 앞에서(output과 input 관계를 파악해야 한다고 하면서) 언급한 인풋을 변화시키기 위해 해결해야 하는 문제, 또는 활용할 수 있는 기회 영역을 뜻합니다. 구체적인 액션 아이템보다는 조금 더 추상적인 상위 레벨의 개념인데요.
예를 들어 볼게요. 아까 리텐션의 주요 인풋 중 하나가 activation이라고 말씀드렸는데요. Activation은 (다시 설명하자면) 사용자들이 빠르게 프로덕트의 핵심 가치를 경험하고 프로덕트를 이용하는 습관을 들이는 것을 뜻합니다.
그럼 이 activation을 어떻게 하면 높일 수 있을까요? 초반에 핵심 가치를 경험하게 만드는 것이니까, 이런 식으로 접근할 수 있을 겁니다.
만약 제품 사용법이 어려운 것이 문제라서 초반에 사용자들이 핵심 가치를 경험하지 못하고 있다면,
- ‘제품 기능을 단순화해서 사용하기 쉽게 만드는 것’이 방법이 될 수 있고,
- ‘초반에 제품 사용법을 설명해 주는 것’이 방법이 될 수도 있습니다.
- 관점을 바꿔서 제품 사용법이 어렵더라도 사용자들이 극복할수 있게끔 모티베이션을 넣어 주는 것이 방법이 될 수도 있습니다. 성공적으로 제품을 이용하고 있는 사람들이 얼마나 큰 효용을 얻고 있는지 보여준다든지요.
여기서 ‘제품 기능을 사용하기 쉽게 만든다’, ‘제품 사용법을 설명해 준다’, ‘모티베이션을 넣어 준다’ 같은 것들이 기회 영역, 즉 opportunity라고 할 수 있습니다. 이런 기회 영역을 잘 활용하면 activation을 개선할 수 있게 되니까요.
그림으로 그려 보면 이런 식입니다. 우리가 개선하고자 하는 결과에서 시작해서 문제와 기회들을 트리(tree) 구조로 그려 볼 수 있습니다.
아웃풋과 인풋 관계를 파악하는 데서 시작해서 인풋을 변화시키기 위한 기회 영역까지 정의하고 나면, 드디어 프로덕트에서 실행할 구체적인 액션 아이템을 정의할 시간입니다. 이 구체적인 액션 아이템을 solution이라고 부릅니다.
결과와 opportunity, 그리고 solution은 이런 식으로 도식화 해 볼 수 있습니다.
예를 들어 초반에 제품 사용법을 설명해 준다는 opportunity가 있을 때, 이걸 제품 상에서 구체적으로 구현하는 방법은 여러 가지가 있을 겁니다.
- 신규 가입한 사용자에게 제품 사용법을 비디오로 보여줄 수도 있고,
- 아니면 툴팁 같은 걸로 사용 방법을 설명해 주는 것이 방법이 될 수도 있습니다.
이런 구체적인 액션 아이템이 바로 Solution입니다.
좀 더 구조화시키면 이렇게 여러 갈래의 트리 구조를 가진 구조를 만들 수 있습니다.
- ‘사용법이 어렵다’라는 것이 상위 opportunity가 되고,
- 그 밑에 ‘초반에 제품 사용법을 알려준다’, ‘기능을 더 쉽게 사용하게 만들어 준다’, ‘사용법이 어려워도 학습할 수 있게끔 모티베이션을 제공한다’ 같은 것들이 하위 opportunity로 들어갈 수 있는 거죠. 거기서 더 구체적으로 하위 opportunity들을 정의할 수도 있을 거구요. 트리(tree) 구조로 가지를 뻗어 나갈 수 있습니다.
이렇게 프로덕트에서 원하는 결과에 어떻게 다다를 수 있는지, 쪼개서 생각하고 구조화하는 것이 제가 프로덕트 일을 하는 사람으로서 중요하게 여기는 생각법입니다. 오늘 발표에서 다른 건 다 잊어도, Output-Input-Opportunity-Solution 프레임워크 하나는 기억해 주시면 좋겠습니다.
데이터 기반으로 프로덕트를 만드는 팀이 하는 5가지 중 세 번째, 대시보드와 시각화를 통해 팀이 항상 데이터를 본다 입니다.
데이터 기반으로 프로덕트를 만드는 팀은 데이터가 필요할 때마다 매번 분석가에게 의뢰하는 식으로 일하지 않고, 구성원들이 주요 지표를 모니터링하고 데이터를 볼 수 있는 도구(대시보드)를 가지고 있습니다. 그리고 구성원들이 이런 도구에 굉장히 쉽게 접근할 수 있습니다.
아무리 주요 지표를 설정한다 한들, 데이터를 쉽게 볼 수 없으면 활용하기도 어려워집니다. 특히 매번 별도의 데이터 분석가에게 의뢰해야만 하는 팀은 더더욱 그렇습니다. 분석가에게 요청해서 데이터를 받는 데까지는 시간이 걸리기 때문에, 의사결정 속도가 느려질 수밖에 없습니다. 반대로 팀이 직접 데이터를 볼 수 있다면, 의사결정 속도는 그만큼 빨라집니다.
대시보드는 꼭 거창한 것일 필요가 없습니다. 누구나 쓸 수 있는 구글 스프레드시트를 활용해서 대시보드를 만들 수도 있습니다. 혹은 Amplitude, Mixpanel 등 애널리틱스 툴의 대시보드를 이용할 수도 있습니다.
여기서 한발짝 더 나아간 팀들은 더 고도화된 대시보드를 만들기 위한 데이터 인프라스트럭쳐를 갖추기도 합니다.
대용량의 데이터를 저장할 수 있는 데이터 웨어하우스를 갖추고, 수많은 데이터 소스에서 데이터를 추출해서, 적절한 형태로 변환해서 저장하는 엔지니어링을 하고, 태블로 같은 비즈니스 인텔리전스 툴을 이용해서 데이터를 분석합니다.
하지만 이제 막 시작하는 팀이라면 이 수준까지 고민할 필요까진 없습니다. 일단 중요한 지표와 데이터를 한 눈에 볼 수 있는 대시보드와 시각화부터 시작하면 됩니다.
5가지 중 네 번째, 실험 기반으로 프로덕트를 만들기입니다.
실험이란 프로덕트에 대한 가설을 세우고, 가설을 확인하기 위해 실험을 설계하고, 이에 따라 실험을 하고, 그 결과를 데이터로 측정하는 것을 뜻합니다. (실험에 대해 자세히 알고 싶은 분들은 이 글을 참고해 주세요.)
만약 트래픽이 충분히 많은 팀이라면 A/B 테스트를 하면서 통계적으로 의미 있는 결과를 뽑아낼 수 있을 것입니다. 그렇지 않은 팀이라 하더라도 실험을 설계하고, 데이터로 실험 결과를 측정하는 것은 필수입니다.
실험을 진행하는 각 단계에서 데이터를 활용하게 됩니다.
- 가설을 세울 때도 기존에 측정한 데이터를 가지고 가설을 세우고,
- 실험을 설계할 때 역시 샘플 사이즈와 실험 기간을 정할 때 데이터를 활용하고, 어떤 데이터를 측정할지 미리 설계하고
- 실험을 진행하면서는 결과 측정에 필요한 데이터를 수집하고,
- 결과를 측정할 때는 당연히 데이터를 분석해야겠죠.
이렇게 모든 단계에서 데이터를 활용하면서 실험을 설계하고 진행하는 것은, 데이터 기반으로 프로덕트를 만드는 데 있어서 상당히 높은 수준에 올라온 팀들이 하는 일입니다.
5가지 중 마지막 다섯 번째, 데이터를 심층 분석하고, 이를 프로덕트 전략을 세우는 데 활용한다 입니다.
데이터 기반으로 프로덕트를 만드는 팀은 사용자를 세세히 세그멘테이션(segmentation)하고, 집요하게 데이터를 쪼개서 분석하고, 그 결과를 프로덕트 전략에 활용합니다.
예를 들어 사용자들이 프로덕트를 이용하는 평균 시간이 감소했다고 해 보겠습니다. 이런 현상이 있을 때, 사용자들을 세세히 쪼개서 어느 사용자 세그먼트(user segment)가 특히 지표 감소에 영향을 끼쳤는지 볼 수 있습니다.
사용자 세그멘테이션은 유입 채널에 따라서, 가입 시점에 따라서, 특정 기능을 이용했는지 하지 않았는지 여부에 따라서, 혹은 특정 기능을 몇회 이상 이용했는지 여부에 따라서 등등 다양한 기준으로 해 볼 수 있습니다.
데이터 분석에서 '분석(分析, analysis)'이라는 말 자체가 뭔가 큰 것을 세부 요소들로 잘게 쪼개어서 들여다 보는 것을 뜻합니다. 이렇게 잘게 쪼개서 분석하다 보면 지표 변화의 원인을 찾을 수 있게 됩니다.
그리고 이런 분석 결과를 그냥 분석 보고서에만 담고 끝내는 게 아니라, 프로덕트 의사 결정에 반영하는 것이 중요합니다. 이를 위해서는 의사결정을 할 때 항상 근거 자료를 바탕으로 하는 문화가 있어야 하겠죠.
이렇게 근거 기반 의사결정 문화를 갖추는 게 기본적인 것 같지만 사실은 제일 어렵고, 그래서 저는 이런 팀들이 데이터 활용을 높은 수준으로 하는 팀이라고 생각합니다.
다시 한 번, 데이터 기반 프로덕트 개발을 하는 팀들이 무엇을 하는지 다섯 가지를 꼭 기억해 주시고, 이 글을 읽는 분들이 팀에 적용하실 수 있으면 좋겠습니다.
사족이지만, 혹시라도 데이터가 만능이라는 생각을 하지는 않으셨으면 합니다. 정량적 데이터(quantitative data)가 있으면 고객 리뷰나 고객 인터뷰 같은 정성적(qualitative) 자료는 필요 없다고 생각한다든지, 데이터 기반 프로덕트 개발에서는 직관(intuition)의 자리는 없다고 생각한다든지 할 수 있는데... 그렇지 않습니다.
왜냐면 정량적 데이터로 우리가 할 수 있는 일에는 한계가 있기 때문입니다. 정량적 데이터로 할 수 있는 일은 크게 보면 딱 두 가지입니다.
하나는 현황을 파악하는 것입니다. 과거에, 그리고 지금 무슨 일이 일어나고 있는지 파악하는 것이죠.
다른 하나는 (분석 수준이 높은 팀, 그리고 데이터가 많은 팀에서 할 수 있는) 과거 데이터를 기반으로 앞으로 무슨 일이 일어날지 예측하는 것입니다. 이를 예측 분석(predictive analytics)이라고 합니다.
하지만 정량적 데이터가 답을 주지 않는 것들이 있습니다.
현황 분석을 해서 무슨 일이 일어나는지(what)를 데이터로 파악할 수 있지만, 그 일이 왜 일어나는지(why)는 데이터가 알려주지 않습니다. 특정 사용자 세그먼트가 이탈한다는 현상은 데이터가 보여주지만, 그 사용자들이 왜 이탈하는지는 데이터가 보여주지 않습니다. Why를 알기 위해서는 고객 리뷰, 인터뷰 등 정성적(qualitative) 자료가 필요합니다.
그리고 현황 분석과 예측 분석을 해서 '지금 이런 일이 일어나고 있고, 앞으로 이런 일이 일어날 것이다'라는 것을 안다고 하더라도, '그래서 프로덕트 팀이 무엇을 만들어야 할까? 어디를 어떻게 고쳐야 할까?'에 대한 답은 얻을 수 업습니다. 데이터는 문제나 기회 영역이 어디인지는 보여줄 수 있지만, 구체적인 솔루션은 사람이 생각해야 합니다. 구체적인 솔루션은 전적으로 직관과 디자인의 영역입니다.
안내: 프로덕트 조직과 개인을 위한 코칭
프로덕트 조직, 혹은 개인(제품 리더, PM, PO 등)을 대상으로 한 코칭을 제공하고 있습니다. 아래 이야기들이 내 얘기로 느껴지는 분들께 도움을 드립니다. 자세한 내용은 링크된 페이지를 참고해주세요.
- 제품에서 해야 할 일들은 쏟아지는데, 어떤 기준으로 우선순위를 설정하면 좋을지 답을 내리지 못하고 있다. 명확한 방향성이 없이 그때 그때 급한 일을 쳐내는 식으로 일하고 있다.
- 지표를 개선해야 하는데, 어떤 식으로 접근해야 할지 모르겠다. 어떤 지표를 봐야 좋을지 모르겠다.
- 조직에 큰 영향을 끼칠 수 있는 의사결정을 해야 하는데, 하나를 택하면 포기해야 하는 것도 명확해서 쉽게 결정을 내리지 못하고 있다. 이로 인해 리더로서 자신감이 떨어진다.
- 제품 조직과 다른 부서 간 의견 차이와 갈등이 있다. 다른 조직의 입김 때문에 제품 조직이 꼭 필요한 일을 제대로 수행하기 어렵다.
Member discussion