책 제목
프로덕트 오너
출판연월
20년 3월
지은이
김성한

읽기 전

  • PM의 사고방식을 이해해서 그들과 더 효율적인 소통.
  • 내가 PO라면 데이터를 어떻게 활용할지. 데이터를 보는 관점의 변화. 이 변화로 무엇을 할 수 있을지? 아직 모르겠음
  • 프로덕트를 만들어보고 싶은 동기. 사이드 프로젝트로 가능한 정도일까..? PO는 어느정도 인적 볼륨이 필요한 직군이라는 생각이 큼. 작은 프로덕트 만들어서 배포할거면 그냥 내가 대표하면 되는거 아닌가
  • 카페 일하게 되면, 라이브에서 내가 많은 무수한 프로덕트를 서빙하는 것과 같음을 깨달음

읽으면서 든 생각

  • PO는 미니 CEO다
    • 저자가 의미하는 ‘미니’란 권한이 작다는 의미가 있음. CEO와 비슷하다고 볼 수 있지만, CEO처럼 누군가에게 결정을 통보하고, 실행하지 않는다고 함. 오히려 누구보다 저자세로 임하고, 경청하며 사실만을 토대로 설득하는 고독한 자라고 함.
    • 고독? 고독하지 않은 직군이 있나. CEO도 저렇게 일하는 사람 몇 명 있는데
    • 책임은 있지만 권한은 거의 없다고 한다. 권한이 주는 편리함이 없고, 늘 설득해야 한다고 함
    • 헤비 트레이더 직접 찾아가서 어떻게 하는지 지켜보도록 하라는 대표의 말. 이게 도움이 되었다고 하는데 사실 우연히 찾아간 표본이 헤비 트레이더 모집단을 잘 대표했던 케이스라 도움이 된 것 아닐까. 이상한 케이스 만나서 잘못된 길로 빠질 수도 있지 않았을까. 헤비 트레이더 중에서도 잘 사용하지 않는 방식으로 트레이딩 한다던가.
    • 운에 맡기기 보다는 헤비 트레이더 직접 찾아갈 수 있다면, 인구통계학적 데이터가 있다는 것일테니 이걸로 좀 대표 격인 샘플 몇 개를 추출해서 찾아가봤다~ 라는 과정이 있었으면 더 괜찮았을 것 같다
    • PO의 시초가 20세기 초 Brand Man 이라는 직무에 있다는 것이 인상 깊음. 이 당시부터 이런 쪽 수요가 있었구나.
    • 넷플릭스에서 고객에 집착해 프로덕트 개선한 사례: 기존에는 고객에게 높은 평점의 콘텐츠만 추천하면 서비스를 더 오래 사용할 것이라는 가설. 근데 데이터는 그렇지 않았나봄. 그래서 5점 평점 버리고 good, bad의 binary 값만 입력하게 바꿈. 또한 평점이 아닌 개별 고객 선호도와 얼마나 유사한지 퍼센트로 보여줌(CBF 기반한건가). 5점 평점을 버리고 -> binary 평가로의 스텝을 결정한 사고방식이 궁금함. 다른 선택지도 훨씬 많았을텐데
    • 실험적인 마인드를 떠나, 현장을 직접 살피고 고객에 집착하는 마인드는 통찰을 얻는데 가장 좋은 방식인 것 같다. 이유가 수만가지를 댈 수 있겠지. 그럼 반대로 현장에만 있는다면? 고객을 스토킹한다면? 이 나름대로도 얻는게 있으려나
  • 고객의 목소리를 어디까지 반영할 것인가
    • 밀크세이크 이야기. 이건 아직도 잘 이해가 안된다. 이 이야기에서 말하는 시장 분석이 과연 옳은걸까? 전국 모든 매장에서 오전은 직장인이, 오후는 학부모가 소비한다고 할 수 있는걸까? 편향이 있는게 아닐지.
    • 제품을 구매하는 고객의 마인드: 직면한 문제가 있으니, 어떤 것을 고용(=구매)해서 해결하고자 함
    • 6-Pager: 프로덕트의 핵심을 6장 이내에 담는 것. 첫 장에 해당 프로덕트가 고객에게 고용되는 이유를 목록 형태로 나열. 프로덕트를 개발하기 전 고객이 어떤 일을 해결하기 위해 프로덕트를 고용하는지 PO가 먼저 완벽하게 이해하고 있어야 함.
      • 밀크세이크 이야기는 누구보다 소수의 이야기 아닌가? 패스트푸트 한 지점만 본게 아닌가? 이게 어떻게 전국 지점으로 확대되어 일반화된 ‘고용 이유’가 된건지 궁금하다
    • 인구통계학적 데이터로 고객을 구분하는 것은 고객이 왜 제품을 고용하는지 도움 안됨
      • 왜인지 모르겠는데, 영화 <인턴>에서 앤 해서웨이의 회사가 '퇴근 후 와인 마시면서 쇼핑하는 20~30대 여성 고객'을 타겟팅한다는 것이 떠오름
    • 실제 고객 경험을 토대로 분류를 하면 제품 개선에 도움이 된다고 함. 당연한 얘기처럼 들리는데 현실에서 실현이 어려운 이유는, 아무래도 어떤 고객 경험에 반응해야 전체 고객 경험이 개선될지 알기 어렵다는 점이 있을듯
      • 고객 = 데이터 사용하는 임직원이고 제품 = 태블로 대시보드 라고 했을 때, 한 팀의 요구 사항 때문에 대시보드 일부 수정했던 적이 있음. 근데 수정하고 나니 막상 다른 팀에서 문의가 들어오는 경우.
    • 필자가 실제 자본과 시간을 투자해서 고객 경험을 체화했다는 것은 대단하다. 나는 정작 지금 회사 대표 프로덕트도 거의 안해봤는데…
    • 고객의 대다수인 리테일 거래자와, 비중은 적지만 거래량의 대부분을 차지하는 우량 거래자 중 하나를 택하는 것은 불가능에 가까웠다 -> OMTM과 같은 지표 설정이 없어서 갈팡지팡하는 것 아닌가? 쉽게 말해 리텐션이냐 매출이냐 문제 같은데.
      • 리테일 쪽은 선택했다는데 근거를 살펴보면, 결국 리텐션이 전체 사업 관점에서 중요한 지표라고 판단한 것으로 보임
    • 입사하자마자 사업의 방향을 찾던 필자가 조직이 원하는 것을 몰라 갈팡지팡했다는 것은 말이 안됨. 아마 사업의 방향과는 무관하게 제품의 개발 우선순위를 정하는 것은 고민해야 할 많은 요인이 있는 것으로 보임
    • Guiding Principle: 프로덕트 개발, 운영할 때 꼭 지켜야 하는 4~6개의 원칙. 이 부분에선 ‘프로덕트가 다른 PO에게 넘어가더라도 이 원칙만 따르면 문제 없이 개발이 이어질 정도로 정확해야’한다는 부분이 인상 깊음. 미래까지 고려해야 하는 것은 개발이나 기획 모두 비슷함
    • 고객에게 더 나은 가치를 제공하기 위해 집착하는 직군이 PO지만, 회사가 정한 방향성과 목표를 잊어서는 안됨을 강조함. 너무나 당연한 말!
    • 스터디 때 언급된 ‘페르소나’ 얘기가 나옴. 페르소나 != 고객이라는 내용인데, 이유는 결국 편향이다. 순서대로 표본 편향, 확증 편향과 같은 말. 필자는 데이터, 사용 패턴을 감안해 고객을 파악하라고 하는데, 그게 안되니까 페르소나를 차선으로 만드는거 아닌가? 이런 불평할 시간에 데이터 보고 고객 분류하라는 걸까.

