프로덕트 오너: PO가 말하는 애자일 혁신 전략

 

 책 추천을 기가 막히게 하는 동료가 있다. 박신영 작가 시리즈에 이어, 제임스 클리어의 <아주 작은 습관의 힘>까지. 계속 읽고 싶었지만 더 이상을 미룰 수 없었던 <프로덕트 오너>를 드디어 읽게 되었다. 요근래 들어 리더의 중요성, 일의 효율성을 높이는 방법, 협업하는 방법등에 대해 많은 생각이 들기 시작했다. <프로덕트 오너>를 시작으로 '조직의 리더십'과 관련된 책 10권을 한 번 준비해 보았다. 

 

1장 프로덕트 오너는 미니CEO다

 PO는 모든 사람이 지켜보는 존재야. 개발자, 디자이너, 비즈니스 애널리스트 등은
물론 회사 내외부 고객과 사업부, 심지어 나 같은 경영인까지 지켜보고 있어.

 PO는 중심에 있다. PO는 불확실함 속에서 진실을 간파하는 통찰력을 지녀야 한다. 다양한 분야의 사람들과 소통은 물론, 기술적으로 개발 가능한지, 디자인 관점에서 타당한지 등을 확인하기 위해 메이커들과 소통한다. 혹시 모를 법률적 문제를 미연에 방지하기 위해 법률팀의 검토도 받는다. 

 독재자형 리더는 안 된다. 디자이너나 개발자에게 "이거 중요하니까 빨리 해주세요"라고 말하기는 쉽다. 하지만 아무리 급해도 결정을 일방적으로 통보하는 태도로 임한다면, 장기적으로 다른 이들에게 존중받기 어렵다. 왜 우선순위가 급하게 변경되었는지, 무엇을 이루고자 하는지를 당연히 알려줘야 한다. 만약 이미 진행 중인 개발물이 있을 경우, 그것을 우선순위에서 하향 조정할지도 결정해줘야 한다. PO는 최대한 많은 맥락을 설명해줘야 한다. 같이 협업하는 동료의 상태를 파악하는 일이 가장 우선이다. 동료의 상태가 좋지 않으면 결과물도 좋지 않다. 

 책임은 있지만 권한은 없다. 연봉이나 승진에 영향을 줄 수 없으며, 해고도 할 수 없다. PO의 자리는 늘 설득의 연속이다. 자신의 실력을 끊임없이 증명하면서 다른 이들에게 존중받아야 한다. 단기간에 이들의 마음을 얻는 것은 매우 힘들지만, PO는 책임감 있는 모습을 보여주면서 함께 일하는 동료들과 고객이 존중하는 사람이 되려고 노력한다. 문제가 발생하면 PO에게 질문과 눈길이 쏠리지만, 큰 성공을 거두면 PO는 함께 이룬 동료들에게 공을 돌린다. 그들이 직접 두 손으로 만든 서비스이기 때문이다. 부여된 책임감은 많지만, 권한이 없는 PO는 언제나 겸손해야 한다. 

 고객에 집착하고 또 집착하라. 고객을 직접 이해하려는 노력은 PO에게 필수다. 작가는 쿠팡에서 로켓배송에 활용되는 알고리즘을 만드는 데이터 사이언스 조직과 함께 일하게 되었다. 그래서 그는 직접 쿠팡맨이 되어 실제 배송을 해봤다. 고객에 집착하는 사고방식을 주변 동료들에게 전파해야 한다. 단순히 개발을 하거나 디자인 시안을 만드는 것이 아니라, 그것이 고객에게 얼마나 큰 감동을 줄 수 있는지 각자 충분히 인지할 수 있도록 설명해주는 것도 PO의 몫이다. 모두가 고객에 집착할 때까지 PO에게는 직접 현장에서 터득하고 정보를 공유해야 하는 책임이 있다.

 

