왜 하버드 MBA 졸업생들이 프로덕트 오너가 되려 하는가? 프로덕트 오너가 하는 일과 필요한 자질은? 지금 글로벌 IT 기업들은 PO 영입 전쟁 중이다! 쿠팡의 프로덕트 오너가 말하는, 감동적인 서비스를 만드는 대원칙 고객이 열광하는 서비스는 어떻게 만들어지는가? 끊임없는 혁신을 통해 최강의 프로덕트를 만드는 비즈니스 원칙 이 세상에는 다양한 프로덕트가 존재한다. 지구 반대편의 토크쇼 영상을 침대에 누워 볼 수 있게 해준 유튜브, 친한 이들과 이모티콘을 주고받으며 대화를 나누게 해준 카카오톡, 여러 사람의 사진과 동영상을 제공하는 것은 물론 검색 엔진의 자리까지 넘보는 인스타그램, 송금이 필요할 때 공인인증서를 사용할 필요 없이 순식간에 돈을 보내주는 토스, 원하는 상품을 자정까지 주문하면 새벽에 문 앞에서 받아볼 수 있게 해주는 쿠팡까지. 가장 사랑받는 프로덕트는 고객에게 감동을 준다. 그리고 고객에게 감동을 주기 위해 고민을 거듭하는 사람들이 프로덕트 오너(Product Owner, PO)다. 구글, 넷플릭스, 아마존, 배달의민족 등 수많은 사람들이 사용하는 서비스는 각 회사의 PO가 기획 단계부터 디자인, 개발, 출시, 분석까지 모두 책임지고 있다. 한국에는 쿠팡이 거의 최초로 PO라는 개념을 전파시켰고, 최근 몇 년 사이에 대부분의 IT 스타트업 및 대기업들이 프로덕트를 전담으로 책임지는 유능한 PO를 찾고 있다. 미국에서는 이미 MBA 학위 소지자들이 월스트리트 또는 컨설팅 회사를 외면하고 실리콘밸리에서 PO가 되기 위해 진로를 바꾼 지 오래다. 그런데 IT 최강국이라 인식되는 대한민국이지만, 국내에는 아직 정식으로 프로덕트를 관리하는 PO 인력이 부족하다. 제조업과 인프라는 우수해도, 소프트웨어 프로덕트를 책임질 실력파 PO는 손에 꼽힌다. PO로 채용되는 이들 중에도 정작 PO가 정확히 무엇을 어떻게 해야 하는지 잘 모르는 경우가 많다. 이 세상의 모든 업계가 디지털화되면서 PO의 수요가 증가하여 이 직군에 대한 시장의 관심은 커지는데, PO가 어떻게 프로덕트를 만드는지 알려주는 도서는 국내에 단 한 권도 없다. 한국 IT 업계가 실리콘밸리의 십 년 전 상황과 비슷하다고 말하는 이유다. MIT가 선정한 가장 스마트한 기업 쿠팡의 프로덕트 오너로, 〈포브스〉지의 ‘아시아 30세 이하 30인’에 선정되기도 한 저자는 이 책에서 프로덕트 오너는 도대체 무엇을 하는 사람이고 갖춰야 하는 자질은 무엇인지, 프로덕트는 어떻게 만들어야 하는지 알려준다. 저자가 그동안 축적한 프로덕트 관리 노하우가 집약된 이 책을 통해 프로덕트 오너에 대한 통찰력, 고객 경험의 핵심인 프로덕트에 대한 이해, 더 나아가서 프로덕트 조직을 이끄는 리더십에 대한 통찰력을 높일 수 있는 기회가 될 것이다. 프로덕트의 시작부터 끝까지 책임지는 포인트가드, 제대로 된 PO가 고객을 감동시키는 서비스를 만든다! ‘미니 CEO’라는 별명을 가진 프로덕트 오너는, 말 그대로 하나의 프로덕트에 대한 책임을 지고 기획, 분석, 디자인, 개발, 테스트, 출시, 운영까지 주도하는 사람이다. 국내에서는 프로덕트 매니저(PM, Product Manager) 또는 프로젝트 매니저(PM, Project Manager), 기술 매니저(TPM, Technical Program Manager) 등과 혼용되어 사용되기도 한다. 국내 IT 업계에서 흔히 알려져 있는 기획자와는 달리, PO는 프로덕트와 이를 사용하는 고객에 집착하면서 최고의 프로덕트로 개선하기 위해 전적인 책임을 지닌다. 산업 공장에서 제품을 생산하듯이, 실리콘밸리 같은 곳에서는 IT 기업이 인스타그램, 유튜브, 넷플릭스 같은 프로덕트를 만들어낸다. PO가 이러한 프로덕트를 기획하고 개발해 선보이는 과정에서 끊임없이 고객의 목소리를 경청하고, 데이터를 기반으로 결정을 내리는 방법은 다양한 산업에 적용시켜도 효과적이다. 실제로 현재 전 세계 PO가 따르는 원칙 중 상당수가 이미 수십 년 전부터 P&G나 도요타 같은 전혀 다른 산업에서 파생되었다. 『프로덕트 오너』는 이처럼 떠오르는 신종 직업인 PO가 무엇을 하는 직무인지에 대한 설명을 시작으로, 하나의 프로덕트를 만들기 위해 PO가 거치는 과정을 처음부터 끝까지 설명한다. 데이터를 어떻게 수집하고 분석하는지에 대한 안내부터, 모바일 앱 디자인 피드백을 어떻게 전해야 하는지, 심지어 고객 콜센터와의 협업 과정까지 알린다. 신속하고 효율적으로 디자이너 및 개발자들과 협업하기 위해 스프린트, 스크럼 회의, 백로그, 회고 등 다양한 애자일 전략이 적용된다. 각 챕터는 PO가 명심해야 할 원칙을 중심으로 작성되며, 그 원칙을 설명하기 위한 다양한 예시들이 활용된다. 따라서 이 책은 다음과 같은 독자의 궁금증을 해결해줄 것이다. -고객이 열광하는 프로덕트는 어떻게 만들어야 하는가? -혁신과 급성장을 동시에 하는 기업의 프로덕트는 어떻게 만들어지는가? -프로덕트 오너는 도대체 무엇을 하는 사람이고 갖춰야 하는 자질은 무엇인가? -신속하고 효율적으로 기업을 경영하려면 애자일 방식을 어떻게 조직에 적용해야 하는가? 쿠팡의 PO가 알려주는 애자일 혁신 전략의 모든 것 우리 주변 곳곳에서 디지털화는 가속화되고 있다. 몇 년 전과 비교해보면, 음식을 주문하는 방식이 바뀌었고, 은행 업무를 보는 방법도 변했으며, 쇼핑 방식도 달라졌다. 우리의 삶은 다양한 프로덕트 덕분에 개선되고 있다. 앞으로는 인공지능, 머신러닝 등의 기술을 통해 눈에 안 보이는 곳에서 프로덕트가 우리를 더 편한 삶으로 이끌어줄 것이다. 프로덕트의 경쟁력이 결국 회사의 경쟁력인 이 시대에, 프로덕트를 책임지는 PO의 중요성 역시 더욱더 커지고 있다. 이 책은 날이 갈수록 편해지는 고객 중심의 서비스가 어떻게 만들어지는지 상세하게 알려주는 국내 최초의 도서다. 제품이나 서비스를 책임지는 사람이 가져야 하는 마음가짐부터 시작해서, PO가 어떤 자질을 갖춰야 하는지, 기획, 분석, 디자인, 개발, 실험, 론칭에 이르기까지 애자일 전략을 어떻게 적용하는지 설명한다. 프로덕트를 담당하는 PO는 물론, 경영인과 스타트업 창업자에게 유용한 정보로 채워져 있어 IT 프로덕트와 상관없는 업계의 직장인은 물론, 우리가 사랑하는 서비스가 도대체 어떻게 개발되는지 알고 싶은 독자에게 신선한 시각을 제공해줄 것이다.