데이터 속에서 진실을 찾는 법

  • 사업 혹은 운영 방침이 조금만 변경되어도 BA에게 곧바로 알리고 상의한다
  • 일정 기간의 데이터 정확도가 흐트러질 수 있다고 판단되면 관련된 모든 이들에게 당분간 분석 결과를 참조하지 말라고 경고함
    • 이런 PO와 일해보고 싶다. 여기는 내가 경고해야 듣는 둥 마는 둥..
  • 반드시 봐야하는 지표가 무엇인지 PO가 고민. 이게 없으면 고객 행동을 트랙킹할 수 있도록 모든 이벤트에 로그를 심게 된다.
    • 내가 하던 것.. 그 때 PM이랑 논의해서 어떤 지표를 우선적으로 볼건지 정했어야
    • 어떤 지표를 볼건지는 논의했었는데 부족한 것은 PM과 이 지표에 대한 컨센서스가 없었음. 기획자, 분석가만 논의햇던걸로 기억..
  • 데이터 분석의 결과는 두가지로 분류된다. 단순히 참조할 수 있는 것. 곧바로 어떤 행동으로 옮겨 무언가를 바꿀 수 있게 해주는 것
    • 상품 최적 판매 기간 분석?
  • 이 PO는 분석 결과물 공유해주는 자리에서 데이터를 보며 계속 ‘그래서 뭐? 그래서 우리가 무엇을 할 수 있지?’라는 질문을 속으로 던진다고 한다.
    • 분석가 스스로도 계속 해봐야 하는 질문이라고 생각한다
  • 데이터 대시보드도 프로덕트다. ‘처음 접하는 사람이라면 쉽게 이해할 수 있을까’를 PO가 고민하라고 함. 기왕에 시간과 에너지를 투자하여 생성하는 대시보드라면, 누구나 어려움 없이 데이터를 이해할 수 있도록 해주는 것이 당연하다.
    • 개발하는 분석가가 고민해도 좋을 부분인 것 같다.
    • 대시보드 타이틀은 주제를 명확히 알려줘야 함
    • 테이블의 명칭도 명확하게 쓰여 있어야 함
    • 테이브르이 열, 행 명칭도 정확해야 함
    • 명칭만으로 부족한 경우, 테이블이나 그래프 아래에 부연 설명을 덧붙임
    • 영문 등으로 생성할 경우, 대소문자를 잘 구분할 것