2장 고객의 목소리를 어디까지 반영할 것인가

 고객은 제품을 사지 않는다, 고용한다. '식스 페이저(6-Pager)라고 부르는 이 문서는 여섯 페이지 이내에 해당 프로덕트에 대한 핵심내용을 담아내는 것이다. 프로덕트의 목적이 무엇인지, 과거에 어떤 고나련된 시도를 했는지, 어떤 실패 사례가 있었는지, 앞으로 어떤 방향으로 개발할 건지, 그리고 어떤 수치를 활용해서 성공 여부를 확인할 것인지 등을 최대한 간결하고 정확하게 서술한다. 고객은 언제나 해결해야 할 일들에 둘러싸여 있고, 그것을 해결해줄 제품과 서비스를 고용할 준비가 되어 있다. PO는 고객이 흔쾌히 고용할 프로덕트를 만들고 꾸준히 개선해야 한다.

 서비스는 하나라도 사용자 유형은 다양하다. 고객은 모두 똑같이 않다는 사실을 받아들여야 한다. 1) 구체적인 목적이 있는 고객, 2) 목적이 있지만 발견해야 하는 고객, 3) 발견을 원하는 고객. PO가 범하기 쉬운 실수 중 하나는 프로덕트를 만드는 사람의 관점에서 고객을 바라보는 것이다. 그렇게 하면 무의식적으로 PO 자신이 만들고 싶어 하는 방향으로 데이터를 해석하고 결정해버릴 수 있다. PO는 절대로 자신의 직관이나 바람에 의한 결정을 내려서는 안 된다. 

 모든 사람을 만족시킬 수는 없다. PO는 언제나 우선순위를 정해야 한다. 어떨 때는 명백하게 무엇을 해야 할지 눈에 보일 떄도 있지만, 때에 따라서는 일부 고객의 요청을 잠시 보류해야 할 수도 있다. 그때마다 늘 한정된 자원을 어떻게 활용해야 가장 효과적일지 고민하도록 한다. 얼마만큼의 공수를 투입하여 얼마만큼의 임팩트를 낼 수 있는지 논리적으로 따져보고 최적의 결정을 내리는 책임을 지녔기 때문이다.

 식스 페이저로 모두의 동의를 얻어 기록하라. 고객의 요청은 다양하지만 자원은 한정적이다. 그래서 원칙이 필요하다. 작가는 식스 페이저 문서를 작성할 때, 고객 분류와 더불어 공을 제일 많이 들이는 것이 바로 '가이드 원칙'이다. 4~6개의 원칙을 목록화하며, 해당 프로덕트를 개발하거나 운영할 때 꼭 지켜야 하는 법 같은 것이다. 1번이 가장 중요한 원칙이고, 내려갈수록 부수적인 것들로 채운다. 이 원칙을 허투루 작성해서는 안 된다. 짧고 명확하게!

 고객의 요청과 회사가 정한 목표가 충돌한다면. PO가 회사의 성장 전략을 짜지도, 기술 전략을 정립하지도 않는다. PO는 고객만 대변해서는 안된다. 회사 내 전문가들의 의견을 종합하고, 고객의 목소리를 함께 고려하면서 프로덕트가 어떻게 발전해야 최대한 많은 요구사항을 충족할 수 있을지 고민해야 한다. 아무리 고객에게 더 나은 가치를 제공하기 위해 집착하는 PO지만, 회사가 정한 방향성과 목표를 절대로 잊어서는 안 된다. PO는 단순히 프로덕트를 만드는 사람이 아니라, 고객과 회사 모두가 필요로 하는, 제대로 된 프로덕트를 책임지는 사람이라는 점을 명심하자. 고객에게 게속 최상의 경험을 제공하려면, 회사가 건강한 상태여야 한다. 고객의 목소리에 귀 기울이는 것 만큼 회사가 정한 목표와 의견에도 집중하도록 하자. 회사가 없으면 고객에게 더 나은 경험을 제공할 기회까지 사라지기 때문이다.

 

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

 자신을 믿지 말고 데이터를 신뢰하라. PO는 직관에 의존하면 안 된다고 생각한다. 매 결정이 상당히 큰 영향을 끼치므로, 최대한 이성적으로 판단할 수 있도록 데이터에 기반한 사고방식을 갖추도록 한다. 자신이 바라보는 관점이 맞는지, 예상이 맞을지 확인하는 것도 데이터로 검증한다. 데이터는 최대한 다양하게 수집한다. 전체적인 상황을 이해하기 위해서다. 거짓 양성과 거짓 음성이 알고리즘으로 인해 쌓이게 되면 그간 분석한 결과도 정확하지 않는다. 노이즈들이 양질의 데이터에 섞이지 않게 주의하자. 

 대시보드를 통해 정기적으로 확인하라. 애널리스트 등의 도움을 받아 대시보드를 생성한다. 데이터가 축적되고 있지 않다면, 개발팀과 데이터 엔지니어의 도움이 필요할 수 있다. 1) 주요 대시보드 만들기, 2) WBR(주간 실적분석 만들기). 

 행동을 부르지 않는 데이터는 버린다. 참조할 수 있는 것과 실행할 수 있는(Actionable)한 데이터를 구분해야 한다. 그래서 같이 일하는 사람들이 헛일을 하지 않도록 PO는 일을 잘 주어야 하는 것이다. PO는 다양한 데이터를 접할 수밖에 없다. 옆에서 개발자나 애널리스트, 데이터 과학자가 다양한 데이터를 제시할 수도 잇다. PO는 데이터를 단면적으로 보지 않아야 한다. 그리고 자신을 포함한 모든 이들이 쓸데없는 이슈를 파악하는 데 시간을 낭비하지 않도록, 데이터가 액셔너블한지 아닌지 재빨리 알아내야 한다. 

 가설을 세우고 조직의 방향성까지 관리하라. 가설은 PO의 생각을 증명하기 위해 꼭 필요한 수단이다. 아무리 논리적으로 접근하고 설득해도, 테스트와 데이터를 통해 증명할 방법을 마련하지 못하면 개발에 착수하지 않아야 한다. PO의 제안이 틀렸ㄴ느지 증명하고, 당장 기능을 제거해야 하는지 결정 내릴 잣대가 있어야 한다. 데이터에 노이즈가 있다면 반드시 제거해야 한다. 노이지 때문에 자신의 가설이 맞는 것처럼 보일 수도 있으니, 명확한 결과를 얻기 위해 치밀하게 검증하길 바란다. 

 리스크를 최소화하기 위한 데이터 검증법 자신이 책임지고 있는 프로덕트와 관련되어 어떤 데이터가 축적되고 있는지 명확하게 알아야 한다. 만약 기존 데이터만으로는 유의미한 테스트가 불가능하다고 판단되면, 개발팀과 논의하여 필요한 데이터가 쌓일 수 있는 구조로 개선하도록 하자. (+리액트 네이티브 형태를 활용하면, 한 가지 코드 베이스를 가지고 동시에 안드로이드나 iOS 모바일 앱을 만들 수도 있다.) / 어플리케이션 테스트 방식 중에, 고객을 임의로 A팀과 B팀으로 나누어 어느 쪽에 매출이 더 뛰어난지 테스트하는 A/B 테스트 방법이있다. 

 