추천의 글 프롤로그 1장 프로덕트 오너PO는 미니 CEO다 PO는 중심에 있다 독재자형 리더는 안 된다 책임은 있지만 권한은 없다 고객에 집착하고 또 집착하라 TIP 1 PO가 되기 위해 필요한 자질 2장 고객의 목소리를 어디까지 반영할 것인가 고객은 제품을 사지 않는다, 고용한다 서비스는 하나라도 사용자 유형은 다양하다 모든 사람을 만족시킬 수는 없다 식스 페이저로 모두의 동의를 얻어 기록하라 고객의 요청과 회사가 정한 목표가 충돌한다면 TIP 2 페르소나와 고객을 혼동하지 마라 3장 데이터 속에서 진실을 찾는 법 자신을 믿지 말고 데이터를 신뢰하라 대시보드를 통해 정기적으로 확인하라 행동을 부르지 않는 데이터는 버린다 가설을 세우고 조직의 방향성OKR까지 관리하라 리스크를 최소화하기 위한 데이터 검증법 TIP 3 데이터 대시보드도 프로덕트다 4장 효율적인 일정 관리의 비밀 스토리 티켓으로 누구에게 무엇을 알려야 하나? PO가 해서는 안 되는 일 스크럼 회의 때 해야 할 일들 TIP 4 자신만의 백로그 관리 방법을 갖추기 5장 디자이너를 최고의 파트너로 삼는 법 디자이너는 PO의 의도를 구현해주는 최고의 파트너다 과연 편리하고 직관적인 디자인인가? 동료 직원을 대상으로 캐주얼 UT를 하라 TIP 5 의견과 요구사항은 다르다 6장 개발팀과의 협업을 성과로 이끄는 애자일 전략 확실한 프로젝트 수행법, 스프린트 플래닝 완료일을 언제로 잡는 것이 시기적절한가 모든 질문에 대답할 수 있는 소통의 기술 TIP 6 속도와 확장성 사이에서 고민하라 7장 고객 테스트 결과만큼 강력한 데이터는 없다 사용자 테스트UT로 문제점을 보완하라 빠른 피드백 공유는 동기부여가 된다 스프린트 기간 중 언제 테스트하는 것이 효과적인가 TIP 7 UT는 설문조사가 아니다 8장 프로덕트를 출시하는 최적의 시기 배포 일정을 정할 때 플랫폼을 고려하라 A/B 테스트를 활용해 트래픽을 분산하기 내부 직원도 고객이다 TIP 8 올바른 배포 문화를 만들자 9장 테스트 중 가설을 효과적으로 검증하려면 A/B 테스트와 P값을 활용한 가설 검증법 실패를 인정할 줄 알아야 더 나은 경험을 제공할 수 있다 통계적인 결과를 토대로 결정해야 진실에 가까워진다 TIP 9 검증하려는 수치는 미리 정하자 10장 론칭한 서비스의 문제를 바로잡기 업데이트 소식을 고객센터에 먼저 전달하라 프로덕트는 완벽할 리 없다 시간 낭비를 최소화하기 위한 전략 고객의 소리를 들을 수 있는 환경을 조성하라 멀티태스킹으로 문제를 해결하는 세 가지 원칙 TIP 10 5 Why 방식을 고수하자 11장 어떤 인재를 PO로 선발해야 하는가 PO 채용에 앞서 일감부터 확인하자 무한한 잠재력을 알아보는 법 능력 있는 PO로 성장하는 길 TIP 11 처음부터 PO가 아니어도 된다

