첫 프로덕트 오너 경험 레슨런 — Setting a Standard for Product Building Pace
Intro
지난 6개월 동안 PO (Product Owner) 로 일하면서 두가지 제품에서 30개 이상의 프로젝트들을 빠른 주기 안에 실행하고 product growth 에 있어 trial, error, 그리고 impact 를 팀 멤버들과 함께 경험해볼 수 있었습니다.
- 2Q 에는 Search & Discovery 제품의 MAU 를 높이는 제품 팀을 맡았었습니다.
- 3Q 에는 Habit 이라는 제품 팀을 맡아, Aha Moment 를 경험한 유저들의 습관을 형성하는 일에 집중했습니다.
뛰어난 동료들 덕분에 설정한 MAU KR(Key Result) 이나 Retention KR 들을 달성하고 제품을 개선하는 경험을 할 수 있었습니다.
제품 임팩트가 났을 때 느껴지는 기쁨 속에서 프로덕트 오너 라는 제가 전부터 구상했던 커리어 패스에 대한 제 마음은 더 굳건해졌습니다.
하지만 더 좋은 프로덕트 오너가 되기 위해 필요한 것들에 대해 배움이 쌓일수록 고민 또한 깊어져갔습니다.
겸직해온 PO (Product Owner) 역할과 DA (Data Analyst) 역할 사이에서 선택과 집중이 결국 필요하다고 판단했고, 고민 끝에 저는 더 강한 데이터 백그라운드를 둔 PO 로 성장하기 위해 DA 의 역할에 다시 집중을 하기로 했습니다.
오늘의 글은 다시 프로덕트 오너 역할을 하게 될 미래의 제 자신을 위한 제품 빌딩 배움을 정리한 글이기도 하면서, 제가 왜 DA 역할에 다시 집중하기로 결정했는지에 대한 글입니다.
아래의 분들에게 도움이 될 것 같습니다.
- 미래의 제 자신
- 데이터 분석에 강점을 둔 PM/PO 가 되시려 하는 분들
- 목적조직에서 DA 역량의 중요성이 궁금하신 분들
- 주니어 PM/PO 분들
💡 Lesson : 아이디어 실험하지 않기
PO 경험을 통해 “아이디어”를 경계하게 되었습니다.
많은 팀들은 백로그 확보를 위해 혹은 문화적인 이유로 아이디어를 주고받고 제품에 반영할 때가 많은데요, 구성원들의 아이디어가 제품에 반영되는 것은 구성원들의 동기부여 상승에 큰 효과를 줄 수 있습니다. 구성원들의 성공경험, VoC, 그리고 데이터 인사이트를 기반한 아이디어를 통해서 임팩트가 높은 성공률을 지니고 창출되는 경우들도 있습니다.
하지만, 속도와 배움축적을 중요시한다면 아이디어로 백로그를 쌓는 행위 자체는 경계할 필요는 있다고 생각합니다.
왜 사람들은 아이디어를 찾을까?
흔히 사람들이 아이디어라고 부르는 것들은 새로운 기능의 출시를 의미할 때가 많고 필요한 지표상승을 이뤄낼 것 같은 참신한 생각을 아이디어라고 부르는 것 같습니다.
**MVP (Minimum Viable Product) 만들기와 BML (Build-Measure-Learn) 순환루프를 기반으로 둔 Eric Ries 의 린스타트업을 추구하는 경험을 바탕으로 나온 이야기임을 미리 공유합니다.
Eric Ries 의 린 스타트업 에서 설명하는 BML 루프에서도 아이디어를 주요항목으로 다루고 Sean Ellis 의 그로스 해킹 루프도 Eric Ries 의 내용을 토대로 하면서 아이디어를 주요항목으로 다룹니다.
다만 빠른 순환을 중요시 하는 BML 루프에서의 “아이디어” 는
우리가 흔히 생각하는 “~ 이런거 있으면 어떨까요? 좋지 않을까요?” 의 참신한 생각이 아닙니다.
실제로 Eric Ries 가 이야기하는 BML 루프를 실천하기 위해서는
“아이디어” 를 MVP 형태로 만드는 것이 아니라
“가설”을 MVP 로 만들어야합니다.
어떤 아이디어들을 경계해야할까?
제가 경계하는 아이디어는 가설의 형태로 변환될 수 없는 아이디어 들입니다.
다시말해, 해결하고자 하는 고객의 문제가 없는 아이디어를 의미합니다.
고객의 문제해결을 하지 않는 아이디어는 일반적으로 결과물을 통한 부가적인 가치제공에 집중을 합니다. 다시말해, 새로운 기능추가를 통해 지표변화를 보고자 합니다.
이런 아이디어를 MVP 로 구현하는 것에서 크게 두가지 문제를 경험했습니다.
첫번째, 고객의 문제해결을 하지 않는 아이디어는 빠르게 실행하기 어렵습니다.
- 문제원인을 실험하는 것이 아니라 결과물을 실험하고자 하기 때문에 어떤 디자인 디테일이 스펙아웃 될 수 있는지 명확한 기준점이 없습니다.
- 따라서 챙겨야하는 디자인 디테일 혹은 퍼널단계가 굉장히 많아 MVP 로 만든다 하더라도 제품 구현 시간이 상당히 많이 소비됩니다. 결과적으로 성공여부나 확률이 높지 않은 상태에서 큰 리소스를 리스킹 (risking) 하게 됩니다.
두번째, 고객의 문제해결을 하지 않는 아이디어는 배움축적이 가능한 형태가 아닙니다.
- 부가가치를 통해 지표상승을 이룰 수 있을 것이라는 가정을 (assumption) 하는 경우가 많습니다.
- 잘못되거나 범위가 너무 넓은 가정으로 지표상승을 이룬다 하더라도 우리 고객에 대해서 알게 되는 것이 딱히 없고 이터레이션에 적용할 수 있는 배움이 없습니다.
🤓 “A 라는 기능 유용할 것 같은데, 내면 유저들의 리텐션이 높아지지 않을까?”
→ 😲 “A 라는 기능에 노출된 유저는 노출되지 않은 유저보다 리텐션이 높아졌다!”
→ 🤔 “왜? 유용하면 사람들이 더 자주 쓰려 하니깐!
→ 😬 “이터레이션 방향? 더 유용하게 만들면 되지 않을까…?”
MVP 방법론을 도입해 BML 루프로 제품을 만들어나갈 것이라면
MVP 의 핵심을 잊어서는 안됩니다.
- MVP 구성의 핵심 :
가설을 가장 정확하게 검증할 수 있는 방법으로 기획하되,
가설을 검증하는데에 도움이 되지 않는 요소들은 철저히 배제하기 - MVP 활용의 핵심 :
MVP 에서 얻은 배움들을 제품에 적용해 이터레이션을 거듭하면서
우리 고객이 가치를 경험하는 원리에 대한 퍼즐조각들을 알아가기
“Garbage in, garbage out” 이라는 표현이 있죠.
MVP 의 핵심을 망각한 아이디어, 혹은 low-quality 가설이 제품 빌딩 프로세스에 들어갈 경우에 BML 방법론은 효과적으로 working 하지 않습니다.
High quality 가설이 MVP 의 핵심을 담아내게 되고,
BML 방법론으로 승리하는 방법이라는 배움을 공유합니다.
🔄 Lesson : 데이터 활용 페이스메이커 — 백로그 품질
PO 경험을 통해 제품 백로그 관리의 중요성을 알게 되었습니다.
잘 관리된 제품 백로그의 기준과 핵심에는
제품 팀의 데이터 활용 페이스가 핵심이라는 것도 배웠습니다.
좋은 백로그란?
우선 백로그는 단순히 할 것들 혹은 해야하는데 하지 못한 것들을 모아둔 To-Do 리스트를 의미하지 않습니다.
백로그는 고객의 문제해결을 위해서 리소스를 써야하는 액션플랜 명단을 의미한다고 생각합니다.
그리고 백로그에 있는 각 액션플랜은 제품개발 프로세스와 OKR 임팩트가 함께 고려된 우선순위도 함께 동반합니다. 우선순위 배정 방법의 한가지 예시로는 ICE (Impact-Confidence-Ease) 스코어링 모델이 있습니다.
백로그를 쌓아가는 일은 팀이 함께 오너십을 가져가고자 했습니다.
백로그를 쌓을 때는 팀의 데이터 분석을 통한 제품 인사이트 (정량적 데이터) , 유저 VoC 인사이트 (정성적 데이터) 가 가장 성공확률이 높은 액션플랜 들을 수립하는데에 도움이 되었습니다. 액셔너블한 인사이트들을 기반으로 가설을 함께 도출하고 축구선수 후보단을 꾸리듯이 액션플랜 명단을 만들어갔습니다.
반대로, 백로그의 축적속도와 품질에 대한 책임은 전적으로 프로덕트 오너에게 있습니다.
팀 리소스가 효율적으로 운영되기 위해서는 백로그를 쌓아가는 일과 백로그를 실행하는 타이밍은 동시에 이뤄지고 있어야합니다. 백로그 액션플랜을 구현하는 와중에 다음 액션플랜의 기획까지 나올 수 있어야 기획과 빌딩이 맞물려 돌아가면서 제품 팀이 주어진 시간 안에 가장 빠르게 OKR 을 달성하는 지점까지 갈 수 있습니다.
만약, 백로그를 쌓아가는 일과 백로그를 실행하는 타이밍이 별도로 이뤄진다면 디자이너, 엔지니어들과 같은 메이커들의 소중한 시간이 붕 뜨게 됩니다.
데이터 활용의 페이스
정량적 데이터 사용이 더 능숙한 팀이든 정성적 데이터 사용이 더 능숙한 팀이든,
데이터 활용의 페이스는 제품 팀의 백로그 품질 관리와 직접적인 연관성이 있다는 것이 큰 배움이었습니다.
데이터 분석가 채용을 고민하는 팀들과 이야기를 나눌 때 굉장히 자주 받는 질문은
“데이터 분석은 얼마나 빨리 해야해요?” 입니다.
제품 팀에서 PM 과 함께 일하는 데이터 분석가일 경우, 저는 제품빌딩 페이스에 맞출 수 있어야한다고 답합니다.
PO/PM 과 함께 일하는 데이터 분석가의 역할은
데이터 분석을 통해 액셔너블한 인사이트를 혹은 가설을 최대한 잦은 주기로 도출해 제품 전략 측근의 역할을 하는 것이라고 저는 생각합니다.
여기서 데이터 분석가의 역할이 잘 이행되는 것은 PO/PM 의 백로그 품질 관리에 필연적입니다.
데이터 분석가의 역할이 기대이하로 이뤄질 때, 제품 팀 전체가 타격을 받게 됩니다.
데이터 활용을 통한 인사이트 도출이 느려질 경우
→ 제품 백로그가 하나둘 비게 된다
→ 제품 메이커들의 할거리가 비게 된다
→ 백로그거리를 PO/PM 이 찾아야하는 상황이 된다
→ 백로그가 나오기는 하는데 데이터 근거가 약하거나 직관에 의존성을 둔 액션들이 하나둘 나오게 된다 (성공 가능성이 낮아진 백로그)
→ 백로그 퀄리티는 낮아지고 데이터 분석은 신뢰를 잃게 된다
정리하자면, 프로덕트 오너의 핵심직무는 제품전략 실행을 위한 높은 백로그 퀄리티를 유지하는 것이라고 해도 무방할 정도입니다.
효율적인 리소스 운영을 위해서는 데이터 활용 프로세스가
퀄리티 높은 백로그 생성속도를 유지할 수 있어야한다는 것을 배웠습니다.
Outro
요약하자면 BML 루프 실천의 핵심은 좋은 가설이고,
좋은 가설 도출 페이스가 제품 빌딩페이스보다 뒤쳐질 때 백로그의 품질이 크게 저하된다는 사실을 배웠습니다.
PO 역할을 하면서 배운점들이지만,
신기하게도 제품 팀내의 데이터 활용과 맞닿아있는 배움들이었습니다.
PO 의 역할과 DA 의 역할을 겸직하고 있던 저에게는 생각해볼 지점이 많은 배움들이었습니다.
제품 팀의 DA 의 역할에 있어 더 높은 기준치를 갖게 되는 계기가 되었습니다.
다양한 제품 OKR 를 동료들과 함께 달성하고 고객들에게 가치전달을 극대화하는 일은 매우 즐거웠지만, PO 와 DA 의 역할을 겸직한다는 것은 DA 의 역량이 더더욱 밀도높고 성숙해야한다는 사실을 배우게 된 것 같습니다.
반대로 높은 퀄리티의 가설을 도출하는 데이터 분석을 언제나 자유자재로 할 수 있는 PO 가 된다는 것은 빠른 제품빌딩 속도를 추구하는 환경에서 얼마나 큰 가치가 있을지 알게 되었습니다.
이러한 배움들을 기반으로 Data Analyst 의 역할로 선택과 집중을 하게 되었습니다.
앞으로도 프로덕트 기반의 제품성장에 관한 글은 계속 쓰겠지만, 4Q 부터는 “빠른 페이스의 가설추출” 이라는 목적을 명확하게 띈 데이터 분석 능력을 디벨롭 시키는데에 집중해보려고 합니다.
언젠가는 꼭 다시 PO 역할을 하고 싶습니다. 하지만 현재보다 가설도출과 백로그 관리능력이 몇배로 뛰어난 PO 로 돌아오고 싶다는 생각입니다.
개인적으로 2보 전진을 위한 1보 후퇴라는 느낌도 있어 설명하기 어려운 두려움도 있는 것 같습니다.
하지만 충분한 고민 끝에 자의로 내려놓는 상황, 다양한 OKR 달성, 그리고 항상 아낌없이 응원을 주는 동료들이 있다는 사실에서 또 다시 힘차게 성장해보려고 합니다.
긴 회고글 읽어주셔서 감사합니다. 🚀