4장 효율적인 일정 관리의 비밀

 스토리 티켓으로 누구에게 무엇을 알려야 하나? 큰 규모의 신규 기능을 만들기 전, 개발을 주도할 개발자에게 서로 어떤 티켓을 할당해야 할지 알려준다. 개발 과정에서 PO가 해야 하는 가장 큰 임무 중 하나가 구체적인 요구사항을 정하는 것이고, 그걸 개발팀에 전하는 방식이 바로 이 티케팅이기 때문이다. 목적, 배경 정보, 고객을 위해 어떤 일을 하는가?, 원칙, 목표, 주요 지표, 개발 계획, 자주 묻는 질문 등을 고려한다. 

 <에픽:Epic> : 주로 새로운 프로덕트를 만들거나 중요한 신규 기능을 개발할 때 활용한다. 에픽 티켓 아래에 스토리 티켓을 다수 생성해서 관리하는 형태다. 모든 스토리와 태스크 티켓이 완료되었을 때, 비로소 에픽은 개발 완료 상태로 변하게 된다. 목적, 개발 타당성, 목표, 주요 수치 등. 

<스토리:Story> :  에픽을 달성하기 위해 큼지막하게 분류하는 것이 스토리 형태다. 구체적인 개발 요구사항을 가장 중요하게 다룬다. 글로만 작성하는 것은 한계가 있기 때문에, 별도 UX흐름 문서나 디자인 시안 등을 링크 또는 첨부 파일로 추가한다.