효율적인 일정 관리의 비밀

  • 새로운 기능 개발 시 나오는 여러 질문을 FAQ와 같이 목록 형태로 나열해서 문서로 작성, 대응함
    • 내가 하려는건 신규 기능 개발은 아니고, 기존 지표 FAQ이긴한데 이게 어쩄건 시간을 아낄 수 있다고 여기서도 말해주니 좋네
  • 지라 티켓 설명
    • 에픽: 큰 목표를 잡아주는 역할. 새로운 프로덕트, 신규 기능 개발할 때 활용. 에픽 티켓 아래 스토리 티켓을 다수 생성해서 관리하는 형태
    • 스토리: 에픽보다 더 구체적인 개발 요구사항이 있어 에픽을 구성하는 티켓이다.
    • 태스크: 하나의 스토리가 완료되기 위해 개발되어야 하는 것들을 더 잘게 나눈 형태.
  • PO가 개발자에게 존중받는 가장 확실한 방식은 요구사항을 명확하게 전달하는 것
    • 비단 개발자 뿐만 아니라 모든 직군에 통용되는 말.
    • 이게 어려운 이유는, 명확한 요구사항을 위해선 상대의 업무에 대한 이해가 뒷받침 되어야 하기 때문
    • 내가 개발을 해보지 않았는데 개발자에게 명확하게 요구할 수 있을까? 난 못했음
  • PO가 개발, 디자인 일을 해선 안된다고 함
    • 각자의 전문적인 영역이 있고, 이걸 활용해야지 내가 그걸 대신해버리면 여간 골치 아픔
    • 각자의 전문적인 영역을 이해해서 요구하는 것과, 내가 직접 하는 것은 어떻게 다를까