이 책에서 나는 최고의 프로덕트를 만들어서 고객에게 감동을 주는 방법을 체계적으로 설명하려고 최선을 다했다. 일을 하는 사람이면 누구나 이해할 수 있는 단어를 사용하고자 했다. 체계적인 것은 비교적 쉽게 따라 할 수 있기 때문이다. 이 책에 제시된 사례와 방법, 원칙을 통해 수많은 프로덕트가 탄생하길 진심으로 바란다. -〈프롤로그〉 중에서 구글의 프로덕트 매니저로 활약한 후 구글의 벤처 투자 회사인 GV의 파트너가 된 켄 노튼은 “장기적으로 봤을 때, 프로덕트 매니징을 잘하면, 이기고 지는 상황에서 승자가 될 수 있다”고 말했다. 그 기대치 때문인지, 꽤 많은 국내외 회사가 PO 직무를 설명할 때 미니 CEO라고 말한다. 혹하는 별칭에다가 상대적으로 높은 보수까지 챙겨주니, PO가 CEO처럼 결단을 내리는 사람이라고 착각을 부르기 쉽다. 하지만 현실은 그렇지 않다. (…) PO는 절대로 군림하는 존재가 아니다. 사실, CEO보다 ‘미니 CEO’로 불리는 PO가 하는 일이 더 어려울 수도 있다. 왜냐하면 주어진 권한이 전혀 없기 때문이다. 그래서 PO는 늘 명확한 사실과 데이터를 가지고 설득해야 한다. -〈1장 프로덕트 오너는 미니 CEO다〉 중에서 식스 페이저에서 가장 중요하게 생각하는 부분은 거의 첫 장에 나온다. 나는 그것을 “우리는 고객을 위해 어떤 일을 하는가?”라고 칭한다. 이 부분에서 나는 해당 프로덕트가 고용되는 이유를 목록 형태로 작성한다. 이런 목록을 작성하고 다른 이들의 의견을 받아 확정 지을 때까지 다섯 번 이상의 검토를 받은 적도 수두룩하다. 별 거 아닌 것 같지만 단어 하나하나에 집착하며 수정을 거듭하는 이유는, 프로덕트를 개발하기 전 고객이 어떤 일을 해결하기 위해 프로덕트를 고용하는지 PO가 먼저 완벽하게 이해하고 있어야 하기 때문이다. 그래야 프로덕트를 고객에게 선보일 때까지 모두가 동일한 관점에서 의견을 피력할 수 있다. (…) PO는 프로덕트를 기획하거나 개발 방향을 결정할 때, 어떤 고객이 왜 해당 프로덕트를 고용할지 철저하게 고민해야 한다. 설문 조사나 이미 지나간 과거의 데이터를 보고 시장의 수요를 추측하는 것은 PO에게 적절한 방식이 아니다. 당장 직면한 현재의 고객이 어떤 제품을 고용하고 있는지, 그리고 왜 그걸 선택하는지에 대한 관점으로 분석하도록 해야 한다. -〈2장 고객의 목소리를 어디까지 반영할 것인가〉 중에서 풍부한 데이터 속에서는 여러 가지 인사이트를 추출할 수 있다. 그리고 그런 정보로 훌륭한 결단을 내릴 수도 있다. 하지만 PO는 자신의 눈을 전적으로 믿지 말아야 한다. 데이터를 뜯어보고 또 보고, 데이터가 축적되는 방식까지도 검증하도록 한다. 오랜 기간에 걸쳐 확인한 데이터더라도, 그게 진정으로 진실을 대변하는지 주기적으로 의문을 가지자. 데이터의 신뢰도를 실험하고, 노이즈를 파악하며, 전체적인 그림을 그릴 수 있게 된다면 PO는 더더욱 진실에 가까운 위치에서 프로덕트를 개선할 수 있게 된다. -〈3장 데이터 속에서 진실을 찾는 법〉 중에서 개발자들이 다루는 코드와 달리, 디자인 시안은 보편적으로 더 쉽게 파악할 수 있기 때문에 PO가 디자이너의 업무에 간섭할 확률이 더 높다. 디자이너가 고객 경험에 대한 전문가라는 사실을 명심하고, 최적화된 산출물이 나올 수 있도록 도움을 줘야 한다. PO가 구상하고 테스트해보고자 하는 방향성을 구현해줄 파트너라는 점을 늘 기억하라. 그래야 명확한 원칙에 기반한 훌륭한 프로덕트가 탄생할 수 있다 -〈5장 디자이너를 최고의 파트너로 삼는 법〉 중에서 PO는 늘 다른 팀원보다 조금 더 멀리 내다보고 있어야 한다. 개발자나 디자이너가 궁금해하기도 전에, 최대한 미리 정의를 다 해놓고 제공하는 것이 최적화된 협업 방식이라고 생각한다. 고객이 무엇을 원하는지, 협업하는 유관 부서의 상황은 어떤지, 언제까지 필요한 요소들이 완성되는지 등, 팀원들이 언젠가 물어볼 것 같은 질문을 미리 예상하고 답을 마련하라. 단 1초라도 허비하지 않고 계획된 스프린트 플래닝에 맞춰 나아갈 수 있도록 말이다. 프로덕트를 고객에게 원활하게 선보이려면, 팀원들이 집중할 수 있도록 PO는 모든 것에 미리 대답해둬야 한다. -〈6장 개발팀과의 협업을 성과로 이끄는 애자일 전략〉 중에서 아무리 답답해도 PO는 통계적 의미를 믿고 차분히 기다려야 한다. 예를 들어, 7일 동안 테스트를 진행하려 계획했는데, 2일 차에 P값이 매우 낮게 떨어지는 경우가 있다고 가정해보자. 그러면 나머지 5일 동안 테스트를 더 진행해야 하는지 스스로에게 되물을 수 있다. 당장이라도 고객에게 적용할 수 있다는 생각이 들기 때문이다. 하지만 7일이라는 기간을 모두 거쳐야 시기에 따른 편차도 테스트가 감안할 수 있게 된다. 고객은 일요일과 월요일의 행동이 다르고, 목요일과 토요일의 행동이 또 다르기 때문이다. 일주일은 모두 거쳐야 이런 기간적 변동 Seasonality을 통계적으로 헤아릴 수 있게 된다. -〈9장 테스트 중 가설을 효과적으로 검증하려면〉 중에서