<태스크:task> : 태스크는 하나의 스토리가 완료되기 위해 개발되어야 하는 것들을 더 잘게 나눈 형태다. 스토리에 연결된 모든 태스크 티켓이 완료되어야 하나의 스토리가 완료된다. 

 PO가 해서는 안 되는 일 PO는 방향성에 대해 고민하고, 고객 입장에서 생각하며, 데이터를 분석하고, 여러 결정을 시시때때로 내려야 하는 직무인데, 개발까지 맡는 것은 여러 가지 이유로 옳지 않다. PO의 임무는 개발을 직접 하는 게 아니라, 개발자, 디자이너, 비즈니스 애널리스트 등이 각자의 임무를 잘 이행할 수 있도록 요구사항을 명확하게 하고 방향성을 제시하는 데 집중해야 한다. 

 스크럼 회의 때 해야 할 일들 새로운 프로젝트가 시작되면, 문서나 티켓을 생성해야 한다. 변경사항이 발생할 때마다 곧바로 메모를 해뒀다가, 최단 시간 내에 문서나 티켓을 수정해야 한다. 요청사항 정리를 구체적으로 해서 소통의 장을 만들어야 한다. 대부분 PO는 요청사항을 전달받으면, 티켓으로 생성해뒀다가 나중을 위해 보관해두는 방식을 개발 백로그라고 부르기도 한다. 

 