디자니어를 최고의 파트너로 삼는 법

  • 직군 특성 상 디자이너와 일할 기회는 거의 없는데, 이 책에서나마 디자이너와 일하는 경험을 간접적으로 알 수 있는 점이 좋다
    • 첫 장부터 나온 내용이, 디자이너에게 어떤 방식으로 결과물을 도출해야 하는지 알려주는 것은 올바르지 않다고 함.
    • 디자인 시안은 보편적으로 더 쉽게 파악 가능해서 PO가 디자이너 업무에 간섭할 확률이 더 높다고 함
    • 버튼 위치 여기가 좋을 것 같은데 이런 훈수질 하지 말라는 것
  • 그럼 어떻게 피드백 주는 것이 건강한걸까?
    • 디자인에 대한 시각적 코멘트를 하지 않는다
    • 오로지 고객이 사용할 때 어떤 느낌이 들지 가정해보며, 조금이라도 모호한 것을 찾아내려고 노력할 뿐
    • 본인의 개인적 성향 등을 철저히 배제하며 사용성에 대해서만 논의한다. 그래서 엄청 집중해야 하고 고되다고 함
  • 디자인 리뷰 원칙
    • PO는 오로지 고객을 대변하는 입장. 감정, 관계 등을 일체 배제
    • 개발하고자 하는 기능에 대해 정한 원칙에 기반하여 판단할 것
    • 디자이너에게는 질문의 형태로만 의견을 피력. 절대로 지시하지 않음 (이것도 디자인이라고 한거에요?)
    • 질문한 후에는 디자이너의 의견을 경청함. 모든 시안은 고심의 결정체임을 인지할 것
    • 구두로 거론된 내용을 회의 직후 기록하여 전달함. 디자이너가 선호하는 방식을 따른다
    • 디자이너 뿐만 아니라 여러 직군 리뷰 할 때도 비슷하게 적용 가능할 것 같다
  • 이 사람은 사용자 경험을 최대한 객관적으로 다양하게 체감하기 위해 앱만 1,000개 넘게 깔았었다고 함
  • 의견과 요구사항은 다르다
    • 의견: 문구 크기는 최대한 키웠으면 합니다
    • 요구사항: 고객이 구매하기 전, 구매 내용을 최소 1회 확인할 수 있어야 합니다. 고객이 결제할 때, 할부 구매 방법을 인지할 수 있어야 합니다.
  • PO가 디자이너에게 의견을 강조하는 순간, 프로덕트는 고객을 위한 것이 아니라 PO를 위한 것이 되어버리기 때문이다. 명언이네

개발팀과의 협업을 성과로 이끄는 애자일 전략

  • 스프린트에서 아래 내용을 주로 준비하고, 다룬다고 함
    • 이전 스프린트에서 개발 완료한 것
    • 이전 스프린트에서 개발 완료하지 못한 것
    • 이전 스프린트에서 발생한 기술적 이슈 또는 버그
    • 이전 스프린트에 대한 회고
      • 여기서 잘한 점, 개선되어야 할 점을 다루는데, 자기 자신에 대해 적는 것 보다는 조직 전체나 다른 이의 기여에 대해 공유하는게 도움이 된다고 함
      • 나는 그냥 내가 잘한거, 못한거 적었었음..
    • 이전 분기 OKR 달성 상황
    • 이번 스프린트에 개발해야 하는 것
  • 개발자가 직접 고객과 소통하거나 유관 부서와 협의하는 상황이 발생해선 안된다고 한다
    • 동의하는 부분도 있고, 아닌 부분도 있다. 중요한 가정은 PO를 빼고 협의하냐, 포함시키고 협의하냐인 듯
  • 자발적으로 매우 다양한 질문을 하는 경우도 있는 반면, 한마디도 안하고 조용히 경청만 하는 조직원들도 있다
    • 나는 후자. 내가 개선해야 할 부분이라고 생각한다.
  • 확장성 등의 아키텍처 개선을 고려한다면, PO는 레이턴시도 고려해야 함
    • 개발물의 아키텍처가 잘 짜여져 있으면 레이턴시도 줄일 수 있다고 함
    • 지식인데 그냥 적어봄

