1. CPO(Chief Product Officer)의 R&R(역할과 책임)
- Product 전체의 Vision 수립, Goal & Roadmap 관리
- High-level Business / C-level alignment
- PO & Tech 조직, 문화와 프로세스 빌딩
- PO와 관련 직군의 채용, 리텐션, synchronization
- data & test 기반 의사결정 시스템과 프로세스 수립
- 결과를 통해 신뢰 구축
2. FAQ
Q : "소위 촉이 좋고 타율이 높은 기획자와 노력과 Data 기반의 사고는 되는데 실제 타율이 높지 않은 두 기획자 중에 어떤 스타일을 더 선호하고, 보통 주변에 어떤 업무방식과 마인드셋을 가진 사람이 성공하나요?"
A : "촉(직관)을 무시하기는 어렵습니다. 운이 좋게 직관으로 성공적으로 서비스를 런칭 하였다 하더라도, 직관만 가지고 서비스를 운영하기에는 쉽지 않습니다. 그리고, Data 기반으로 사고를 하는데, 타율이 낮다면, Data를 혹시, 잘못 해석하고 있는 것은 아닌지, 혹은 잘못 활용하고 있는것이 아닌지를 확인해봐야 할거 같습니다. 그리고 직관이 좋은 기획자는 근거를 가지고 설득할수 있는 능력이 수반이 되어야 좋은 기획자가 될수 있을것이라고 생각 합니다."
Q : "PO로서 데이터 분석은 어느 정도 수준의 역량을 가져야 하는지?(ex : R) SQL은 기본으로 할 수 있어야 하는데 맞나요?"
A : "데이터 분석 역량은 PO에게 굉장히 중요합니다. PO 업무를 수행하다 보면, R까지 활용할 일은 거의 없는거 같아요. 오히려, SQL 쿼리만 어느정도 할수 있으면 좋을거 같아요. 오히려 PO에게 가장 중요한 소양은 데이터를 이해하는 능력, 그리고 지표를 수립하는 능력, 이런것들이 더 중요한거 같아요. 데이터라는게 관점과 기준에 따라서 해석이 충분히 달라 질수 있거든요. 그리고 때에 따라서는 이것은 인과 관계가 아니고, 상관 관계 인데, 인과 관계로 해석을 해서 문제가 발생하기도 합니다."
Q : "데이터를 이해하는 능력은 어떻게 하면 기를 수 있을까요?"
A : "경험이 있어야 될거 같습니다. 그 경험이 그냥 시간이 지나면서 얻어지는 경험이 아니고, 실제 가설 수립을 해보고, 해봤는데, 데이터가 그렇게 안나오면, 그러면 뭐가 문제 였지? 이런 과정을 계속 반복을 하다 보면, 그 역량이 길러지는 것 같아요."
Q : "대학교 졸압한 신입이 PO가 되기 위해 어떤걸 준비해야 할까요?, 개발자 출신, 디자이너 출신, 창업자 출신 등 다양한 백그라운드가 존재하는데, 백그라운드가 없는 사람이 시작하려면 어떤게 중요할까요?"
A : "백그라운드가 없으면, 백그라운드를 만들어야 되겠죠. 백그라운드를 어떻게 만드냐면, 첫번째는 서비스를 많이 써보고 고객의 크리티컬 페인 포인트가 무엇인지를 도출 해보고, 그래서 그 페인포인트를 해결 하려면, 어떤 솔루션을 제시를 해야 되지? 를 많이 고민해 보는게 좋을거 같습니다. 특히 내가 지원하려는 회사의 서비스에 관심을 가지고 그런 부분에 있어서 고민의 깊이가 깊으면 좋을거 같아요. 이런것도 하나의 백그라운드가 될수 있고, 그리고 꼭 웹/앱 서비스가 아니더라도 본인의 과제에 있어서 정량적인 성취를 이루는 것이 중요할거 같아요. 과제를 할때 목표가 무엇인지, 정략적으로 설계를 해보고, 과제를 달성하기 위해서 이렇게 수행을 했는데 실제 지표가 이렇게 나오더라, 왜 그랬을까? 이런것들을 쌓아 나가는것도 좋은 백그라운드가 될수 있을거 같아요. 또 큰 회사나 큰 서비스를 가기위해서 준비만 하는것이 아니라, 작은 회사나 작은 서비스에서도 경험을 빨리 많이 해보는것이 더 중요할거 같아요."
Q : "기획자의 성장을 위해 읽어야할 도서가 많지 않은데, 100% 기획자를 위한 것은 아니더라도 추천하시는 책이나 자주 가시는 미디어가 있다면 어떤것인가요?"
A : "사용성의 관련해서는 저는 '스티브 크룩'의 책을 많이 보구요. [스티브 크룩'의 '생각하게 하지마'] 라는 책과 [사용성 평가, 이렇게 하라!], [Don't Make me Think], [Steve Krug Rocket Surgery Made Easy] 그리고 사용성 이외에는 [Lean Startup], [진화된 마케팅 그로스 해킹], [The Lean Startup], [Zero to One], [그로스 해킹] 린-스타트업 이라는 책은 MVP(최소 기능 제품)이라는 용어를 만들어내고 유행을 시켰을 정도로 매우 유명한 책이고 MVP를 통해서 빠르게 테스트를 하고 product을 발전시키는 방법에 대해서 쓰여진 책 이라고 볼수 있습니다. 그리고 [Zero to One]은 심플한 원칙으로 성공에 대해서 설명을 해주고 있구요. 그로스 해킹은 product을 성장시키기 위해서 봐야하는 여러가지 지표에 대해서 설명을 해주고 있습니다. 그런데, 개인적인 경험에 의하면, 책이 가끔 위험하기도 한거 같아요. 사실, 상황과 조건은 항상 다르고, 그런데 무리하게 적용을 하려고 하기 때문에, 부작용이 발생하기도 해요. 따라서, 책을 보실때에는 그런 특수한 상황, 조건들을 잘 이해를 하고 보시면 좋을거 같습니다."
Q : "대시보드는 유관 업무자들이 직관적으로 쉽게 이해할 수 있어야 하지만, 제대로 된 대시보드를 만드는 일은 많은 리소스를 필요로 합니다. 고객과 접점이 있는 프로덕트를 우선시 하다보니 항상 대시보드는 우선순위가 밀리고 있는데, 제대로 된 대시보드가 실질적으로 프로덕트 개선에 많은 기여를 할까요?"
A : "대시 보드가 다 똑같지는 않을거 같아요. 거기에 어떤 지표들이 있느냐에 따라서, 질이 달라질수 있을거 같아요. 실제적으로 의미없는 지표들이 굉장히 많은 대시보드들도 저는 많이 봤구요. 그래서 그게, 실제 인사이트를 이끌어내서 실제 액션을 할수 있는 지표들로 구성된 대시보드를 만드는게 중요할거 같아요. 그런데 질문 중에서 product을 구현하느라 대시보드 구현이 밀린다고 말씀을 하셨는데, 그 뜻은 아마 product을 구현하는 조직이 대시보드도 만든다 라는 뜻인거 같아요. 당연히 Feature 릴리즈가 더 우선순위가 더 높게 설정이 될수 밖에 없고, 같은 조직이 대시보드를 만든다고 하면, 순위가 많이 밀릴수도 있을거 같아요. 그리고 대시보드 뿐만이 아니라, 로그를 개발자들이 잘 개발을 해줘야, 그 대시보드에 있는 지표들이 의미가 있게 나올수 있거든요. 그런데 비즈니스 우선순위 혹은 Feature 구현이 밀리다 보면, 그런것들이 나중에 구현이 되거나, 안되거나 할수 있습니다. 그래서 데이터 분석을 하는 조직, 담당자 혹은 R&R이 별도로 구분되어 있으면 좋을거 같구요. 그렇게 하기 어렵다고 하면, 일정 N%라도 할당을 해두시면 좋을거 같아요."
Q : "모든 의사 결정은 데이터 기반으로 해야한다고 배웠고, 그렇게 하려고 노력중이지만 데이터로 딱 떨어지게 검증하기 애매한 상황을 자주 마주합니다. 무언가 액션을 취하기에는 신뢰가 부족한 경우, 어떻게 하시나요?"
A : "일반적을 A/B 테스트를 해서 신뢰가 떨어지고, 이것을 확신할수 없다고 하면, 대부분에 케이스에서는 [기존안] 대로 갑니다. 빠르게 중요한 다음 가설을 검증하는 것이 좋을거 같아요. 데이터 없이 혹은 완벽한 데이터가 가추어지기 전까지 완벽한 테스트 결과가 가추어지기 전까지 아무런 액션도 하지 않고, 기다리는 것은 굉장히 낭비라고 생각을 합니다. 시장에 있어서의 타이밍도 많이 놓칠수 있기 때문에 빠르게 목표를 찍고 가는게 더 중요하다고 생각을 합니다."
Q : "그런데, 우리의 핵심 고객은 누구인가?"
A : "서비스의 전략과 방향성이 중요하고, 우리의 핵심 고객이 누구인지를 알아야, 지금 질문하신 부분에 대해서 답을 드릴수 있을거 같아요. 목소리를 높이는 고객이 우리의 핵심 고객이라고 볼수 있는지, 그 고객에 요구사항이 일부 고객에 요구사항은 아닌지, 우리 서비스의 수익성과 성장 가능성과는 아무 관련 없는 고객이 아닌지, 생각을 해보면 좋을거 같아요. 페이팔 CFO가 한 얘기 중에서, '우리 서비스에 돈을 벌어다 주는 고객이 누구인지? 제대로 파악해야 한다.' 라는 메세지를 들은적이 있습니다. 우리의 핵심 고객이 누구인지를 파악하고, 그 질문에 답을하는 것이 중요하다고 생각을 합니다. 고객에 요구사항이 내가 분석했던 데이터와 맞아 떨어진다면, 서비스에 방향을 바꾸는 것도 방법일수 있습니다. 앞에서 제가 인스타그램의 예를 들었었는데, 데이터를 통해서 사진 공유만 많이 쓰네? 라는 것을 발견을 했잖아요. 그래서 서비스를 피봇팅 했습니다. 스타트업에서 피봇팅은 굉장히 중요하거든요. 예를 들면, 슬랙이라는 메신저 회사가 있는데, 기업에서 협업 솔루션으로 슬랙을 많이 씁니다. 근데 이 회사는, 처음 부터 메신저 회사가 아니였거든요. 원래는 게임을 만들던 회사였는데, 게임을 만들면서 이 게임을 잘 만들기 위한 협업 도구가 필요해서, 부수적으로 만들었던게 메신저 였어요. 그런데 고객에 해당하는 회사 구성원들이 메신저를 너무 잘썼어요. 그래서 잘 안되는 게임을 버리고, 메신저 회사로 피봇팅을 했습니다. 그래서 지금은 기업 공개도 하고, 성장한 회사로 자리매김 하고 있죠. 그래서 실질적으로 고객에 요구사항이나 니즈에 맞게 Product을 피봇팅 하는 것도 중요한 전략이 될수 있습니다."
Q : "우리 서비스 개선을 위해 국내, 해외 서비스들을 레퍼런스로 많이 참고하는데, 이런 방식으로 학습하는것이 맞는지? 그리고 맞다면 대표적으로 잘 만들어진 서비스의 케이스가 있는지 궁금합니다."
A : "사용자들이 많이 사용하고, 리텐션이 좋은 서비스들은 대체로 잘만들어진 서비스 라고 볼수 있을거 같아요. 그래서 그런 서비스를 벤치마킹 하는건 매우 좋다고 생각을 합니다. 비슷한 고민을 했던 사람들이 다양한 테스트를 통해서 데이터를 보고 그런 솔루션들을 도출 했었을 거기 때문에, 그런 서비스를 많이 밴치마킹 하므로써, PO들에 고민을 많이 줄여 줄수 있다고 생각을 해요. 그런데, 벤치 마킹 보다 더 중요한 거는 고객과 고객 문제의 본질을 이해하는게 더 중요 하다고 생각을 하거든요. 예를 들면, 제가 매우 존경하는 사람은 [제임슨 다이슨] 이에요. 다이슨은 헤어 드라이어를 만들기 위해서 타사를 벤치 마킹 한게 아니라, 고객이 가지고 있는 문제에 본질에 집중을 했어요. 그래서, 실제 머리카락도 1500km, 테스트도 40만번 이상 테스트를 해서 드라이어를 만들었죠. 제가 생각하기에 다이슨은 벤치마킹해서 서비스를 잘 만드는 것이 아니라, 고객의 문제에 본질을 집중을 해서, 그 문제를 잘 해결하려고 하는 대표적인 예라고 생각을 해요."
Q : "소위 대박나는 서비스들의 공통점은 무엇이라 생각 하시나요? 여러 요인이 있겠지만 시장의 규모인 것인지, 출시 타이밍인 것인지, 마케팅 역량인 것인지?"
A : "사실 [야놀자] 서비스도 경쟁사에 뒤쳐질 때, 벤치마킹을 되게 많이 했었어요. 그러다 보니, 서비스가 서로 비슷해지는 경향이 있어서, 실제로 고객들도 내가 지금 [야놀자]를 쓰고 있는건지, 경쟁사 서비스를 쓰고 있는 건지, 되게 헷갈린다는 얘기를 많이 했었거든요. 그래서 서비스를 벤치마킹을 하면, 한계라는게 거기에서 오는것 같아요. 그런데 위 질문에서 말씀드린것 처럼, 문제에 본질에 집중을 하고 테스트와 데이터 분석을 반복 하다 보면, 타사에는 없는 그래서 고객에 문제를 혁신적으로 해결할 솔루션을 도출 할수 있게 되는거 같습니다."
Q : "IT 제품의 우선순위가 높아 개발 조직 중심적인 회사도 있고, 사업(세일즈)에 우선순위가 높아 사업부의 결정이 중요한 조직도 있습니다. 무게 중심이 서로 다른 조직에서 어떻게 우선순위를 만들어 나가시나요?"
A : "예전에는 Item이 좋아야되! 라고 얘기를 하는 사람들도 있었던거 같아요. 그리고 팀이 중요해 라는 얘기들도 했었구요. 그런데, 제각 생각하기에는 첫번째는, 시장에 타이밍, 아무리 좋은 제품을 만들어도 시장이 그걸 원하지 않으면, 그 제품은 성공할수 없잖아요. 두번째는, 그 제품을 성장시키는 구성원들에 역량이 중요할거 같아요. 시장에 타이밍과 구성원들에 역량 2가지를 성공에 요인이라고, 생각을 합니다. 구성원들에 역량이 중요한 이유는, 서비스가 운좋게 런칭할 당시에 성공을 했다고 하더라도, 서비스를 잘 성장시켜야 하잖아요. 밖에서 보기에는 잘 모를수도 있는데, 사실 서비스가 성장을 하는데는 내부에서 굉장히 고통스럽게, 시스템적으로 프로세스 적으로 환골탈태하는 내부 변화를 겪고 있다고 보시면 될거 같아요. 되게 힘들거든요. 그래서 이런 변화들을 얼마나 잘 만들어내느냐가 서비스에 성공을 좌우 합니다. 제품을 출시하고 나면, 굉장히 레거시 코드들이 많이 쌓여요. 그러면 이것들을 다 걷어내고, 새로운 기술도 도입하고, 그렇게 해야 되잖아요. 그런 과정에 있어서 구성원들에 역량이 중요하다고 볼수 있겠죠."
Q : "같은 데이터를 보고도 팀내에서 해석이 각기 달라 다음 테스트할 가설을 수립하는데 어려움을 겪고 있습니다. 이런 경우 어떤 기준으로 우선순위를 설정하나요? 각자의 해석에 따른 모든 가설을 테스트해보고 싶지만 리소스와 시간이 제한적입니다."
A : "이런 우선순위를 결정하는 것이 PO에 역할 입니다. 우순순위를 수립하기 위해서는 각각에 요구사항에 대해서 Expected Result가 잘 도출 되어야 할거 같구요. 그거에 따라서, 사업부에 우선순위가 높아진다면, 사업부에 요구사항을 먼저 하는것이, 당연할 거구요. 그것은 시기에 따라서도 또 달라질수 있을거 같습니다. 그리고 서비스에 성장 단계나, 마케팅에 우선순위가 높을수도 있구요. 이런 부분들을 정량화 해서 우선순위를 가져가면 좋을거 같아요."
'Lean Startup' 카테고리의 다른 글
| PO vs PM vs 기획자 (2) | 2021.01.18 |
|---|---|
| 효율적인 미팅과 Written Communication (0) | 2021.01.02 |
| 문제를 공유하고, 솔루션을 찾아나가기 위한 협업 방법 (2) | 2021.01.02 |
| 고객 중심의 Prioritization(우선순위) (2) | 2021.01.01 |
| 제품 로드맵, 제품 백로그 (0) | 2021.01.01 |