5장 디자이너를 최고의 파트너로 삼는 법

 디자이너는 PO의 의도를 구현해주는 최고의 파트너다. 프론트 엔드를 담당하는 PO에게는 디자인이 매우 중요하다. UX/UI 디자이너는 PO가 의도한 바를 해석하여 구현해주는 최고의 파트너가 될 수밖에 없다. 디자이너가 동일한 목적 의식을 갖고 작업할 수 있도록 도움을 줘야 한다. 시안 작업이 진행되는 도중에도 스크럼 회의 등을 통해 어떤 지표를 달성해야 하는지, 그렇게 달성할 경우 고객과 회사에 끼치는 영향이 무엇인지 등을 추가적으로 설명해줘도 된다. 

 과연 편리하고 직관적인 디자인인가? 주로 시안은 PO가 정해준 원칙 내에서 산출되기 때문에, PO가 전체적인 흐름을 단번에 파악하기는 쉽다. 하지만 처음 접하는 사용자에게는 모든 것이 새롭다. 그런 고객이 고민하지 않고 직관적으로 사용할 수 있는 프로덕트를 만들어야 한다. 그래서 PO는 완전히 처음 접하는 입장이 되어, 화면에 보이는 모든 것을 탐구하듯이 뜯어봐야 한다. 작가는 휴대폰에 1,000개가 훨씬 넘는 어플리케이션을 다운받았었다고 한다. 처음 앱을 설치할 때, 아무 생각없이 접해서 편리함이나 불편함들을 몸소 체크하는 것이다. 

 동료 직원을 대상으로 캐주얼 UT를 하라. 실제 고객을 대상으로 UT(User Test)를 하기 전에 동료 등 내부 직원을 대상으로 간소화된 절차로 진행하는 형태를 캐주얼 UT라고 한다. 대상자가 편하게 자신의 생각을 구두로 설명하도록 유도하라. 대상자 한 명으로부터 너무 많은 것을 얻어내려고 하지 말고, 짧게 짧게 다수의 대상자를 통해 진행한 후 대다수가 느끼는 부분을 확보하는 것이 훨씬 더 유용하다. 

 

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

 확실한 프로젝트 수행법, 스프린트 플래닝 스프린트 플래닝은 말 그대로 하나의 스프린트를 계획하는 회의다. '단거리 전력 질주'라는 뜻의 스프린트는 애자일 방식의 조직에서 2주 단위로 나눠 집중 개발하는 것을 말한다. 기능의 명칭, 관련된 에픽명, 티켓 링크, 담당자, 배포 일자, 주요 일자 등을 정리해서 이전 스프린트에 개발완료한 것을 공유한다. 이전 스프린트에서 개발을 완료하지 못한 채 다음으로 넘어 가는 것을 '스필오버(Spillover)'라고 부른다. 기술적 이슈나 버그가 있다면 '인시던트 리뷰(Incident Review)'를 진행하여 원인, 대응 방식, 개선책 등을 심도 깊게 논의한다. 그리고 조직원 각자가 느낀 이전 스프린트에 대하 회고를 작성한다. 

 완료일을 언제로 잡는 것이 시기적절한가. PO가 범하기 쉬운 실수 중 하나가 일방적으로 완료예정시간ETA을 개발 조직에 강요하거나, 혹은 반대로 개발 조직의 의견에만 의존하여 ETA를 역으로 산정하는 것이다. PO는 일방적으로 강요하지도, 일방적으로 강요받지도 말아야 한다. 고객에게 선보여야 하는 일정, 사업적으로 달성해야 하는 목표, 개발 조직의 여건 등을 두루 고려한 후 최적의 완료 일정을 협의하도록 한다. 한정된 자원과 시간 내에 최대한 많은 가치를 선보이는 것이 PO의 책임이다. 원만한 관계를 유지하며 반문과 집중 탐구를 통해 그 목적을 달성할 수 있도록 노력하기 바란다. 

 모든 질문에 대답할 수 있는 소통의 기술 PO가 대신 소통을 책임지는 것이다. 주기적으로 직접 유관 부서원들을 만나 의견을 취합한 뒤, 개발 조직과 공유한다. PO는 개발자나 디자이너가 그 어떤 질문이든 편하게 물어볼 수 있는 환경을 조성해야 한다. 

 

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

 사용자 테스트(UT)로 문제점을 보완하라. 프로토타입이 완성되는 동안, PO는 UT를 준비한다. 일단, 대상군을 정의하여 최소 세 명 이상의 대상자를 선정한다. 대면 진행 방식과 원격 진행 방식으로 나누어 지는데, 시간비용적 및 효율적 측면에서 원격 진행이 더 낫다. PO는 대상자가 편하게 사용할 수 있도록 환경을 조성해주어야 한다. 

 빠른 피드백 공유는 동기부여가 된다. UT 이후, 개발 조직 전체에 공유한다. 개발팀에 최대한 신속하게 결과를 정리해서 개발조직에 전달하는 것도 중요한 작업이다. 그 다음 단계를 진행하기에 앞서 모두가 동일 선상에서 이해할 수 있도록 PO는 기록하고 구두로 설명하는 절차를 한시라도 빨리 밟도록 한다. 

 스프린트 기간 중 언제 테스트하는 것이 효과적인가 스프린트 중간인 금요일이나 월요일에 진행하는 것이 가장 효과적이라고 볼 수 있다. 최악의 경우까지 생각하면서 새로운 로직을 위한 요구사항 정의까지 신속하게 준비하면서 이끌어나가야 한다. 

 

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

 배포 일정을 정할 때 플랫폼을 고려하라. 배포란, 개발이 완료된 후, QA(Quality Assurance)라고 불리는 품질 또는 기능 테스트를 거친 뒤, 온전한 상태라고 판정되면 고객이 사용할 수 있도록 적용하는 것을 뜻한다. 모든 개발의 마무리는 배포이며, 신규 프로덕트일 경우 배포 일자가 흔히 일컫는 론칭 똔느 공개 일자라고 통욯되기도 한다. 플랫폼을 iOS, 안드로이드, PC까지 고려해야 하는데 iOS는 꽤 까다롭다. 애플 앱 스토어의 승인을 받아야 다운로드 또는 업데이트가 가능하다. 회사에 따라 사용률이나 매출이 급증하는 기간에는 배포를 금지할 수도 있다. 

 A/B 테스트를 활용해 트래픽을 분산하기 보편적으로는 A그룹과 B그룹으로 분류되는 로직을 무작위로 나눈다. 새로운 기능을 배포했을 경우, A그룹과 B그룹의 트래픽을 분석하는 것이다. 이렇게 트래픽을 예의주시해야 하는 이유는 여차하면 롤백(Rollback)으로 이전 버전으로 바로 되돌려야 하기 때문이다. 

 내부 직원도 고객이다. 일반 고객이 사용하는 프로덕트는 최대한 직관적으로 만들어야 한다. 개별적으로 설명하지 않아도 곧바로 이해하고 충분히 사용할 수 있도록 개발한다. UX 디자이너가 대부분 일반 고객이 사용하는 프로덕트 개발에 투입되는 이유다. 내부 고객용 프로덕트 또한 직관적으로 만들어야 하지만 내부 고객은 연락을 취하기가 상대적으로 수월하기에 피드백이 따르다. 여기서 가장 중요한 것은 '사용 안내서'다. 

 

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

 A/B 테스트와 P값을 활용한 가설 검증법 P값은(Probability Value; P-Value) 실험의 결과가 우연히 나타난 것인지 아닌지 판단할 때 사용되는 수치다. P값이 0에 수렴할수록 통계적 유의도는 100%에 가까워짐을 의미한다. 

 실패를 인정할 줄 알아야 더 나은 경험을 제공할 수 있다. PO는 자신이 선정한 가설을 테스트하기 위해 많은 지원을 받아야 한다. 개발 조직의 개발자들은 물론, 디자이너, 비즈니스 애널리스트, 운영 조직 등 다양한 사람들의 도움을 얻어 비로소 테스트를 할 수 있다. 그들의 도움을 받았다는 것은, 상당 기간동안 회사의 자원을 투자받았다는 것을 의미한다. 회사는 이 많은 인원을 고용하기 위해 보수를 지급하는데, 그들이 PO의 가설을 테스트하는 데 활용됐기 때문이다. PO는 더더욱 이성적이어야 한다. 아무리 자신의 팀원들이 많은 노력을 했어도, 결과가 유의미하지 않으면 납득하고 그다음 가설을 설정해야 한다. PO가 결정을 확실하게 내려야 개발 조직과 디자이너도 시간을 허비하지 않고 다른 목표 달성에 집중할 수 있기 때문이다. 

 통계적인 결과를 토대로 결정해야 진실에 가까워진다. 고객 수가 상대적으로 매우 적어서 유의미한 데이터를 뽑아서 분석하는 것이 불가능한 정도라도 직관보다는 통계적인 결과를 토대로 결정 내려야 한다. PO는 늘 이성적이어야 한다. 서두르지 말고, 충분한 고객이 유의미한 결과가 도출될 수 있도록 기다리자. 인내심을 가지고 기다리다 보면 진실에 더 가까워질 것이기 때문이다. 

 