고객 테스트 결과만큼 강력한 데이터는 없다

  • UT의 중요성을 말하면서, 필요한 절차를 나열하는데 생각보다 엄격(?)한 느낌이 든다
  • UT도 결국 편향의 저주를 피하긴 어려울 것 같다. 이 유저가 모집단의 아웃라이어라면?
    • 이 유저를 관찰한 결과로 수정한 사항이 오히려 프로덕트의 확장성을 해치는 꼴 아닌가
    • 이런 부분은 어떻게 고민하고 있는지 궁금하다
  • UT는 신규 프로덕트 뿐만 아니라, 기존 프로덕트의 수정 사항에도 적용되는 개념 같은데, 이 회사는 왜 그런걸 안하는 걸까?
    • QA만 할 뿐, UT는 이 책에서 처음 접한 개념
  • chapter summary(?)에 위에서 언급한 편향에 대해 간접적으로 답변을 하는데,
    • UT는 다수의 의견을 묻는 것이 아니라, 1대 1환경에서 한 명의 고객이 프로덕트를 사용하는 모습을 보고 떠오르는 생각을 직접 접하면서 인사이트를 도출해내는 절차라고 함
    • 프로덕트를 사용하는 고객의 진정한 모습을 확인하고자 함이라는데.. 이 유저의 선호, 취향을 떼어놓고, PO가 가정하는 어떤 인간 본연의 모습만 놓고 보겠다는 건가?
    • 그러기엔 관찰 노트에서 너무나 많은 취향이 들어간 것 같은데..
    • 다 관찰하고, 그 중 인사이트라고 할만한 것들을 추려내는 과정도 중요할 것 같다

프로덕트를 출시하는 최적의 시기

  • 핫픽스: 급하게 수정하여 안정화된 버전을 배포하는 것
  • 플랫폼 별 배포 방식이 다름
    • PC(웹): 브라우저 통해 접속, 사용이 가능하므로 개발팀이 배포하면 곧바로 고객이 브라우저 접속, 사용 가능
    • 안드로이드: 새로운 버전 배포하면 거의 바로 구글 플레이에서 다운로드, 업데이트가 가능함
    • iOS: 새로운 버전 배포하려면 애플의 검토가 필요함. 승인 후 다운로드, 업데이트가 가능함
  • A/B 테스트의 목적을 신규 기능 효과 검토 뿐만 아니라 트래픽 분산하는데에도 적용 가능하다는게 신기함
    • 새로운 디자인이나 기능을 배포한 다음, 곧바로 모든 사용자에게 보여주는 것은 위험하다고 함
    • 일반적인 상황이라면, 점진적으로 노출 빈도를 높이는 것을 권장함. 근데 여기 회사는?
    • On/Off switch 방식을 사용해서, 신규 기능에 문제가 있으면, B 그룹 꺼버리고, 트래픽을 모두 A 그룹으로 몰아버리는 것이 가능함
    • 이 방식에선 핫픽스가 덜 필요하지 않을까?
  • 이렇게 그룹을 나눠 트래픽 분산할 수 없는 상황이라면, 언제든 롤밸할 태세를 취해야 한다고 함.
    • 그래서 이 회사에선 롤백이 종종 보이는거구나.
  • 내부 직원도 고객이라는 말이 참 공감됨
    • 분석가로 일하다 보면, 일반 사용자를 접하는 경우는 거의 없고, 대체로 임직원 대상으로 프로덕트를 선보이는 일이 종종 있음
    • 내부 고객이 사용하는 프로덕트는 대외적으로 서비스하는 프로덕트를 운영할 수 있게 도와주는 경우가 대부분이라고 함

테스트 중 가설을 효과적으로 검증하려면

  • A/B/C 테스트를 언급하는데, A/A 테스트를 말하는 것 같다. 필자는 이걸 굳이 할 필요 없다는 입장인데, 분석가 관점에선 필요하다고 본다
  • p value를 어떻게 산출하는지를 고려하지 않고, 올바른 해석이 가능할까?
    • 테스트에 필요한 가정을 따지고, 데이터 형태에 따라 적절한 방법론을 적용해서 검정 결과를 내는 것 까지는 분석가에 믿고 맡기는 걸까?
    • 결과에 대한 해석만 다룬다는 점에서, 분석가 외의 관점을 볼 수 있다는 것이 인상깊다
    • ‘p 값이 0.01 보다 낮을 때 까지 테스트를 신뢰하지 않는다’ -> 0.01이란 값에 개인적인 의미, 선호를 부여하는건가? p 값이 낮은게 어떤 의미인지 아는걸까. 마냥 낮은게 좋은건 아닌데..
  • 지표 결정에 있어서 성공 지표만 보는게 아니라 아래 두 지표를 같이 봐야 한다고 함. 새로운 기능이 끼치는 영향을 미시적, 거시적으로 봐야 한다고 하는 것
    • 특정 기능과 직결된 수치
    • 프로덕트 전반의 수치
  • P 값이 낮아지지 않을 때 PO의 선택지
    • 더 많은 고객에게 노출되도록 테스트를 연장
    • 테스트 중단 후 신규 디자인, 기능이 의미 없다고 판단
    • 유의미한 테스트 결과는 없지만, 프로덕트 전체에 악영향이 없다고 판단, B그룹을 전체로 확장
  • p 값은 현상을 파악하는 수많은 방법 중 하나일 뿐이다. p 값이 유의하게 낮아 B안을 선택해도 막상 테스트 결과와 정반대의 현상이 나타날 수 있다고 생각함
    • 이 PO도 이걸 알고 있을 것이다. 그럼에도 p 값을 테스트의 성과를 판단할 지표로서 이렇게 중요하게 다루는 이유는 뭘까?
    • 이 방법이 아니면 휴리스틱한 결정을 내리는 것이 최선인데, 구성원을 설득하려면 휴리스틱한 의사결정보다 그나마 데이터에 기반한 것으로 보이는 수치가 좀 더 설득력 있다고 생각해서 아닐까
    • p 값을 다루는게 따지고보면 구성원을 위한, 처절하게 현실적인 이유라고 추정해보니 나름 그럴듯하다.
    • 또 분석가와 달리, PO는 모든 사람을 이끌고 B 안을 만들어낸 사람이다. 단순히 float 값 하나로 그동안의 성과를 무로 돌리기엔…
    • 이 관점에서 테스트 연장해보는 것도 이해는 된다
    • 리소스가 크다고 꼭 유저들이 좋아하는 것은 아니니까. 잔인해져야 하는데, 막상 쉽겠냐고~
  • 이 부분도 역시 다루는데, 이 사람은 ‘개발 조직과 디자이너에 대한 심적인 미안함 때문에 테스트 결과를 왜곡된 시각으로 해석하려 하면 절대 안된다’고 함
    • 물론 A/B 테스트가 제대로 진행되었는지 검증하고 추가적으로 데이터 분석해보는 것은 PO의 책임이라고 함
    • 결과가 좋던 나쁘던 위 작업은 반드시 수행되어야 함. 테스트가 성공할 확률은 30%임을 알자
  • 트래픽이 적어 충분한 샘플 사이즈를 모으기 어렵다면?
    • 이 사람은 기다리라고 함. 사실 별다른 방법이 없긴 함
    • 특정 기간 내내 p 값이 어느 정도로 유지되는지 알 수 있는 p 값 트렌드로 고려해야 한다고 함. p 값 트렌드라..
    • p 값을 일종의 시계열 변수로 보고, 이게 시간이 지남에 따라 유의하게 변동하는지 보겠다는건데, 신기하네. 이렇게는 볼 생각 안 했는데
  • 검증하려는 수치는 미리 정해야 한다고 함
    • 이런 방식이 일반적인 것은 아는데, 고민이 되긴 한다
    • 테스트 전 특정 지표만을 본다는 것은, ‘이 기능으로 대략 이런 효과가 날거야’라는 직관적인 가정에 기반한 사고다
    • 이와 반대되는 방식은, 볼 수 있는 모든 지표를 모니터링하는 것이겠지. 이 중 급격히 뛰는 것도 있을테고, 거의 변동 없는 지표도 있을 것이고
    • 두 집단 간 sanity check만 완벽하다면, 사실 모든 지표를 놓고 그 중 유의한 변동이 있는 것을 추려내서 보는 것이 맞지 않나 싶다
    • 내가 예상치 못한 효과를 가져올 수 있는거니까. 다른 사람들은 어떻게 생각할까