10장 론칭한 서비스의 문제를 바로잡기

 업데이트 소식을 고객센터에 먼저 전달하라. 회사에서 새로운 기능에 대해 가장 잘 아는 사람은 PO다. 처음 들어보는 기능에 상담사도 답답함을 느낄텐데, 프로덕트가 변화할 경우 무조건 고객센터에 알려야 한다. 최대한 미리 개발 문서와 함께 주요 사용법을 정리해서 전달하는 걸 권장한다. 일반 고객이 아니라, 내부 고객이 사용하는 프로덕트가 업데이트되더라도 동일하게 안내해야 한다. 

 프로덕트는 완벽할 리 없다. 자신의 프로덕트에 문제가 발생한 것 때문에 초조하거나 창피해하는 PO도 있을 것이다. 하지만 이 순간만큼은 그런 감정을 느끼기보다, 매 초마다 고객에게 끼칠 영향을 고려하면서 최적의 결정을 내리는 것이 급선무다. 개발자의 역량, 소요될 시간, 고객의 상황 등을 종합적으로 살펴보며 적절한 시간에 과감한 결정을 내려야 할 수도 있다. 

 시간 낭비를 최소화하기 위한 전략 매우 빠른 속도로 발전하는 업계에 속해 있는 PO와 개발 조직은 시간이 귀하다. 스스로는 물론, 개발 조직과 디자이너, 비즈니스 애널리스트, 그 외 유관 부서원들의 시간을 조금이라도 허비하는 걸 극도로 꺼린다. 그들의 시간이 곧 자원이자 비용이고, 시간을 효율적으로 활용해야 고객에게 더 나은 경험을 계속해서 선보일 수 있기 때문이다. 

 고객의 소리를 들을 수 있는 환경을 조성하라. VOC(Voice Of Customer)은 고객의 소리를 뜻하는 것이다. PO에게 VOC만큼 소중한 정보는 없다. 고객의 의견을 수렴하고, 고객이 느끼는 불편함을 제거하고, 고객이 원하는 가치를 제공하는 프로덕트를 만들 때, 고객의 생각을 생생하게 접할 수 있다는 것은 축복에 가깝다. 고객 서비스 조직과 협업하여 VOC 리포트를 생성하는 걸 추천한다. 고객의 소리를 접하다 보면 새로운 아이디어가 떠오르기도 할 뿐더러, 반성도 하고 기쁨도 느낄 수 있기 때문이다. 

 멀티태스킹으로 문제를 해결하는 세 가지 원칙 PO의 삶에서 가장 고된 요소 중 하나는, 하루 종일 수많은 정보를 흡수하고 곧바로 생각을 정리해야 하는 것이다. 프로덕트 하나를 책임지든, 여러 개를 맡고 있든 상관없이, PO는 다양한 회의에 참석한다. 개발자와 이슈를 분석하는 회의, 디자이너와 시안을 검토하는 회의, 데이터 과학자와 알고리즘을 논하는 회의, 경영진과 다음 분기 목표에 대해 의논하는 회의, 그리고 수많은 유관 부서의 요청을 접하는 회의까지. 짧게는 15분에서 30분 다누이로 나눠 계획된 회의에 참석하기 위해 이 층, 저 층 이동하다 보면 뇌가 휴식할 틈이 없다. 무조건 메모! 우선순위 정하기! 커뮤니케이션!

 

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

 PO 채용에 앞서 일감부터 확인하자. PO가 설정한 목표를 달성할 수 있도록 세부적으로 조율하고 실행해주는 자가 PM 또는 TPM이다. 이런 협업 구조때문에 새로운 PO를 채용할 필요가 없었다는 것이다. PO에게 전적인 오너십을 줄 수 없다면, PO를 위한 전담 개발조직이 없다면 PO를 구할 타이밍이 아닌 것이다. 

 무한한 잠재력을 알아보는 법 지원자가 책임진 프로덕트가 어떤 고객을 위해 무슨 가치를 제공하고 있는지 알고 있어야 하며, 자신이 맡은 프로덕트가 회사 전체의 목표에 어떤 역할을 하고 있는지 알고 있어야 한다. 회사 전체에 대한 넓은 시각을 가지고, 고객 중심적인 사고방식을 통해 성공 지표를 설정해본 경험이 있는지 확인하는 것이 중요하기 때문이다. 

 능력있는 PO로 성장하는 길 PO에겐 오너십이 제일 중요하다. 자신의 프로덕트에 대한 직접적인 가설 설정과 요구사항을 정의할 수 없다면, 그 누구도 그 PO의 오너십을 인정하지 않을 것이다. 그리고 프로덕트에 대한 이해를 쌓아야 한다. 작은 것부터 책임지고, 어느 특정 편을 들어주지 말아야 한다. 

 

# 그래서 결론! PO의 자질은?

체계적으로 생각하기(Thinking Systematically) & 깊게 파고들기(Dive Deep)

 단숨에 읽었던, 박신영 작가의 정석 시리즈 외에 가장 신나고 가슴 뛰며 읽었던 책이라고 볼 수 있다. 비문학은 내 취향은 아니지만 그래도 인생을 살아가면서 필요하기에 읽긴 한다만... 이렇게 잘 정리되어 있는 책만 읽으라 하면, 자주 읽을 수 있을 것 같기도 하다. 다만 기록하는 것이 조금 피곤하다면, 피곤하달까?