런칭한 서비스의 문제를 바로잡기

  • 갑작스럽게 기능이 변경되거나 새로운 디자인이 적용되면, 고객을 대하는 다른 조직들은 상황을 파악하느라 정신이 없다.
    • 그래서 A/B 테스트 등 기능 변화가 있는 패치 때는 유관 분서에 이런 테스트가 있을 것이다 라고 전달하는 것이 필요하구나
    • 필자는 고객 서비스 조직에게 최대한 미리 디자인 시안을 토대로 기능을 설명하는 사용 안내서를 작성해 공유했다고 함. 엄청나네
  • 내부 고객이 사용하는 프로덕트가 업데이트 되더라도 동일하게 안내해야 함
    • 이거 내가 맨날 해야 한다고 하는거!!!! 특히 대시보드 업데이트하면 공지하라고 말 하는데, 나 밖에 안 함…
    • 대시보드를 프로덕트 처럼 관리한다고 했을 떄, 변동 사항 히스토리를 남길 수 있게 위키를 대시보드마다 하나씩 파서 관리하는 것이 좋을 것 같다
    • 그럼 변경된 내용만 상위에 노출시켜 위키 링크만 유관 부서에 전달하면 될테니까? 메일 또는 슬랙이든 편한 채널로.
  • VOC의 중요성을 언급하며 이걸 주기적으로 접하는 환경 구축 방법과 그걸로 어떤 것을 할 수 있는지 다룬 부분이 있는데, 이거 분석가한테도 적용될 수 있을 것 같다
    • 여기서 프로덕트 = 태블로 대시보드다
    • VOC = 슬랙, 메일 등으로 오는 대시보드, 데이터에 대한 문의다. (어차피 분석가 외의 인원은 대부분 대시보드로 데이터를 접하고 있음)
    • VOC 리포트(사용자 ID, 고객 분류, 문의 사항, 문의 분류, 접속 경로, 기기 종류, 앱 버전 정보, 최초 가입일자, 최근 n일간 거래량, 최근 n일간 접수되는 voc 수)
    • 모든 VOC를 취합해서 전달할 필요는 없고, 기술적 문제에 대한 것만 취합해도 됨 = 필요한 VOC만 필터링 (=추천?)
    • 이걸 매일 접하다보면, 현재 프로덕트의 어떤 점이 불편하고, 어떤 점을 개선할 수 있을지 인사이트를 얻지 않을까?
  • 회의 때 스스럼없이 질문하는 성향이 생겼다는데, 다르게 말하면 남들 말하는 도중 끊고 질문한다는 것
    • 예의를 갖추는게 중요하다고 생각해서, 난 사실 회의 때 남들 말 끊은 적이 거의 없다.
    • 저 사람이 뭘 말하고 싶어하는지, 원하는게 뭔지 몰라 계속 듣기만 했던 적이 많다. 말하는걸 듣다보면 내 질문에 대한 답을 찾겠지라는 심정으로
    • 만약 내가 맡은 일에 대해 그런 태도였으면 잘못된게 맞다. 그래서 지금은 꽤 많이 소통이 늘은 편인데,
    • 만약 내가 맡은 일이 아님에도, 회의에 참석했다는 이유만으로 노를 하나 더 저어도 될까?

어떤 인재를 PO로 선발해야 하는가

  • PO와 PM, TPM 간 차이에 대해 말해주는데 뭔가 PM이 PO에 종속된 듯한 느낌
    • 협업 관계라고 했는데, PO가 틀을 잡으면, PM이 이걸 구체화, 실현시키는 것 같다
  • 수직적 위계구조 형태라 윗선에서 시킨 내용을 그대로 이행해야 하는 경우엔 PO를 채용해선 안된다고 함
    • 신속하게 가설을 설정하고, MVP를 만든 후 테스트 진행해서 검증하는 것을 지속적으로 할 수 있는 환경이어야 한다고 함
  • 면접 때, 최근 업무를 중점적으로 이야기 한다고 함
    • 몇 년 전에 무엇을 했는지, 오래 전에 어떤 학교를 나왔는지 등은 판단하는데 큰 도움이 안됨
    • 오히려 그 학교를 나와서 오래전부터 꾸준히 거쳐온 경험의 결과물인 현재의 사고방식을 이해하는 것이 중요함
    • 지원자가 여러 가지 결정을 왜, 어떻게 내렸는지 이해하기 위해 deep-diving 한다고 함
    • 내가 맡은 프로덕트(작업)이 회사 전체의 목표에 어떤 역할을 하고 있는지 알고 있어야 함
    • 고객 중심적인 사고 방식을 통해 성공 지표를 설정해본 경험이 있는지 확인하는 것이 중요함
    • 비단 PO 면접 뿐만 아니라, 대부분 면접에서 써먹을수 있을 것 같다. 이거 토대로 내 커리어 정리해보면 좋을듯